SAP S/4HANA Brownfield Migration: When No-Go Is the Right Decision

I've been working with SAP for more than 20 years. In the early 2000s, at 16–17, I was already installing and configuring SAP systems. Since then I've been involved in many SAP initiatives, and over the last 10 years in many ECC to S/4HANA migrations.

Alongside that I have 10–15 years of experience with Axapta and Dynamics – today Dynamics 365. Seeing both worlds is exactly what's needed in a sophisticated SAP environment: knowing not only what the system can do, but how to steer a project when it doesn't go to plan. This story is about one of those times.

It's also the "other half" of a story I've already told: the 4 a.m. Telekom outage happened right in the middle of this cutover.

ECC vs. S/4HANA: From Customisation to Standard

SAP ECC was a system you could customise almost endlessly. Over the years, companies built their own developments, their own tables and their own logic into it. That flexibility is the biggest challenge in a migration today.

S/4HANA is far more standardised. The "clean core" principle means the core system stays as close to standard as possible, and custom extensions move out to SAP BTP (Business Technology Platform). This makes future upgrades and projects much easier – but the road from ECC is not.

• Many data sets change – for example, customers and vendors become Business Partners, and finance moves to a new, unified data model (the Universal Journal).
• SAP Activate is the recommended methodology for ECC to S/4HANA transformations.
• Fit-to-Standard workshops drive the long-familiar custom solutions back to standard wherever possible.

This is where companies often get frustrated. A process that has worked "our way" for 15 years suddenly has to work the standard way. On top of that, a brownfield migration usually means 48–72 hours of business downtime – and every hour of it is visible.

The Big Logic Difference: Dynamics 365 vs. SAP

Put simply: Dynamics 365 started from the standard, while SAP is getting there now – coming from decades of customised ECC systems. That's why an ECC to S/4HANA migration is not just a technical upgrade, but a business transformation as well.

A Typical Weekend Runbook for a Mid-Size System (1–5 TB)

For context, here is what an indicative brownfield cutover runbook looks like for a mid-size system. The exact times depend on database size, hardware, the number of countries and interfaces, and the results of the mock runs.

Our Cutover

Our system was larger than this example: a multi-terabyte SAP used in several countries. Because of its size, the decision was to lock the users on Tuesday afternoon instead of at the weekend.

The go/no-go meeting was interrupted by a single point of failure – my own.

I live in Cordia Woodland, in the middle of District IX in Budapest – in a building with almost no Telekom mobile coverage. When the fibre went down at 4 a.m., I lost everything at once. A cutover decision-maker who can't connect is a risk too. Two streets away from home, the problem didn't exist.

The Decision: Stop, and Let the Team Rest

By Thursday morning it was clear: there was no chance of completing the brownfield migration in this window. The decision was to stop – and send the team to rest.

Both halves of that decision matter. A team that has been awake for more than 24 hours doesn't fix errors; it makes new ones. And a no-go isn't a failure. Going live with wrong VAT codes in several countries would have been.

What Went Wrong: A Small eÁFA Change in a Multi-Terabyte Migration

The SAP system is used in several countries. For the Hungarian data, the new eÁFA solution had already been implemented – the Hungarian Tax Authority's (NAV) electronic VAT system, which the ERP talks to directly through an M2M (machine-to-machine) connection.

As far as we can see so far, this implementation changed something in the VAT codes. Somewhere between the mocks and the actual brownfield migration, this was missed. The root cause analysis is still under way.

Lessons for the Next Cutover

• A change freeze means freeze – including tax and legal localisations. eÁFA, e-invoicing and VAT changes are changes too. Anything that goes into production after the final mock needs a new mock or at least a targeted delta test.
• The mock must match production. Before cutover, compare the configuration and transports of the last mock against production. The difference is where the risk is.
• Agree the go/no-go criteria in advance. And make sure the decision isn't made only by the team that has been awake for 24 hours.
• People are on the critical path too. Plan shifts and rest periods into the runbook, just like database steps.
• Your own infrastructure is part of the cutover. The connectivity of the key decision-makers is a single point of failure. Have a backup that doesn't depend on the same provider or the same building.
• RCA before the next attempt. The new window only makes sense once we know exactly what happened to the VAT codes – and how to prevent it.

What Do You Think?

• Have you seen a localisation or tax change derail a cutover?
• How do you handle change freeze when legal deadlines don't wait for the project?
• Who makes the go/no-go decision in your projects – and how rested are they?

Related Case Studies

• Three Backups, One Point of Failure – A 4 a.m. Telekom Outage
• BCDR – Business Continuity and Disaster Recovery in IT Operations
• Plan B – High Availability: redundant internet for remote work