That is why the strategy should follow discovery, not preference. This guide compares the main approaches, the constraints that should drive the decision, and the rollback and validation needed for a controlled cutover.
What a database migration strategy is
A database migration strategy defines how data and workloads move from a source database to a target database. It covers the cutover approach, the sequence systems move in, the rollback plan, and the data validation that confirms the migration worked.
The right strategy depends on business and technical constraints: acceptable downtime and data loss, application dependencies, team capacity, and how easily the move can be reversed. Requirements around data integrity, compliance, and business continuity also shape what is realistic.
Discovery establishes those constraints before an approach is chosen. It identifies application migration requirements and database dependencies, including stored procedures and triggers with no direct equivalent in PostgreSQL's own feature set, as well as undocumented connections to downstream systems. This is particularly important when moving from legacy systems, where operational assumptions can differ significantly between platforms.
The migration approaches and what each costs you
Three database migration strategies cover most enterprise moves:
- Big bang
- Phased migration
- Parallel run
Each balances downtime, complexity, and migration risk differently.
Big bang cutover
In a big bang database migration, everything moves during one planned cutover. The source database stops accepting changes, data is transferred and validated, applications are repointed, and the target database goes live.
This works when the data can move within the available downtime window and the application landscape is small enough to test end to end. It also keeps complexity relatively low because there is only one system of record.
The trade-off is that migration, data validation, and troubleshooting all happen in one window. For larger databases, even the base backup and data transfer can consume a significant part of that window.
Phased migration by wave
A phased migration moves workloads in groups over weeks or months, with source and target systems operating side by side between waves.
This works well for large, heterogeneous database migrations, particularly where workloads can be separated into clear dependency groups. Smaller waves also give teams an opportunity to apply lessons from one migration before starting the next.
The trade-off is a longer migration and greater integration complexity. Applications and data flows may need to operate across both platforms, while governance and access controls must remain consistent throughout.
Parallel run with continuous replication
A parallel run uses continuous database replication to keep the source and target current until cutover. In PostgreSQL, logical replication can replicate ongoing changes while the target is prepared and validated.
This approach is often described as a zero-downtime database migration, but it does not eliminate downtime completely. A short outage is still required to stop writes, confirm the target has caught up, and repoint applications.
The trade-off is operational complexity. Two live systems require continuous monitoring to maintain data consistency, and PostgreSQL logical replication does not replicate schema changes or sequence data. These need to be handled separately before cutover.
Choosing an approach against your constraints
The matrix below shows how each database migration strategy fits common business and technical constraints:
| Constraint | Big bang | Phased by wave | Parallel run |
| Downtime tolerance | Hours, planned | Short, repeated per wave | Minutes at cutover |
| Data volume | Fits the migration window | Can be divided by workload | Suits larger volumes |
| Application coupling | Loose, few consumers | Clusters can be isolated | Tight or unclear |
| Data location constraints | Straightforward | Manageable per wave | Live in two places |
| Team experience | First migration viable | Builds capability by wave | Assumes prior experience |
| Operational overhead | Lowest | Moderate, sustained | Highest |
| Rollback options | Narrow | Reopen with each wave | Widest before cutover |
The most conservative approach is not always the safest. Parallel run creates a longer period in which two systems can drift and requires the expertise to maintain data consistency. A well-rehearsed big bang may carry less risk for some teams. Regulatory requirements can also restrict where data is stored during a cloud migration or other cross-environment move, not just where it resides afterward.
Sequencing and wave design
A phased migration should start with lower-risk workloads, giving the team a chance to test the process before moving more complex systems.
Ordering by risk and dependency
Move lower-risk workloads first, then progress to more tightly coupled, higher-risk systems. Workloads that share applications, data, or other dependencies should move together to avoid creating new integration problems between the source and target environments.
Decision gates between waves
Each wave should have a decision gate with agreed success criteria and a named owner. If data validation, application testing, or other criteria are not met, pause the migration, resolve the issue, and apply what you learn before starting the next wave.
Building a rollback path that works
A rollback plan should define when the migration can still be reversed, how that reversal will happen, and who has authority to make the decision.
Where the point of no return sits
Before writes reach the target database, rollback may simply mean repointing applications to the source database. Once new data exists only on the target, reverting requires that data to be reconciled without compromising data integrity.
Define this point of no return before cutover, along with how long the source will remain available and when it can be decommissioned. The rollback window will narrow as the migration progresses.
Rehearsing the rollback
Test the rollback process before cutover, including common failure points: can the source accept writes again if replication only runs one way? Can sequence and identity values be reconciled? Can downstream systems be repointed?Can backups be restored within the required timeframe?
The rehearsal should also confirm who makes the rollback decision and the criteria that trigger it.
Validation and the definition of done
A database migration is not complete when the data has moved. Before cutover, agree the data validation, testing, and operational criteria the target database must meet, as well as who makes the final go/no-go decision.
Validation should cover:
- Data integrity and consistency: Compare row counts and aggregates between the source and target to confirm data has migrated correctly.
- Functional validation: Test applications, reporting, and integrations against the target environment.
- Performance testing: Test production-like workloads and concurrency to identify performance issues before go-live.
- Operational readiness: Have monitoring, alerting, updated runbooks, on-call support, and disaster recovery procedures ready before cutover. Database activity monitoring should also be in place from go-live.
Define how long the post-cutover stabilization period will last, who owns the target database during it, and what must be achieved before the migration is considered complete.
Where migration strategies fail
Database migrations often run into problems before cutover. A 2025 survey by Caylent found that only 6% completed their most challenging database migration on time, while 46% experienced five or more hours of downtime.
These problems usually come back to a handful of planning and ownership gaps:
- Choosing the strategy too early: Discovery has not established the true data volume, application dependencies, or complexity of the source database.
- Assuming acceptable downtime: The technical team plans around an outage window that the business has not agreed to.
- Unclear accountability: No one has responsibility for confirming the completion criteria or making the final go/no-go decision.
- An untested rollback plan: The process exists on paper but has not been rehearsed under realistic conditions.
- Leaving operational readiness until after cutover: Monitoring, backups, recovery procedures, and support are not ready when the target database goes live.
De-risking the move with the right support in place
Your database migration strategy should also consider what happens after cutover. The target platform needs to support the availability, resilience, security, and operational requirements identified during planning.
Fujitsu Enterprise Postgres provides:
- High availability: Replication and high availability capabilities help reduce planned downtime and support resilient production environments.
- 24/7 support: Global support provides access to PostgreSQL expertise when issues arise, backed by defined SLAs.
- Long-term support: Fujitsu Enterprise Postgres provides a minimum seven-year support lifecycle, with support available for up to ten years, compared with five years for each community PostgreSQL major version.
- Enterprise security: Built-in security capabilities help organizations maintain the access controls and data protection required in regulated environments.
A successful migration should leave you with a database platform that can meet your requirements long after cutover. Talk to the Fujitsu team about whether Fujitsu Enterprise Postgres fits your target environment.
Frequently asked questions about database migration strategy
What are the main database migration strategies?
Three database migration strategies cover most enterprise moves. A big bang migration transfers everything in one planned cutover. Phased migration moves workloads in waves, while a parallel run keeps the source and target current through continuous replication until traffic switches. Trickle database migration is another term sometimes used for gradually moving data while systems remain operational.
When should you use a big bang migration instead of a phased one?
A big bang migration suits environments where the data fits within the available downtime window and applications can be tested end to end. It is generally the lower-complexity option. Phased migration is better suited to larger or more complex environments where workloads and dependencies can be separated into manageable waves.
Can a database migration be done without any downtime?
Not completely. Continuous replication or change data capture (CDC) can keep the target database current while the source remains live, significantly reducing downtime. However, even a so-called zero-downtime database migration typically requires a short cutover to stop writes, confirm data consistency, and repoint applications.
How do you build a rollback plan for a database migration?
Define what rollback means at each stage and identify when changes to the target database become difficult to reverse. Specify how long the source database will remain available, the state it must remain in, the criteria that trigger rollback, and who makes the decision. Test the rollback plan before cutover.
How do you decide the order of migration waves?
Order migration waves by risk and dependency. Start with lower-risk workloads, keep applications and databases with shared dependencies together, and leave tightly coupled workloads until the process has been tested. Set clear decision gates between waves so problems can be resolved before the next phase begins.
What is the most common reason database migrations fail?
Database migrations often run into problems when the strategy is chosen before discovery is complete. Teams may underestimate data volume, application dependencies, database schema complexity, or schema conversion requirements. Poor data quality can also create problems during validation. Discovery should establish these constraints before the data migration strategy is finalized.
What is the safest database migration strategy?
There is no single safest strategy for database migration. The right approach depends on downtime tolerance, data volume, application dependencies, team experience, and the required scalability of the target environment. The safest approach combines those constraints with a tested rollback plan, clear validation criteria, and agreed ownership of the final cutover decision.
PostgreSQL Insider 
