Cutover Checklist
StableA 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_restoreor 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
- Stop writes to the source.
- Update application secrets and DSNs.
- Restart the application or its connection pool.
- 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.
