Migration Strategy
A migration strategy defines how a company moves from a legacy system to a new one – usually an ERP: by which approach, in which order and with which risk profile. It answers the fundamental question "big bang, phased or parallel operation?" and frames the entire cut-over.
A migration strategy is the overarching roadmap that defines how a company moves from a legacy system to a new one – typically an ERP. It does not answer which records are transferred (that is the job of data migration), but rather the question of approach: is everything switched over on a single go-live date, are sites or modules migrated one after another, or do the legacy and new systems run in parallel for a while? The strategy thus defines the risk profile, the sequence and the timeframe of the entire system switch.
At its core, the migration strategy is a trade-off between speed, risk and effort. A fast full switch minimises the time in which two systems have to be maintained in parallel, but concentrates the entire risk on a single day. A phased approach spreads the risk and allows for learning effects, but extends the project duration and the phase in which interfaces between old and new have to be bridged. The right choice depends on company size, process complexity, downtime tolerance and the quality of the legacy data – there is no universally "best" strategy.
At a glance
- Roadmap for the switch from a legacy to a new system (approach, not data content)
- Three basic patterns: big bang, phased migration, parallel operation
- Trade-off between speed, risk, effort and downtime tolerance
- Frames the cut-over, go-live and the hypercare phase that follows
- To be distinguished from data migration – the actual data transfer
The basic patterns of a migration strategy
In practice, almost all migration strategies can be traced back to three basic patterns and their hybrids. They differ mainly in how strongly the switchover risk is concentrated on a single point in time and how long the legacy and new systems have to coexist.
Big bang: switchover on a fixed date
With the big-bang approach, the entire company is switched to the new system on a fixed date and the legacy system is shut down. The advantage is clarity: there is only one truth, no permanent dual maintenance and no complex transitional interfaces. The price is a high, bundled risk – if the cut-over fails, day-to-day operations can potentially grind to a halt. Big bang is best suited to smaller and mid-sized organisations with a manageable process landscape, clear responsibilities and sufficient time buffer around the go-live.
Phased migration and parallel operation
With phased (step-by-step) migration, the new system is introduced in stages – for example by site, entity, module or process area. This spreads the risk and allows experience from the first wave to feed into the next. With parallel operation, the legacy and new systems run at the same time for a defined period, so results can be reconciled before the legacy system is finally shut down. Both variants reduce the downtime risk but increase effort and complexity, because data has to be kept temporarily in sync and transitional interfaces have to be operated.
What the choice of migration strategy depends on
The right migration strategy does not follow from preference but from measurable conditions. The decisive factors are the downtime tolerance of business operations, the number of sites and entities, the complexity of the processes, the quality and volume of the legacy data, and the available project resources. A pure online retailer with a tight fulfillment cadence has different requirements than a manufacturing company with several plants.
As a rough guide: the lower the tolerable downtime and the more complex the organisation, the more this argues for a lower-risk, staggered approach or parallel operation. Small, homogeneous companies with clean data are often faster and cheaper with a well-prepared big bang. It is important to define the strategy early in the project – ideally as part of the ERP implementation and documented in the requirements specification – because it decisively shapes the schedule, test concept and resource needs.
Migration strategy in the ERP project
Within an ERP rollout, the migration strategy is the framework into which data migration, test runs, cut-over and go-live all fit. It determines when the data set is frozen, in which order processes go live, and how long an intensively supported hypercare phase is maintained after the start. Without a clear strategy, these building blocks easily come into conflict – for example when one site is due to go live while central master data has not yet been cleanly transferred.
A fallback plan is always part of the strategy. In case the final switchover run fails, it must be defined how and up to what point it is possible to revert to the legacy system. With a big bang this rollback plan is especially critical, because otherwise the legacy system would already be shut down. With staggered approaches the ongoing operation of the legacy system eases the problem, but shifts it into maintaining the transitional interfaces.
Cut-over planning and maintenance windows
The cut-over is the actual switchover: the final freezing, transfer and release of the data. It is usually scheduled in a tight maintenance window – such as a weekend or month-end – during which day-to-day operations pause. The migration strategy defines how this window is structured: which tasks run in which order, who signs them off, and from which point a rollback is no longer possible. A minute-by-minute cut-over choreography with clear responsibilities is a central success factor in every approach.
Distinction: migration strategy vs. data migration
Migration strategy and data migration are often confused, but they refer to different levels. Data migration is the technical and functional transfer of specific records – extracting, cleansing, mapping, loading and validating articles, customers, accounts or open items. The migration strategy sits one level above: it defines by which pattern and in which order the entire switch takes place, and in which waves the data migration happens at all.
Put simply: the strategy answers the "how and when" of the system switch, data migration the "what" at record level. Also to be distinguished is the permanent integration of productive systems via interfaces – it is not a one-off switch project but ongoing operation. Keeping these levels cleanly separate avoids mixing strategic fundamental questions with operational data details in the project, which would otherwise lead to both being decided poorly.
Example
Example: staggered ERP switch at a trading company
A trading company with three sites and a connected online shop wanted to move from an organically grown siloed solution to an integrated ERP. Because of the tight shipping cadence in e-commerce, a longer downtime was out of the question. The project team therefore decided against a company-wide big bang and in favour of a phased migration strategy: the smallest site with a simple product range went live first, in order to test the approach under real conditions.
The experience from this first wave – refined field mapping, more precise cut-over checklists, more targeted user training – fed into the following sites. The online shop was switched over as the second-to-last building block and transferred in a weekend maintenance window with minute-by-minute cut-over planning. For every wave there was a fallback plan to the still-running legacy system. Result: no noticeable standstill in day-to-day operations, manageable risk per wave – paid for with several months of parallel effort and temporary transitional interfaces.
Frequently asked questions
Matching ERP systems
Related services
Sources
Questions about Migration Strategy in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.