SAP cutover and hypercare explained

Written by an SAP Finance & Treasury practitioner working with SAP since 2008 · how the guides are written · Updated 9 October 2026

Cutover is the sequence of steps that takes a business off its old system and onto the new SAP system, usually across one long weekend. Hypercare is the period of intensified support that follows, until the new system has survived its first period-end and the project team hands it to whoever runs it next. A mock cutover, also called a dress rehearsal, is the timed practice run of that sequence in a test system before the real one.

What happens in a cutover?

A runbook, executed in order against the clock:

1. Freeze. The business stops transacting in the old system at an agreed moment and takes its final extracts.
2. Technical steps. The last transports are imported, interfaces are pointed at the new system, background jobs are scheduled, users are created and their roles assigned.
3. Master data top-up. Master data that may have been loaded days earlier is brought up to date.
4. Open business. Stock, open orders on both sides, open receivables and payables, and balances are loaded in dependency order and reconciled object by object against the extracts.
5. Business checks. Functional leads run their checks, and key users post a first real transaction in each area.
6. Go or no-go. The whole is reported to a go or no-go meeting.
7. Go-live. If the answer is go, the system is opened, the old one is closed to input, and the first working day begins under hypercare.

What is a mock cutover, and what is a dress rehearsal?

A mock cutover is a full practice run of the cutover: the same runbook, executed into a test system by the same people, in the same sequence and against a stopwatch. A dress rehearsal is the last mock cutover before the real one, run as close to the production weekend as the project can make it. Many teams use the two terms for the same thing, and "cutover rehearsal", "dry run" and "cutover simulation" are further names for it. SAP's own training material says "dry run" and "dress rehearsal": the cutover plan is adjusted after it, and the issues it finds are analysed and fixed before the go or no-go decision (SAP Learning, Discovering SAP Activate). It is rehearsed because the weekend cannot be extended, and it produces the two things the real one needs: a timing for every step, and a list of what went wrong.

The migration stream has usually rehearsed its loads several times before the full rehearsal; the full one adds the technical steps, the business checks and the communication, and it is the last layer of the test strategy. Programmes that skip it find out on the real weekend that a load takes three times longer than anyone thought, or that a step nobody owned was never done. Each rehearsal should be cleaner and faster than the last, and the trend across them is what the steering committee uses to decide whether the date holds.

Who does what on the weekend?

• The cutover manager owns the runbook and the clock: every step has an owner, a planned start, a planned duration and a status, and the manager calls each one, chases the late ones and keeps the timeline honest. On many programmes the project manager or the test manager takes the seat; on large ones it is a role of its own.
• The migration lead and the object owners run the loads and the reconciliations, and report each object as loaded, reconciled and signed.
• Basis imports the transports, switches the interfaces, schedules the jobs, watches the system and holds the rollback.
• Functional leads and key users run the checks and the first transactions, and sign that their area is ready.
• The business owners and the steering committee take the go or no-go decision on the evidence the others produce.

All of it happens on a bridge call and in a war room, with a status board everyone can see, and the communication — what is done, what is late, what it means — is as much of the job as the steps.

What is the go or no-go decision?

A decision taken against criteria written down weeks earlier, so that it is not taken on nerves at midnight. The criteria are typically the reconciliation of every migrated object, the absence of open defects above an agreed severity, the readiness of the interfaces and the business sign-offs, and they are reviewed at checkpoints through the weekend rather than once at the end. The honest part of the decision is the alternative: a no-go means the rollback plan is executed — the old system reopened, the loads discarded — and a new date found, which is why the rollback is rehearsed too. The methodology places the decision at the end of its deploy phase; a programme that cannot say what would make it choose no-go has not planned a cutover, only a date.

What does hypercare do?

It keeps the project team in the building while the business learns the system for real. The first transactions in each area, the first deliveries and receipts, the first payment run, the first billing cycle — each meets a situation testing did not cover, and hypercare is the arrangement that lets those be fixed in hours rather than through a ticket queue. Concretely: consultants on the floor beside the key users, a daily call that triages every issue by business impact, a defect process with a fast lane for anything that stops a transaction, and a steady narrowing of the team as the issue rate falls. The milestone that ends it is the first period-end close, because the close is where every area's postings are tested together; once it has run, the system and the open issues are handed to AMS and the project closes. Exit criteria — an issue rate, a close done, a handover accepted — are written down for the same reason the go or no-go criteria are.

Why does the ecosystem read cutovers as the credential?

Because it is the phase that cannot be attended passively. A workshop can be sat through, but a cutover puts a name against every step and a time against every name. That is why experience is read by the go-lives on a record, why "ran the cutover" outweighs "delivered projects", and why test managers and migration leads who own a clean one are asked to own the next programme. It is also, for a newcomer, the easiest phase to be useful in: the checks need hands, and the vocabulary of the runbook is learned in a weekend and kept for a career.