Version upgrades

An upgrade is two things in a fixed order: a new application package, and then the database steps the new version brings with it. Those steps are written so that running them a second time does nothing.

The two paths

Path	When	What you do
New installation	Empty database	The whole installation path, once
Upgrade	Existing database	A new package plus the version's database steps

What the database steps do

Every step has a report-only mode that reads, prints what it would do, and writes nothing. Running that mode before the upgrade is how you learn what is about to happen in one specific database.

Two rules apply to the steps themselves, and they are what makes an upgrade a repeatable action:

• A second run does not write again. A step that has already run recognises that and reports it, rather than failing or creating a duplicate.
• A value you edited stays. A step that introduces a new setting writes only where no value exists; a value an administrator chose — a system title, a threshold, a cadence — is reported as a local value and left as it is.

Some steps also offer an explicit undo of what they did.

What happens to whatever was due during the downtime

What was due	What actually happens
A scheduled report whose time has passed	Sent once when the system returns, then advanced to the next occurrence — not once per missed occurrence
A reminder for a window that has already started	Not sent after the fact
Events and invitations already issued	Unchanged; the upgrade does not touch them

That direction was chosen deliberately: three copies of the same report landing together in an inbox turn a short outage into an incident of its own.

What to check afterwards

1. Support center → System information. The system version is what the server actually reports, not what the package is called. The same panel carries server uptime, database, server inventory and the number of configured connections. A Copy report button produces the same information as text to attach to a support request.
2. One screen that pulls inventory. If rows arrive, the inventory is being read. An inventory that is not being read does not appear as an error — it appears as an empty list or as demo data, and the panel above says which of the two.
3. One connection that sends outward. A connection test against the saved configuration, and send a test email if mail is configured. An email arriving is the only evidence that the mail path works.
4. What's new. The change list ships with the package and is not stored in the database, so it always describes the version running on this machine.

On an air-gapped network

The new package crosses by the same route the first one did — see Air-gapped deployment. Keep a copy of the package actually installed: it is also what a return to that version needs, and there is nowhere to download it again.