Cut-over
The cut-over is the tightly scheduled switchover phase of an ERP implementation, in which a company moves from the old to the new system: the legacy system is frozen, the final data is transferred and verified, and the new ERP is released for live operation.
The cut-over is the tightly scheduled switchover phase of an ERP implementation, during which a company transfers day-to-day operations from the old system to the new one. Within this window – usually a weekend or a low-activity period – the legacy system is locked for postings, the final state of the master and transaction data is migrated into the new ERP, verified and released, so that afterwards all orders, postings and inventory movements run exclusively in the new system. The cut-over is therefore the actual technical and organisational transition act between the project and live phases.
Unlike the go-live, which marks the moment of switching to live operation, the cut-over encompasses the concrete sequence of activities that make that moment possible. It is not a single press of a button, but a minute-by-minute planned sequence of freezing, migrating, reconciling, testing and releasing. Because during this phase neither the old nor the new system is fully operational for a short time, the cut-over is one of the most critical and most carefully prepared moments of any ERP project.
At a glance
- Tightly timed switchover phase from the old to the new ERP system
- Process: freeze the legacy system, migrate data, reconcile, release
- Controlled minute-by-minute via a detailed cut-over plan
- Includes checkpoints, a "point of no return" and a rollback scenario
- Preparation for the go-live – not identical to it
How does a cut-over proceed?
A cut-over follows a fixed sequence that is rehearsed in advance in several test migrations. At the start, the legacy system is frozen: from a defined point in time, no new documents may be entered there, so that a stable baseline is created. The final data is then extracted, transformed and loaded into the new ERP – first the master data such as items, customers and suppliers, then the open transaction data such as stock levels, open orders and open items. Each of these steps has an owner, a time slot and a clear success criterion in the cut-over plan.
After loading comes reconciliation: totals, record counts and samples are compared between the old and new systems to ensure that the data transfer is complete and correct. Only once these checks are passed and formally released is the new ERP opened to users. The period between freezing and release is the actual cut-over window – it should be as short as possible and as long as necessary in order to keep the standstill of daily business to a minimum.
Scheduling the cut-over window correctly
The cut-over window is deliberately placed in a low-activity period – often over a weekend, on a public holiday, or at the turn of the month or year. The aim is a period in which as few open transactions as possible have to be migrated and the business can absorb the brief standstill. The cleaner the legacy system is worked down before the cut-over (for example, few open orders, posted goods receipts), the leaner and lower-risk the switchover will be.
The cut-over plan as the central control instrument
The core of every cut-over is the cut-over plan – a minute-by-minute schedule that records which task is done when, by whom and with what result. It interlocks technical steps (data export, import, interface activation, system release) with organisational ones (communication to the business units, release decisions, provision of contact persons). For each critical step, preconditions, checks and an estimated duration are recorded, so that during the window the project team always knows whether it is on schedule.
A good cut-over plan also contains defined decision points. The most important is the "point of no return": the threshold beyond which a fallback to the legacy system is no longer provided for. Before this point, the team must decide whether all checks have been passed and the release can go ahead – or whether the cut-over is aborted and the rollback scenario is triggered. These clear criteria take the pressure off gut decisions in an emergency.
Rollback: the planned way back
A serious cut-over plan always defines a rollback: a documented procedure for returning to the legacy system in a controlled way in the event of critical errors, as long as it has not yet been finally shut down. This includes keeping the legacy system preserved in its original state until the end of the window and not overwriting it immediately. After the release and the first live operation, however, a rollback quickly becomes expensive and practically barely feasible, because new documents are already being created in the new ERP – which is why the quality of the preparation determines whether this emergency route can be dispensed with.
Why the cut-over decides between success and chaos
The cut-over is the moment when all the groundwork of an ERP project proves its worth or backfires. A poorly planned cut-over can mean that on the first working day stock levels are wrong, open orders are missing, or interfaces to the shop and shipping do not work – with the result that deliveries stall and users’ trust in the new system suffers. Conversely, a cleanly executed cut-over ensures that the organisation carries on working on Monday without any noticeable friction.
Success depends almost entirely on the preparation: on the data quality in the legacy system, on reliable test migrations in which the complete process was rehearsed several times, and on a realistic schedule with buffers. The cut-over itself adds no new functionality – it merely transfers a verified state into live operation. That is why in practice a cut-over that runs without surprises is the result of weeks of careful trial runs, not of luck on the appointed day.
Cut-over in the ERP system and adjacent tasks
In the ERP context, the cut-over is closely interlocked with data migration and the chosen implementation strategy. With a big-bang implementation, the cut-over is particularly demanding, because all areas are switched over at the same time and no live fallback system is available in day-to-day operations. With parallel operation or a phased implementation, the switchover is spread across several smaller cut-overs, which reduces the individual risk but requires temporary interfaces between old and new.
The cut-over is immediately followed by the hypercare phase: a period of intensive support after the release, in which key users and support accompany operations closely and fix errors quickly. The cut-over thus marks the transition, not the end of the project. A complete switchover also includes activating all interfaces to the shop system, marketplace and shipping service provider, as well as communicating to all business units from when which system is the leading one.
Distinction: cut-over vs. go-live and data migration
Cut-over, go-live and data migration are often used synonymously, but they denote different things. The go-live is the moment of switching to live operation – the point from which the new ERP is the leading system. The cut-over is the phase that leads up to this moment: the planned sequence of activities around the switchover. Put simply, the go-live is the event and the cut-over is the path to it.
Data migration, in turn, is a part of the cut-over, but not the same thing: it means the technical transfer of the data sets from the old to the new system. Beyond that, the cut-over encompasses the freezing, the release decisions, the interface activation and the organisational control. Those who separate these terms cleanly plan more precisely: data migration is rehearsed in test runs, the cut-over plan orchestrates the entire switchover process, and the go-live is the result that makes both visible.
DACH-specific aspects of the cut-over
In the DACH region, the cut-over date is often deliberately placed at the start of a posting month or fiscal year, so that financial accounting, the advance VAT return and DATEV or BMD handovers start cleanly in the new system and no posting period is split across two systems. The cut-off date is chosen so that the monthly or annual close and the switchover do not collide.
At the same time, shutting down the legacy system after the cut-over must not be confused with deleting its data: documents relevant for tax purposes remain subject to retention requirements and must continue to be available in a GoBD-compliant and audit-proof manner. A well-documented cut-over therefore records which data state was transferred at which point in time – this traceability is part of the procedural documentation and, in case of doubt, must be evidenced to a tax audit.
Example
Practical example: an online retailer’s cut-over over a weekend
An e-commerce retailer with around 40 employees is replacing its previous inventory management system with a new ERP. For the switchover, the team chooses a low-revenue weekend and draws up a cut-over plan with around 50 individual steps – from the last order acceptance in the legacy system on Friday evening, through the data migration on Saturday, to the reconciliation of stock levels on Sunday morning. Each step is documented with a time, an owner and a check criterion.
On Friday at 6 p.m. the legacy system is frozen, the shop is set to a maintenance notice, and the final data migration is started. After the import, the team reconciles stock totals and open orders on a sample basis; only after the check has passed does the release decision fall on Sunday at 2 p.m. – before the defined "point of no return". The shop and the marketplace interfaces are reactivated, and from Monday morning the team works exclusively in the new ERP, accompanied by a two-week hypercare clinic.
Frequently asked questions
Matching ERP systems
Related services
Questions about Cut-over in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.