Condo Consult · 2025 · Production
Zero-Downtime Database Migration
Migrating a live production system from SQL Server to PostgreSQL with no maintenance window, using a Strangler Fig pattern so each domain moved independently and every step could be reversed.
Context
A production system on SQL Server that had to move to PostgreSQL without a maintenance window. A big-bang cutover would have meant hours of downtime and a rollback plan nobody could rehearse, on a database the business depends on daily.
Architecture
Decisions & trade-offs
Strangler Fig migration
chosen over Big-bang cutover in a maintenance window
A single cutover concentrates all the risk into one irreversible night, and the rollback path is a database restore performed under pressure. Strangler Fig keeps both databases live and moves one domain at a time, so every step is small, verifiable and reversible by flipping a flag. It costs more total elapsed time and a period of dual maintenance — worth it to never take the product offline.
Dual reads before the write cutover
chosen over Cutting reads and writes over together
Reading from both databases and comparing results surfaces schema and data drift while the legacy database is still authoritative. Mistakes get caught as diffs in logs instead of as corrupted production rows.
CI/CD & operations
- Each domain cutover shipped as its own pull request behind a feature flag, so the switch was a config change rather than a deploy.
- Data parity was verified by dual reads before writes were cut over — mismatches surfaced as diffs before users could see them.
- Every cutover had a documented rollback that was a flag flip, not a database restore.
Results
Downtime
Zero
Cutover strategy
Domain by domain
Rollback path
Feature flag, no restore