As 2027 approaches: five decisions to make on your S/4HANA move

SAP ends mainstream maintenance for ECC 6.0 at the close of 2027. Extended support runs to 2030 at additional cost, but that is not a solution — it is buying time. Since a typical transformation takes 9 to 18 months from preparation to go-live, the decision window is narrower than it looks.

The most common mistake we see in the field is starting with a technical question: brownfield or greenfield? That question matters, but it comes second. The five topics below need to be settled first; the technical approach then follows from those answers.

1. How much of your custom development is actually used?

Z programs, user exits and reports accumulated over the years form a burden that most companies have never inventoried. Trying to carry all of that code across doubles both the duration and the cost of a migration.

The starting point is usage analysis: over the past 12–24 months, how often did each custom object run, and who ran it. In practice we find a significant share of that list is never used, or can be met by standard S/4HANA functionality. As the list of code to migrate shrinks, project risk falls with it.

2. Is your master data ready to move?

The business partner approach in S/4HANA merges customer and vendor master data into a single structure. Duplicate records, missing tax information or inconsistent account groups in your current system all become visible at once during migration.

Master data cleansing is the most underestimated item in a migration. It can run in parallel with the project, but its start should not be delayed: cleansing decisions — which records merge, which get closed — require business sign-off, and that takes time.

3. Which local requirements are critical in your financial processes?

In Türkiye, e-invoicing, e-ledger, inflation accounting and VAT refund processes shape the scope directly; in multi-country structures, each country's statutory reporting does the same. Where standard S/4HANA does not fully cover these, the replacement must be planned in advance.

The critical point is this: if compliance items surface as “additional development” at the end of the project, the go-live date slips. Moving this topic to the very start of scoping removes most late-stage surprises.

4. Who will run the business during the migration?

Transformation projects ask for the most experienced people in each business unit — the same people who run daily operations. When that overlap is not planned, either the project slows down or operations suffer.

The practical answer is to define project time upfront and cover the daily support load externally during that period. In companies with a support (AMS) model in place, transformation projects visibly progress with less disruption, because the team can think about tomorrow rather than today.

5. What do you expect to gain afterwards?

This is the hardest question. “Support is ending, we have to move” is a valid reason, but it does not steer a project on its own. A measurable goal — cutting the close from 8 days to 4, improving stock accuracy, moving reporting out of Excel — acts as a compass in scope discussions.

Without a goal set at the start, scope takes the shape of the loudest request. With a measurable goal, the question “does this development serve the target?” disciplines scope by itself.

Where to begin

The answers to these five topics also determine which migration approach fits you. If you will largely keep existing processes and speed is the priority, a system conversion (brownfield) fits; if you will redesign processes, a new implementation (greenfield) may suit better. There are also selective data transition approaches in between.

Before deciding, we recommend taking a photograph of your system's current state: custom development inventory, master data quality, process maturity and compliance items. Timelines built without that picture tend to be revised halfway through the project.