Cutover Checklist

Stable

A practical checklist for switching the application to SPG99 after migration.

Updated: March 5, 2026

It is better to treat cutover as a separate short operation with a prepared plan, not as “the last step some evening.”

Before the cutover window

  • the target tenant, database, and final DSN are confirmed;
  • the team knows which migration method was used: pg_dump / pg_restore or approved replication;
  • the application, migrations, and major queries have been verified on the target database in advance;
  • the rollback path and responsible people are defined.

Immediately before cutover

  • freeze schema changes on the source;
  • finish or coordinate background jobs that may continue writing;
  • do a final validation of data and target connectivity;
  • if replication is used, verify that lag is minimal or zero.

The switch itself

  1. Stop writes to the source.
  2. Update application secrets and DSNs.
  3. Restart the application or its connection pool.
  4. Run a read/write smoke test against SPG99.

After cutover

  • check the database state in Console;
  • inspect Metrics and Logs;
  • confirm that business-critical operations work normally;
  • keep the old source in standby mode for an agreed short rollback window, if required.

What is especially important not to forget

  • update DSNs in all services and background workers, not only in the main application;
  • rebuild or clear old connection pools;
  • remove obsolete secrets after the rollback window ends.