Upgrading to Flow 7.2.0

Before you start#

Back up the database, and verify the backup restores. Not that it completed — that it restores, onto a server you could actually use. This is the only rollback you have.

Check your maintenance entitlement. An Infohub licence carries a licence expiry and a separate maintenance expiry. Maintenance governs entitlement to new versions, so an instance can run happily for years and then refuse an upgrade. Confirm before scheduling the window, not during it. See Licensing Infohub.

Inventory every machine in the instance. Flow Config workstations, and every server running Flow Bootstrap. All of them are upgrading in this window.

Note your plugin package versions, under %ProgramData%\Flow Software\Flow\Config\Packages.

Read Deprecations and Breaking Changes.

Pick a quiet window. Not month-end, not during a shift handover that depends on an Infohub report.

Why every machine together#

Flow Config writes the schema version. Once one Flow Config has upgraded the database:

• An older Flow Config will refuse the newer database.
• An older Bootstrap may not understand newly configured objects.

So a partial upgrade leaves some of your estate unable to work. Upgrade every machine in the same window.

The sequence#

1. Stop what you can afford to stop. In particular, consider undeploying consumers if you would rather they did not publish during the upgrade.

2. Back up the database. Again, verified.

3. Upgrade the servers. Run the 7.2.0 MSI on each machine running Flow Bootstrap. The installer stops the service, replaces the binaries, and restarts it. Content under %ProgramData% is preserved.

A Linux host has no installer: stop the FlowBootstrap service, extract the 7.2.0 TAR over the daemon folder, and start it again — or pull the 7.2.0 image if it runs in Docker. See Installing Infohub Beyond the Wizard.

4. Upgrade the Flow Config workstations.

5. Open Flow Config against the database. It performs the schema upgrade.

6. Confirm the schema upgrade completed rather than assuming. The database script repairs in this release run as part of it.

7. Verify the model. See the checklist below.

8. Deploy. Anything showing Different needs deploying to pick up the upgrade.

9. Confirm values are arriving, and that consumers and notifications resumed.

Two upgrade failures specific to this release#

Both were fixed in 7.2.0, and both are worth knowing because they affect getting to 7.2.0.

"Incorrect syntax near go". Database scripts are now forced to CRLF line endings. An upgrade failing with this message is hitting the line-ending problem — 7.2.0 contains the fix, so ensure you are running a 7.2.0 build that includes it rather than an earlier attempt.

A silently skipped upgrade. As above: a failed pre-migration backup previously let the tool load without upgrading. If a past upgrade appeared to work but behaviour suggested otherwise, this may be why.

Plugin versions matter#

Connectors are plugins, and a plugin declares its own property set. If a plugin assembly is older than the configuration expects, properties it does not recognise can be silently lost when configuration is saved.

Practically:

• Note plugin versions before upgrading.
• If plugin packages are updated as part of the upgrade, verify a sample of connections afterwards — server, credentials, query, and any connector-specific properties.
• The symptom to watch for is a connection whose query or a specific property appears blank when it definitely was not.

This matters most for the Web Service connector in this release, because its property set grew substantially with the OAuth work.

Verification checklist#

After upgrading, before declaring it done:

Structure

1. The model tree is intact — folders, metrics, measures, event schemes.
2. Measure counts match what you recorded beforehand.
3. Charts and dashboards open and render.

Configuration 4. A sample of connections: server, credentials, and connector-specific properties present. 5. Web Service connections in particular — check the authentication and header properties. 6. Calculated measures compile; nothing shows as unvalidated. 7. Time schemes: offsets and freeze point unchanged.

Operation 8. Deployment status: everything Deployed, nothing Different or Faulted. 9. New values arriving for a sample of measures across the model. 10. Event schemes producing events. 11. Consumers publishing, verified at the destination. 12. Notifications delivering.

Numbers 13. Spot-check a handful of values against what they were before the upgrade. They should not have changed.

Item 13 is the one people skip and the one that matters most. Ten of the fixes in this release change behaviour in ways that are correct but visible — read the next section before you treat any of them as a regression.

