Upgrade with a known recovery point and a clear completion check.

1. Plan the change

1. Record the installed version and selected target version. Open the target's full notes, channel, migration and breaking-change flags, and advisory in portal Downloads.
2. Check that the existing installation was completed using the supported signed installer. Pre-beta development databases are not supported upgrade sources.
3. Review host prerequisites, available space, the maintenance window, and who can recover the host if it becomes unavailable.
4. Check the license and replacement capacity if the commercial term or allocation changed. A smaller replacement must fit the installed deployment's reserved seats.
5. Validate the recovery point below, then use a pilot or staging environment for your intended sign-in, connector, and change workflows.

2. Prepare and test the recovery point

Use the Backups section of docs/INSTALL_ADMIN.md in the verified release. The installed backup script creates an encrypted database and deployment-configuration archive and its checksum. Keep a verified off-host copy and hold its decryption identity separately from the application host.

1. Choose how much data loss and recovery time your organization can accept, and retain recovery points accordingly.
2. Verify that a real encrypted backup and its matching checksum reached the intended off-host storage. An enabled schedule is not evidence that a backup succeeded.
3. Use the bundled restore-check procedure to validate the artifact. Exercise a restore into an empty disposable database before relying on that recovery point.
4. Record the selected version, backup time, validation result, and restore duration outside the deployment.
5. Monitor backup freshness and failed runs; check again after host, storage, or schedule changes.

Retain these separately

Keep the matching signed release, its independently confirmed verification key, backup decryption material, and the host's DNS, TLS, firewall, monitoring, and secret-manager configuration. Exported job artifacts and local application logs are not part of the logical database backup. The complete inventory is in docs/DISASTER_RECOVERY.md.

Restore validation also needs compatible PostgreSQL restore tools and the chosen decryption tool. Follow the bundled requirements; a successful restore check is not a production recovery procedure.

3. Choose the supported upgrade path

Administrator-approved update from Naradox

When the installer configured UI updates and the host meets their requirements, use Platform > Updates to review and explicitly install an update. The update path verifies the artifacts and requires its configured encrypted off-host backup. Follow docs/UPDATER_SERVICE.md for host prerequisites, status, and recovery; starting a container profile alone does not configure this workflow.

Signed manual upgrade

Download and verify the target release, then use the Upgrades section in its docs/INSTALL_ADMIN.md. Run the target bundle's upgrade script against the existing installation with the documented backup configuration. This path is also available when the host cannot use UI updates, including the documented SELinux and Docker mode restrictions.

Use the existing installation directory. The upgrade preserves the current license unless you explicitly supply a replacement; a normal software update does not require buying another license. Do not run the fresh-install procedure over an existing deployment.

4. Confirm completion before reopening normal work

• The selected upgrade path reports completion, and the installed version is the intended target.
• The HTTPS application opens, readiness checks pass, and an administrator can sign in with the expected MFA and session policy.
• The license, encrypted connector settings, intended read access, and authorized workflow still work.
• Review queued, failed, or unresolved jobs and the audit record; confirm backup freshness and update status.

Use the release's docs/GO_LIVE_RUNBOOK.md for the detailed checks. A downloaded bundle, started job, or briefly reachable login page alone is not proof that the upgrade completed.

If an upgrade is interrupted

• Manual upgrade stopped after preparation: retain the original recovery backup, fix the reported cause, and follow the bundled instructions to resume the exact same signed target release with the original options, except for the documented license-capacity case below.
• UI update has an unresolved result: inspect its operation status and follow the updater guide's reconciliation procedure. Do not start a competing manual upgrade while the update may still be running.
• A smaller replacement is rejected after services stopped: follow the capacity-downgrade procedure in the bundled installation guide. Resume the exact same signed target release without --license-file to finish with the retained entitlement. Once the application is running again, free the surplus reserved seats and import the smaller replacement there.
• The database or host cannot be recovered in place: use the disaster-recovery procedure below.

Do not clear an unfinished installation marker by hand, change the target release mid-resume, or replace the original recovery point with a backup of a partially upgraded deployment. Send the version, operation status, failed step, and sanitized error to support.

Recovering a host, database, or irreversible migration

Follow docs/DISASTER_RECOVERY.md from the retained, verified release. It covers containment, backup validation, replacement-host preparation, authority files, database restore, runtime reconciliation, and checks before reopening traffic. Installing an older application bundle does not roll back the database.

Keep old and replacement writers isolated. Restoring an earlier database can restore queued jobs and omit later audit records; it does not undo changes already made in Check Point. Reconcile potentially repeated vendor changes before restoring write access, then verify local access, licensing, audit integrity, and read-only connector behavior.

The supported recovery quarantines restored pending or retryable work for reconciliation and disables connector auto-install. Local Network Feeds stop serving released content while retaining their drafts and URLs; review and explicitly release each intended feed after recovery. Gateways can retain cached entries. Follow job recovery and Network feeds before restoring those workflows.

Restored browser sessions, outstanding invitation and password-reset links, pending MFA setup, and MFA backup codes are invalidated. Enrolled authenticators remain available. Sign in again and regenerate backup codes using Sign-in and security.

Record the actual recovery point and duration externally. Once the recovered release is stable, treat any newer upgrade as a separate change with a fresh validated backup.