Upgrading from Flow 6.x

The shape of the jump#

A 6.0.x → 7.x upgrade is a major-version migration: the schema upgrade is long (hours on a large database is normal, not a hang), irreversible, and crosses several releases' worth of schema changes at once. The database migration machinery applies update scripts sequentially, so the mechanism is a single install-new-run-migration pass rather than manually installing each intermediate version.

That said, treat it as multi-stage in practice:

• Confirm the path for your exact source version with support before scheduling. Specific old builds have known potholes (a 6.0.x source with a particular schema state may need an intermediate hop or a pre-fix script). The confirmation costs one email; discovering a pothole mid-window costs the weekend.
• Budget the migration duration by rehearsal, not hope — see the dry-run below.

The licence key format trap#

This one has bitten every 6.x upgrade ticket in some form:

• Current keys are the long JWT-style format (eyJ…).
• 6.0.9-era UIs cannot accept the long format — the field/validation predates it.
• Old short-format keys are not issued anymore.

So the sequencing is fixed: upgrade first, then apply the current key on the new version. If your 6.x maintenance expiry gates the upgrade itself, that check is against the maintenance date (must cover the 7.x release date) — arrange the renewal and the correctly-dated key before the window. If the site's current 6.x licence is healthy, it keeps 6.x running until the moment of migration; the new key applies immediately after. Never plan to "refresh the licence on 6.0.9 first" with a modern key — it cannot be entered.

The replicate-first approach (recommended for production 6.x)#

The de-risked path used by sites that cannot gamble the plant, and it doubles as the rehearsal:

1. Stand up the target — a new server (or the same, side-by-side SQL) with current Windows/SQL per Supported Platforms.
2. Restore a copy of the 6.x database there.
3. Run the migration on the copy with the 7.2.0 Config tool. Time it. Capture every warning.
4. Fix what surfaces on the copy — connector plugin versions, the vMeasureValue-era view changes for any external SQL readers (Querying Infohub from SQL), the behaviour changes between the versions.
5. Validate: model intact, sample values matching 6.x, charts rendering, one full engine cycle clean.
6. Only then repeat against production, in a window sized by step 3's measured duration — or, for a server move anyway, promote the rehearsal machine to be the new production (final delta restore → migrate → cut over), which shrinks production downtime to the cutover.

Post-restore/pre-migration items are the standard set: Platform host name, consumers undeployed on any copy, new licence after the identity change — the checklist is in Backup and Recovery.

What changed underneath (6.x modeller's orientation)#

A modeller returning after years on 6.x should skim, in order: Deploying Configuration (the states), Templates: Concepts (materially evolved since 6.x), and What's New in 7.2.0. Two mechanical notes from real 6.x migrations:

• Old query-on-measure configurations: 7.x supports queries on both tags and measures, but content migrated from very old versions is worth spot-checking — a handful of 6.x sites found retrieval configurations that needed re-saving to settle into the current property model.
• Module/package versions: after migration, the packages under %ProgramData%\Flow Software\Flow\Config\Packages must be the 7.2.0 set; stale modules produce the property-loss class described in Infohub Components and Installers.

The one-page runbook#

1. Support confirms the path from your exact build ☐
2. Maintenance/renewal dated to cover 7.2.0; new-format key in hand ☐
3. Rehearsal migration on a copy — timed, warnings captured, fixes noted ☐
4. External SQL readers inventoried and re-verified against the new views ☐
5. Production window = rehearsal time + margin; backup verified restorable ☐
6. Migrate → apply key → Platform host check → plugins current → deploy → validate ☐
7. Keep the 6.x backup until a full reporting period passes ☐

See also#

• Upgrading to Flow 7.2.0
• Licence Keys in Practice
• Deprecations and Breaking Changes
• Backup and Recovery