Fixes that will change some numbers#

These are corrections, so the new values are the right ones. They are still worth anticipating, because someone will notice.

Retired event periods now always close. An event that was left open-ended had a duration growing without limit, and every duration-derived measure above it was wrong. Those measures will now report correctly, which may be a visible step change where the problem existed.

Locked-retrieval template updates preserve user-added calculations. Where a template update previously removed them, they now survive. Nothing is lost by this; a model that had been losing calculations will simply stop doing so.

Ordinal attribute lookups are now case-sensitive. If any lookup relied on case-insensitive matching, it will now fail to match. Worth checking if you use ordinal attribute lookups.

Case-insensitive model attribute placeholders in the MQTT consumer. Topics that previously failed to resolve a placeholder because of case will now resolve. Confirm the resulting topics are the ones subscribers expect.

Measure integration starts sending attribute-only changes. An attribute edited on an event period that had already ended was never pushed, because it was stamped below the integration's watermark. It is now detected. Two consequences: consumers begin receiving changes they were previously never sent, and the upgrade clamps integration watermarks that the old behaviour had advanced into the future, so an integration that had gone quiet will start catching up on its first scan. Expect a burst, then a return to normal.

Integration placeholder timestamps move. [periodstart] and [periodend] resolved against the server's operating system time zone rather than the instance time zone. If those two differ at your site, timestamps in integration payloads will shift — to the correct values. Anything downstream that had been compensating for the old offset needs to stop.

Stranded tag transform configuration is removed. Where a tag's retrieval type had been changed from Aggregated to Calculated, hidden tag transform rows were left behind. The upgrade deletes them and clears template links that pointed at them, writing a System Migration audit row for each. Query the Log table after upgrading if you want to see exactly what was removed.

Time slice coverage fills in. Manual and Set-To-Previous measures whose time slices did not cover the whole time period now do. Periods that read as partially missing may become complete.

Backfill on GUID-keyed FLD and V2 licences. The engine previously computed a backfill cutoff from a creation date those licences do not carry, producing a cutoff in year one. Backfill windows on affected instances will change to sensible ones.

Template updates stop overwriting an instance's Time Slice Aggregation. A measure whose event value had been corrected to Average by hand, and reverted to Sum by every template update, now keeps the correction — so event values on such measures will stop being N times too high after the next update. Conversely, a template update no longer sets the aggregation type on an instance unless the template locks it; see Deprecations and Breaking Changes.

If a number changes after the upgrade, check this list before treating it as a regression.

Rollback#

There is one route: restore the database backup and reinstall the previous Infohub version.

That means everything since the backup is lost — including any manually entered values, which cannot be recovered from anywhere else. It is why the backup must be verified and why the window should be quiet.

Keep the pre-upgrade backup until you have run at least one full reporting period on 7.2.0 without surprises.

Multi-site estates#

Sites will not all upgrade on the same day, so decide a policy rather than improvising:

• Which version combinations you are prepared to run between a site and the centre.
• Upgrade order. A pilot site first, then the centre, then the rest is a common pattern — but confirm the pilot site's replication to the still-older centre works before proceeding.
• Template server compatibility. If the centre publishes templates, confirm derivation still works from an un-upgraded site.

Verify replication end to end after each step rather than at the end.

After the upgrade#

Worth doing in the first week:

• Run the audit recipes over the model. See CLI Recipes for CI.
• Check the Flow event log for anything new and recurring.
• Move the freeze point forward if it had been held back for the upgrade.
• Look for event schemes sitting behind. The Event Scheme form offers Skip To on a scheme more than 21 days behind; if any scheme has been stranded behind a data gap, this release is the first that can move it on without intervention in the database. See Event Lifecycle Operations.
• Review the new capabilities you may want — the CLI expansion and the OAuth work are the substantial additions. See What's New in Flow 7.2.0.

See also#

• What's New in Flow 7.2.0
• Upgrading from Flow 6.x
• Deprecations and Breaking Changes
• Backup and Recovery