Same weekend. Different people in the room.
A cutover is a cutover: rehearse it, freeze it, time it, decide it, be able to undo it, then staff the noise afterwards. What changes between an AWS migration and an S/4HANA conversion is not the discipline. It is who else is in the room, and which of them owns the parts we do not.
Pick the one with the date on it.
An AWS migration
Workloads, databases, the DNS flip. Your build or a partner's — we sequence the move.
- We own — the plan; the rehearsal being run and timed; the timed runbook; the go/no-go call; the rollback plan, its rehearsal, and the decision to stop if it has not been proven; and hypercare through to its written exit. And the estate underneath it: accounts, guardrails, the network paths between environments, restores that actually restore, access granted and revoked on a schedule, and the reporting layer a steering committee reads.
- You own — your application code. We do not write it. We sequence its move, and we own the weekend it moves on.
An S/4HANA conversion
A conversion with a date, on AWS or not. Your Basis team and your SAP partner keep their work.
- We own — the plan; the rehearsal being run and timed; the timed runbook; the go/no-go call; the rollback plan, its rehearsal, and the decision to stop if it has not been proven; and hypercare through to its written exit. Plus the programme layer a conversion demands: concurrent workstreams sequenced against one date, executive reporting, risk forecasting and the contingency planning that follows from it. And the AWS estate underneath, where there is one.
- They own — ABAP, SAP Basis, functional configuration, HANA sizing, and every SAP-certified infrastructure call. We plan and run alongside your Basis team and your SAP partner; we do not replace them. There is no SAP partnership here and no AWS SAP Competency. If either is a requirement on your programme, we are not the firm — and it is cheaper to learn that here than three calls in.
$ ls ./estates — 2 · same runbook, different room
Scoped to one cutover. Named, dated, and closed in writing.
unit — one cutover: the event with the date on it, from the first rehearsal to the written close of hypercare. The date is yours, not ours; what we scope against is the event, not a calendar we do not control.
Every task with an owner, a predecessor, and a duration taken from the rehearsal rather than estimated at a desk.
What ran long, what broke, and what changed in the plan because of it. The first pass runs long; that is the point of running it.
Written before the rehearsal, by named owners, while everyone was still rested.
Its own steps, its own measured duration, and the last point at which it can still be taken.
Triage staffing, a defect path agreed before the first defect, an owner per business area, and the written criteria that end it.
One report a steering committee reads without being walked through it — and where the estate is ours to build, the dashboards behind it in your accounts, as code.
All six, in your systems: the runbook in your repository, the criteria in your document store, the dashboards in your accounts. They are written to be re-run rather than to be filed.
The deliverable is not the weekend. It is the pattern your own PMO runs the next one from.
fixed scope · you own the output
Ask the obvious question.
You should want to know whether anyone here has actually stood in this. The discipline above did not come from a conference talk — it came from SAP S/4HANA conversion programmes run end to end, into real production, where the business was offline if the weekend went wrong. That record, and the exact line where our SAP scope stops, is set out on one page rather than summarised into a bullet here.
The adjacent block of work is Migration Factory — discovery, wave planning and repeatable cutover across an estate. This page owns the date; that block moves the estate.