Instance Lifecycle Administration

Renaming the Infohub database#

Supported, with three follow-ups people miss:

1. Rename in SQL (single-user, ALTER DATABASE … MODIFY NAME, back to multi-user).
2. Every Flow Config connection entry and anything else holding the old name (external queries, DBA jobs) must be updated — Config's saved connections are per-user, so each modeller updates their own.
3. The licence survives — it binds to the database's GUID identity, not its name (details).

If Config throws a connection-string validation error after the rename (or after a restore), the saved connection entry itself is malformed for the new situation — delete the saved entry and create it fresh rather than editing it.

Moving between SQL editions or servers#

SQL Express → Standard, or to a new server, is a backup/restore plus the standard restored-instance checklist — which exists in full in Backup and Recovery. The short form of what bites:

• Licence: new database identity → new key required, requestable only after the restore. Budget the gap.
• Platform host name: still names the old machine; nothing runs until corrected.
• Consumers/notification servers: undeploy before the new copy can double-send into production systems.
• Express-specific: confirm the model actually fit Express's caps before assuming the move is optional — a database bumping Express's size limit exhibits as mysterious failures well before the move.

A dev mirror of production#

The ask: dev should be a 1:1 copy of prod for troubleshooting. The pattern that works:

1. Restore last night's prod backup to the dev server (scriptable; the backup exists nightly via the maintenance window).
2. Post-restore, immediately and in this order: undeploy/repoint all consumers and notification servers → fix the Platform host to the dev machine → apply the dev licence.
3. Only then let anyone in.

Step 2's order matters: the copy is born pointing at production destinations with production's schedule. Script the whole sequence — a manual step forgotten once is an email blast to real recipients or duplicate rows in a real warehouse. A dev instance needs its own permanent licence (dev server's own database identity); request it once with the prod licences rather than re-requesting per refresh — the identity changes per restore, so in practice sites either script the key request or accept a standing dev key arrangement with support. Raise the pattern with support once, not per refresh.

Retiring an instance#

Deleting an instance is deliberately manual — there is no "delete instance" button:

1. Undeploy everything (stops collection and outbound sends cleanly).
2. Stop/disable the Flow Bootstrap service on its hosts (or uninstall Infohub where the host is being repurposed).
3. Take and archive a final backup — retention obligations (batch traceability, manual data) outlive the instance; the backup is the archive.
4. Drop the database.
5. Housekeeping: revoke its server keys at any template server/replication parents, remove it from estate monitoring, note the licence as freed.

Skipping step 5 is why central instances alarm on dead sites for months.

Rolling a model back#

Asked plainly: "I deleted elements — how do I roll back to a previous model version?"

The honest answer: Infohub has no model-level undo or version history. Entity versioning exists for values (measure values, event periods), not for configuration. The rollback options, best first:

1. A model export taken before the change — import it back over the damage. This is why the KB advises exporting before any restructuring; the export is your model version.
2. Last night's maintenance backup — restore it to a side database, open it with Config, export just the damaged subtree, and import that into production. Full-restore rollback is a last resort (it discards everything since the backup, including the day's manual entries).
3. Rebuild from the template — if the deleted content was templated, re-instantiating/updating from the template regenerates configuration (not values; derived values re-calculate, manual values are gone).

Codify the cheap habit: export before restructuring, and let nightly backups be the safety net — then a rollback is twenty minutes of side-restore instead of a data-loss negotiation.

The register#

All of these operations go wrong at their seams — the consumer nobody undeployed, the licence nobody re-requested, the external query nobody re-pointed. One page per instance listing: its licence details and expiry, its consumers and their destinations, its server keys (issued and held), external SQL readers, and its backup/retention arrangement. Every operation above starts by reading that page; most tickets in this category exist because it did not.

See also#

• Backup and Recovery
• Licence Keys in Practice
• Querying Infohub from SQL
• Importing and Exporting Models