A migration is a production change that runs for months. These notes follow that change in order: who owns production, how replication is chosen, what QA has to prove, who can stop a cutover, how rollback is rehearsed, what monitoring must show, what a handover contains, when the work can close, and what changes for the team afterward.
- 01. Operations and migration are one delivery system
- 02. Choose replication from the failure modes it must survive
- 03. What QA must prove before production
- 04. Who has the authority to stop a cutover
- 05. Rollback must be rehearsed, not merely documented
- 06. What monitoring must reveal during the transition
- 07. What the next engineer needs at handover
- 08. When the migration is ready to close
- 09. Operating habits after cutover
01. Operations and migration are one delivery system
A SQL Server to PostgreSQL migration can be technically correct and still fail operationally.
The migration code is only one part of the system.
Production still needs monitoring, backups, maintenance, incident response, reporting and support.
Someone must own the existing platform while the new one is tested.
Someone must decide whether a cutover proceeds, pauses or rolls back.
Someone must preserve operational context across teams and support shifts.
This is how we run live database modernization work: we manage operations and migration as one delivery system.
Before approving a migration plan, ask:
- Who owns production during the transition?
- What must QA prove before cutover?
- Who has rollback authority?
- How will incidents and handovers work after migration?
If those answers are unclear, the migration is not production-ready.
02. Choose replication from the failure modes it must survive
Replication should not be chosen from a feature matrix.
It should be chosen from the failure modes the migration must survive.
A SQL Server to PostgreSQL migration needs a replication design that holds up across QA, reporting, recovery and production.
The same configuration can behave very differently when the schema includes:
- Partitioned tables
- Row filters
- Missing replica identity
- Incompatible indexes
- High write volumes
- Frequent schema changes
A design that works in development may fail when it meets production data and operating conditions.
In live delivery, we test extension-based and native PostgreSQL replication against the actual table structures, recovery requirements and cutover plan.
When the exception list becomes longer than the operating model can safely support, we change the design.
Before approving a replication architecture, ask:
- Which tables cannot replicate cleanly, and why?
- What lag or error threshold stops the cutover?
- How are schema changes controlled during the transition?
- Can replication be rebuilt without increasing risk to the primary system?
Replication is not a migration checkbox. It is part of the cutover and recovery design.
03. What QA must prove before production
If QA proves only the happy path, production becomes the failure test.
A migration should not pass QA because the data arrived once.
For a SQL Server to PostgreSQL program, a successful load is only the baseline.
QA must test representative transactions, difficult table structures, replication interruption, monitoring and recovery.
In live delivery, an early replication configuration passed the basic flow but failed against specific table structures and operating limits.
We changed the design, rebuilt it in QA and validated the new path before promoting it to production.
Before authorizing cutover, ask:
- Is data reconciliation repeatable across tables and test cycles?
- Which lag, error or mismatch stops the release?
- Can interrupted replication be restarted or rebuilt without increasing risk to the source system?
- Has rollback been rehearsed within the agreed recovery window, with a named owner?
If those answers are unclear, QA has not produced enough evidence to authorize production.
04. Who has the authority to stop a cutover
A cutover is not controlled if everyone can raise a concern but nobody has the authority to stop it.
Most cutover plans assign tasks, owners and timelines.
Fewer define decision rights.
In a SQL Server to PostgreSQL migration, the team should not be negotiating authority after replication lag breaches its limit, reconciliation fails or a critical workflow breaks.
In live delivery, we assign stop authority before the change window opens.
Anyone responsible for a critical control can call a pause.
One named cutover owner then decides whether to resume or roll back, using evidence and thresholds agreed in advance.
Before approving the cutover plan, ask:
- Which signals trigger an immediate pause?
- Who owns the evidence for each signal?
- Who can authorize a restart?
- When does a pause become a rollback?
- Who communicates the decision to the business?
If the answer depends on who happens to be online, the cutover is not production-ready.
Clear stop authority does not slow delivery. It prevents uncertainty from becoming downtime.
05. Rollback must be rehearsed, not merely documented
A rollback plan has to account for the transactions created after cutover.
Once PostgreSQL accepts new transactions, switching the application back to SQL Server can leave the old system missing business data.
Keeping the source database online is only part of the recovery plan.
For a SQL Server to PostgreSQL migration, rehearse what happens both before and after the target starts accepting writes. The recovery path changes once the two systems hold different data.
In QA, test the full sequence:
- Stop application writes and background jobs in a controlled order.
- Recover and reconcile transactions accepted since cutover.
- Validate critical business workflows on the recovery system.
- Measure elapsed time from the rollback decision to validated service restoration.
Agree in advance how long that sequence can take and what data loss, if any, the business accepts. Name the person who verifies both before service resumes.
If the rehearsal cannot meet those limits, resolve the gap before approving cutover.
Before signing off, ask one question:
Can we demonstrate what happens to every transaction accepted after cutover if we have to return?
That answer is the evidence behind a credible rollback plan.
06. What monitoring must reveal during the transition
Your database can be available while the business is already working with stale data.
A reporting feed can stop updating while the application still accepts transactions. A replication process can be running while its backlog grows.
During a SQL Server to PostgreSQL migration, monitoring needs to cover the source, the target and the path between them.
Before cutover, establish a baseline for the workload that matters. During the transition, track:
- Replication lag, errors and recovery progress.
- Storage headroom and retained transaction logs.
- Critical query latency, blocking and application errors.
- Report freshness and scheduled job completion.
Each signal needs an agreed threshold, a named responder and a next action. Test the alert route in QA so the right person receives enough context to investigate.
Compare performance under representative workloads. A quiet test period tells you little about the next reporting cycle or peak in customer activity.
Before approving the monitoring plan, ask:
Which signal would tell us that a customer workflow has degraded even though both databases are online?
That is the gap to close before the transition begins.
07. What the next engineer needs at handover
A handover is incomplete if the next engineer still needs the original author to explain what is safe.
During a database migration, the operating state changes quickly. A replication path is rebuilt. A job is paused. An exception is accepted for a limited window.
The next shift needs to know which of those decisions still applies.
For a SQL Server to PostgreSQL transition, the handover should make five things clear:
- Which system currently accepts writes and where dependent applications connect.
- What changed, what was validated and where the evidence lives.
- Which jobs, alerts or replication processes are paused or operating under an exception.
- What remains unresolved, with a named owner and a due time.
- Who can approve the next change, pause the work or authorize recovery.
Then test the handover with the receiving engineer.
Can they find the current runbook, confirm their access, locate the relevant dashboards and explain the next action without reconstructing a chat history?
If they cannot, complete the transfer before releasing the outgoing owner.
The handover is ready when the receiving team can act on it.
08. When the migration is ready to close
The cutover can finish before the migration is ready to close.
The application connects to PostgreSQL. The first checks pass. Traffic moves.
There is still a production service to accept.
Before closing a SQL Server to PostgreSQL migration, review the evidence with the team that will operate it:
- Critical workflows and reporting cycles have passed the agreed validation.
- Performance has been assessed under representative demand.
- Backup and recovery procedures have been tested against agreed recovery objectives.
- Monitoring, escalation, access and support responsibilities have been accepted by the receiving team.
- Open defects and exceptions have named owners, deadlines and explicit acceptance.
Set the observation period around the workload. A quiet afternoon may say little about an overnight batch or a month-end report.
Agree separately when the old platform can be retired, taking account of recovery needs, retention requirements and remaining dependencies.
The question at closure is simple:
Can the receiving team operate, change and recover this service within the agreed scope?
That is the through-line of this series. Replication, QA, cutover authority, rollback, monitoring and handover all contribute to the same operating responsibility.
09. Operating habits after cutover
The data moves to PostgreSQL in a weekend. The operating habits take longer.
A team that ran SQL Server for years brings its routines with it. Most of them do not transfer.
Maintenance works differently. Backup and recovery tooling is different. Connection handling is different. The signals that warned of trouble on the old platform are not the ones that matter on the new one.
The risk is not a failed migration. It is a successful one, operated with the wrong instincts.
After cutover, we check four things with the operations team:
- Which routine tasks from the old platform still run, and which ones no longer mean anything?
- Does alerting watch what fails on PostgreSQL: vacuum health, replication lag, connection saturation?
- Has the team performed a point-in-time recovery on the new platform, not only read about it?
- Who decides on configuration changes, and where is that decision recorded?
The first ninety days on a new platform set the habits for the next several years.
They deserve the same attention the cutover received.
Where these notes lead
The notes describe one operating model. The service pages describe how Datrick delivers it: SQL Server to PostgreSQL migration, database migration services, migration risk assessment, PostgreSQL consulting, and managed database services for the platform after cutover. For a production problem that cannot wait, see emergency DBA support.