Cutover · programme delivery

We have run the go‑live weekend.

Not as a figure of speech. Behind this company is roughly eight years of SAP programme delivery — seven S/4HANA hub conversions into two production environments, spanning several countries, leading delivery teams of about ten to twenty-eight people.

This is not an SAP practice, and the next section says exactly where our scope stops. What carries across to an AWS migration is the discipline the weekend demands: a rehearsed cutover, an enforced freeze, a go/no-go with named owners, and a rollback that had to be real — because the window in which it could still be taken was measured in hours.

delivery & programme management — not technical SAP

You leave with a written spek — what your roadmap is blocked on, a fixed scope, and a timeline for your estate. Yours whether or not you use us.

$ ./cutover --rehearse
01
Rehearse it
Execute the whole sequence against a copy of production, timed, before anyone executes it for real.
02
Decide it
A go/no-go at a stated point, by named owners, against criteria written while everyone was rested.
03
Be able to undo it
Where most plans stop. A rollback nobody has executed is not a rollback — it is an intention with a heading.
# the boundary, first

What we do not do — before what we do.

Programme delivery and technical SAP are two different jobs, and a technical buyer finds the seam between them on the first call. So it may as well be on the page. We have done one of these jobs, at length, and not the other one at all.

  • Cutover, end to end. Planning, dry runs, the change freeze, conversion execution, testing, the go/no-go, go-live and hypercare.
  • Conversion delivery. Seven S/4HANA hub conversions into two production environments, spanning several countries — real production, other people's businesses on the other side of it.
  • Programme management. Multiple concurrent projects, weekly executive reporting, risk forecasting and the contingency planning that follows from it.
  • Delivery leadership. Teams of roughly ten to twenty-eight people, working across time zones, on a plan with a fixed weekend at the end of it.
  • The estate underneath. The environments, the network paths between them, the restores, the access, and the reporting layer the steering committee reads.
What we do not do — 5
  • ABAP. We do not write it and we do not review it.
  • SAP Basis. Your Basis team or your SAP partner keeps that work. We plan and run alongside them; we do not replace them.
  • Functional configuration. FI, CO, MM, SD and the rest. Someone else owns the business process design, and should.
  • HANA sizing and SAP-certified infrastructure decisions. That is a specialist call and we are not the specialists.
  • Badges. There is no AWS SAP Competency here and no SAP partnership. If one is a requirement on your programme, we are not the firm — and it is cheaper for you to learn that on this page than three calls in.

What is left is the part that is hardest to hire for and easiest to under-plan: the weekend itself, and the months of sequencing that decide how it goes.

Book the 30-min review →
# what a cutover actually is

Six things decide whether a cutover lands.

None of this is SAP-specific. It is the same shape whether you are converting an ERP, moving a database, or flipping DNS onto a platform you rebuilt on AWS. Where migrations differ is how much of it a team believes it can skip — and on a weekend where the business is offline if you are wrong, the answer is none of it.

$ tap a row for what it means, and what it looks like when it goes wrong

The cutover is executed in full against a copy of production, and timed, before anyone executes it for real. The first pass runs long. That is the deliverable — you are not rehearsing to prove the plan works, you are rehearsing to find the places it does not, while finding them is still free.

Fails when the rehearsal is a walkthrough of the document rather than an execution of it.

Change stops on an agreed date, and the stop is held by someone with the standing to hold it. Everything that will move has to be known before it moves, so the delta is a list you carry in — not a discovery you make mid-cutover, with the clock running.

Fails when a freeze is announced but not enforced, so the plan describes a system that no longer exists.

Every task with an owner, a predecessor, and a duration taken from the rehearsal rather than estimated at a desk. The point is not tidiness. It is that at any moment during the weekend somebody can say whether you are ahead or behind — which is the only honest input to the decision in row four.

Fails when durations are guesses, so "behind" is a feeling rather than a number.

A decision taken at a stated point, by named owners, against criteria agreed and written down while everyone was still rested. Write them before, because the version of the team that has been awake through the night is not the version that should be inventing the criteria.

Fails when the decision is deferred until it is no longer a decision.

A tested path back, with its own runbook, its own measured duration, and a last point at which it can still be taken. A rollback nobody has executed is not a rollback — it is an intention with a heading. Knowing where you stand against the clock is how you know whether that door is still open.

Fails when the fallback exists only as a paragraph in the plan.

Go-live is not the end of the programme; it is the start of the loudest part of it. Staffed triage, a defect path agreed before the first defect arrives, an owner per business area, and written exit criteria — so hypercare ends deliberately instead of quietly becoming permanent support.

Fails when nobody defined the exit, so the programme never actually closes.

$ ls ./cutover — 6 · rehearsal, freeze, runbook, go/no-go, rollback, hypercare

Recognise the list? Then you already know which row your next migration is weakest on. That is a useful thirty minutes.

Book the 30-min review →
# why this is on an AWS site

The conversion is the visible half. The estate underneath is the other one.

Under a conversion there is always an estate: environments to stand up and tear down, network paths between them, restores that have to actually restore, access granted and revoked on a schedule, and a reporting layer executives read on a Monday. That half is AWS work, and it is the half we do.

environments/
Accounts, guardrails and network paths laid out so a rehearsal environment can be a real copy of production rather than an approximation of one.
terraform/
The environment you rehearsed in and the one you cut over into are built from the same infrastructure code — which is what makes "it worked in the dry run" mean anything.
dashboards/
The reporting layer a steering committee reads without being walked through it. AWS-hosted dashboards were part of at least one SAP programme we ran.

That is the honest intersection, and it is the whole of it. We are not selling SAP on AWS.

The discipline an SAP go-live forces on you is the discipline an AWS migration deserves and rarely gets. When the phrase "there is a rollback path" appears elsewhere on this site, it is written by people for whom that sentence has had to be true.

The adjacent block of work is Migration Factory — discovery, wave planning and repeatable cutover across an estate. See the full set of accelerators for what it sequences with.

# next step

Which hour of your migration are you dreading?

Thirty minutes with an engineer. Bring the cutover you are not looking forward to — the conversion, the database move, the DNS flip — and we will tell you what we would rehearse first, and where your rollback is currently a sentence rather than a path.

You leave with a written spek — what your roadmap is blocked on, a fixed scope, and a timeline for your estate. Yours whether or not you use us.

Book the 30-min review → $ ./book --30min --no-pitch