An ERP migration strategy determines how the organisation moves business processes, users, data and transactions from the legacy environment to the target platform. The choice between a big-bang, phased or parallel deployment affects more than the go-live weekend: it changes integration design, reconciliation effort, staffing, cost, risk exposure and the length of time the business operates across two systems.
There is no universally safest approach. The right strategy depends on process dependencies, entity structure, data separation, operational seasonality, regulatory constraints and the organisation’s ability to run a controlled transition. This guide provides a decision framework for selecting the approach and testing whether it is feasible.
The three main ERP deployment strategies
Big-bang migration
A big-bang migration moves the agreed scope to the new ERP at one defined cutover. The legacy system is frozen or made read-only for the migrated scope, and users begin processing in the target platform after the go/no-go decision.
Potential advantages: one transition event, less time maintaining dual environments, fewer temporary interfaces and a faster path to a single system of record.
Trade-offs: a concentrated risk window, a larger cutover workload, and limited ability to isolate problems by business unit. It requires mature testing, clear ownership and strong operational contingency planning.
Phased migration
A phased migration moves the organisation in waves. The waves might be defined by legal entity, country, business unit, site, module or process. A well-designed wave has a clear boundary and a manageable set of dependencies.
Potential advantages: smaller cutovers, lessons from early waves, staged investment and the ability to prioritize high-value or lower-complexity operations.
Trade-offs: the organisation may operate old and new systems for months. Shared master data, intercompany transactions, consolidated reporting and cross-site processes can become difficult when a workflow spans systems in different waves.
Parallel run
A parallel run operates the legacy and target systems simultaneously for a defined period or for selected processes. The purpose is to compare outputs, validate results or maintain a fallback while confidence is established.
Potential advantages: additional comparison evidence for payroll, finance, inventory valuation or other high-impact processes; an opportunity to identify differences before relying entirely on the target system.
Trade-offs: duplicate effort, reconciliation overhead, unclear transaction ownership and the risk that teams treat both systems as authoritative. Parallel operation should have a specific purpose, duration, scope and exit criterion.
Compare the approaches
| Decision factor | Big-bang | Phased | Parallel |
|---|---|---|---|
| Cutover size | Large, concentrated event | Smaller, repeated waves | Varies by process and duration |
| Dual-system period | Usually shorter | Often longer | Explicitly required |
| Integration complexity | Can be lower after transition, high at cutover | Often higher during coexistence | High where both systems exchange data |
| Reconciliation effort | Concentrated around cutover | Repeated at each wave | Continuous comparison for selected outputs |
| Best fit | Strong readiness and tightly coupled scope | Clear business or geographic boundaries | Processes where comparison materially reduces risk |
How to choose the right approach
1. Map process and data dependencies
Identify which processes cross entities, sites and modules. An organisation may want to migrate one country first, but shared inventory, centralized procurement or intercompany finance may make that boundary impractical. Map order-to-cash, procure-to-pay, record-to-report, plan-to-produce and other critical value streams end to end.
2. Test whether the business can operate across systems
For a phased approach, document how users will know which system owns each customer, item, supplier, order, invoice and balance during the transition. Define master-data synchronization, transaction routing, reporting consolidation and exception handling. If those controls cannot be designed and tested, the proposed wave boundary is not ready.
3. Evaluate the operational risk window
Estimate how long each process can be unavailable, what transactions can be queued, and which activities must continue during cutover. Include month-end close, payroll, seasonal demand, shipping peaks, regulatory deadlines and supplier/customer commitments. Avoid scheduling the highest-risk transition during a period when business capacity is already constrained.
4. Compare total transition cost
Do not compare only implementation fees. Include temporary interfaces, dual licensing, duplicated support, manual reconciliation, parallel staffing, training across waves, travel, cutover rehearsals and the cost of delaying benefits. A phased approach may reduce the size of a single cutover but cost more if coexistence lasts longer than planned.
5. Set measurable exit criteria
Each wave or parallel period needs entry and exit criteria. Examples include completion of critical testing, reconciliation within approved tolerances, resolution of high-severity defects, user readiness, support coverage and formal business approval. Define who can stop the cutover and who can authorize resumption.
Migration strategy decision matrix
| Condition | Approach to evaluate first | Why |
|---|---|---|
| One entity, limited integrations, strong readiness | Big-bang | May avoid unnecessary dual-system complexity |
| Distinct entities or sites with manageable dependencies | Phased | Allows controlled waves and learning |
| Critical outputs require independent comparison | Time-boxed parallel run | Creates evidence before full reliance on target |
| Highly shared data and cross-entity processes | Redesign wave boundaries first | Prevents fragmented process ownership |
This matrix is a starting point, not a prescriptive rule. A complex global organization may combine approaches: phased deployment by region, a big-bang cutover within each region, and a short parallel validation for selected financial outputs.
What the migration plan must contain
- Approved scope, wave boundaries and process dependencies.
- System-of-record rules for every data domain and transaction.
- Integration, synchronization and reconciliation design during coexistence.
- Data conversion cycles, mock cutovers and performance assumptions.
- Business readiness, training, communications and support coverage.
- Go/no-go criteria, rollback triggers and decision authority.
- Exit criteria and retirement plan for the legacy environment.
Questions to ask the implementation partner
- Which process and data dependencies make our proposed waves viable or risky?
- How will master data and transactions move between environments during coexistence?
- What evidence will demonstrate that each wave is ready?
- How many mock cutovers are included and what volumes will they use?
- What is the cost of temporary interfaces and dual operations?
- Who owns the go/no-go decision and rollback execution?
Final recommendation
Select the deployment strategy that minimizes total business disruption across the full transition—not simply the one with the smallest first cutover. Big-bang can be efficient when scope is cohesive and readiness is high. Phased deployment can work when boundaries are genuinely separable. Parallel operation is useful when it produces necessary comparison evidence and has a firm exit date. Make the choice only after mapping dependencies, estimating coexistence cost and proving the cutover approach in rehearsal.
For related planning, see the ERP migration guide and ERP data migration checklist.
Frequently asked questions
Is big-bang ERP migration always riskier?
It concentrates risk into one transition, but a poorly designed phased migration can create prolonged integration and reconciliation risk. Compare the full operating model rather than the cutover event alone.
Can an ERP project combine phased and big-bang approaches?
Yes. An organization can deploy by region or business unit in waves, then use a single cutover within each wave. Selected processes may also use a time-limited parallel validation.
How long should a parallel run last?
Only as long as needed to meet defined validation criteria. The duration should be based on business cycles, transaction volumes and the evidence required—not an arbitrary calendar period.
How to model coexistence costs
For every week that two ERP environments remain active, estimate the cost of maintaining interfaces, monitoring failures, reconciling balances, supporting users and managing security in both systems. Include temporary data synchronization, duplicate license or infrastructure charges, specialist support and manual workarounds. Assign a planned retirement date to each temporary interface; otherwise, temporary integration can become permanent technical debt.
Also model the business cost of delayed benefits. If a new warehouse, entity or business unit remains on the legacy platform, the organization may not realize the expected improvements in inventory visibility, consolidated reporting or process standardization. Put these delays into the business case rather than treating migration duration as a project-only metric.
Use a wave-readiness checklist
- All processes in the wave have an accountable business owner.
- Master-data ownership and cross-wave transaction rules are documented.
- Interfaces to systems outside the wave have been tested at expected volumes.
- Data conversion and reconciliation have passed agreed thresholds.
- Users, approvers and support teams have completed role-based preparation.
- Open defects have been reviewed against business impact and approved exit criteria.
- Cutover tasks, dependencies, communications and decision authority are rehearsed.
For Microsoft Dynamics 365 projects, Microsoft’s Success by Design framework offers a useful phase structure—Discover, Initiate, Implement, Prepare and Operate—and emphasizes early risk reviews and go-live readiness. It does not prescribe one deployment pattern for every customer; the organization must select a method that fits its process and technical dependencies.
See the Success by Design framework and the go-live readiness checklist when defining project gates.
