What Actually Happens in the Ten Weeks After an S/4HANA Go-Live

Cutover weekend gets all the preparation. The runbook, the war room, the hourly checkpoints, the rehearsal cycles. Then Monday arrives, the system is up, the sponsor sends the congratulations note, and the program quietly enters the phase almost nobody plans properly.

Here is what a pattern we keep running into looks like from the delivery side.

Week one is fine, and that is the problem

The first week is usually calm. Volumes are low because the business is being careful. The tickets that come in are access issues and training gaps. Everyone relaxes slightly. Someone says the words “smoother than expected.”

This is where the hypercare exit conversation starts too early. Support readiness gets signed off against a week that was not representative of anything.

Weeks two to four: volume finds the gaps

Then real transaction volume arrives, and the failures change character. They stop being functional errors and start being throughput errors.

Interfaces that passed every functional test start timing out on batch sizes nobody replicated in the test environment. Output management queues back up. A background job that ran in four minutes against test data takes ninety against production. None of this is a design flaw in the classic sense. It is a sizing and volume assumption that no test cycle stressed, because test data volumes almost never match production shape.

The other thing that surfaces here is master data. Not the records that failed validation and got fixed during migration. The records that passed validation and are wrong anyway. Vendors with the right format and the wrong payment terms. Materials with valid but stale planning parameters. These do not raise errors. They raise questions from the business three weeks later.

Weeks five to ten: period close, and the real test

The first period close is the moment the design is genuinely assessed for the first time.

Universal Journal changes how reconciliation works, and teams that carried ECC habits into the new model tend to discover this in the worst possible setting. Reconciliation gaps appear between subledger and GL positions. Intercompany balances do not clear the way finance expects. Reporting that matched in parallel run does not match now that both sides are live and moving.

The pressure here is not technical difficulty. It is that finance has a statutory clock and the answers sit with people who are already being pulled into rollout wave two.

The three things that actually determine how this goes

Who still has context. On most programs, the real answer to “why is it configured this way” lives with two or three people. If their contracts ended at hypercare exit, the organization has documentation without reasoning. Configuration is written down. The trade-off behind it usually is not. That is the artifact worth producing before anyone rolls off.

What got deferred. Every cutover date is protected by a set of conscious deferrals. Defects triaged to phase two. Reports rebuilt “later.” A reconciliation that was accepted as manual “for now.” None of that disappears. It arrives in weeks two to ten as a backlog with no owner, no sprint, and no budget line.

Whether run and change are the same team. If the same architect owns incident escalation and the next rollout wave, the incident queue wins every time, because it is louder. The rollout slips silently, and nobody notices for a month.

What good teams do differently

Not complicated, just rarely done.

Rehearse volume, not only function. At least one test cycle against production-shaped data volumes, including the batch windows.

Write down the reasoning, not just the configuration. A short decision log with the alternatives considered is worth more than another hundred pages of specification.

Treat hypercare exit as a condition rather than a date. Two clean period closes is a defensible bar. Four calm weeks in August is not.

Name a run owner who is not the delivery lead. Different queue, different priorities, different person.

Resource the deferral backlog before cutover. If phase two has no named capacity, phase two is a parking lot.

The lesson

Cutover proves the system starts. Period close proves the design holds. Almost every plan is built for the first one and staffed for none of the second.

With ECC mainstream support ending December 31, 2027, the window for a slow stabilization is narrowing for everyone still mid-programme. The teams that come out of this well will be the ones who treated the ten weeks after go-live as delivery work rather than as cleanup.