SAP cutover and hypercare explained

Cutover is the sequence of steps that takes a business off its old system and onto the new one, 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 can hand the system to whoever runs it next. Together they are the part of an SAP programme that everything else exists to reach, and the part the ecosystem reads most closely on a CV.

What happens in a cutover?

A runbook, executed in order against the clock. The business stops transacting in the old system at an agreed moment — the freeze — and takes its final extracts. The technical steps follow: the last transports are imported, interfaces are pointed at the new system, background jobs are scheduled, users are created and their roles assigned. Then the loads, in dependency order: master data that may have been loaded days earlier is topped up, then the open business — stock, open orders on both sides, open receivables and payables, balances — is loaded and reconciled object by object against the extracts. Functional leads run their checks, key users post a first real transaction in each area, and the whole is reported to a go or no-go meeting. If the answer is go, the system is opened, the old one is closed to input, and the first working day begins under hypercare.

Why is it rehearsed?

Because the weekend cannot be extended. A cutover rehearsal — a mock cutover, a dress rehearsal — runs the same runbook into a test system with the same people, the same sequence and a stopwatch, and 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, a build can be reviewed, but a cutover puts a name against every step and a time against every name, and the person who ran the reconciliation or held the bridge at three in the morning knows things about the system and about themselves that a phase plan cannot teach. 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, the weekend needs people, and the vocabulary of the runbook is learned in a weekend and kept for a career.