SAP S/4HANA Migration Without the Vendor Theater

SAP’s mainstream ECC maintenance ends December 31, 2027, and the question now is which SAP S/4HANA migration approach fits the system you already run. This practitioner guide shares my framework for choosing among greenfield, brownfield, and hybrid, the preparation work required, and why getting a late start just punishes your budget.

Key Points

• Your decision is greenfield, brownfield, or hybrid, and it revolves around your custom code volume and data footprint.
• 2027 is the real deadline, while the 2030 extended support is a paid penalty.
• The conversion is the easy bit, but custom code triage and archiving will decide the success of your migration.
• Waiting is not free. Experienced S/4HANA talent is projected to run 20% to 30% short of demand, and an ECC system past 2030 becomes an audit and security liability.

Choose Between Greenfield, Brownfield, and Hybrid On a 2027 Deadline

The end of 2027 feels like it’s still a long way away. Unfortunately, when you add a SAP migration into the mix, it can make your project timeline painfully tight. It is way too easy for everyone to look at that last day of 2027 and think that things will be OK when their gut instinct tells them so. So, let’s not debate about how real that date is; let’s look at how we should approach getting our SAP migration to fit in the time we really have, especially when a greenfield build has an expected 12- to 24-month runway.

So, regardless of how we get there, let’s agree that the question is not whether to move off ECC, the previous-generation SAP ERP. SAP already made that decision for us. The question now is which SAP S/4HANA migration approach aligns with the system you actually have. Figuring out how late you can start versus your appetite for paying a premium is the real start to this conversation.

We have to make the options digestible and something we can hand off to leadership. SAP ends mainstream maintenance for ECC on December 31, 2027, even though there is an option for extended support through 2030. And, we only have three real migration approaches available to us:

• Greenfield – rebuild clean
• Brownfield – convert in place
• Hybrid/Selective – move what matters and leave the rest

The deciding factor between those options is a calculation based on your custom code volume and the data footprint. Not SAP’s stated dates.

The Deadline Is a Scheduling Problem

I like to frame the problem with real numbers, so let’s do that.

Looking at the state of ECC customers at the tail end of 2024. Only about 37% of ECC customers had even licensed S/4HANA. A 2025 SAPinsider survey put roughly a third of organizations fully live, with another quarter mid-implementation. That means the majority of the customer base is somewhere between “we bought the ticket” and “we haven’t left the house yet.”

Most companies are seeing their migration running about 1.5 years on average, and the ASUG state-of-adoption research shows a reported range of four months to six years based on complexity. A range that broad doesn’t really help me, other than to say that, in practice, it is tough to estimate or tighten the project.

Regardless, the deadline is fixed. There is a lot of work to do, and the people who can actually do it aren’t waiting around.

I keep seeing teams treat the 2030 extended maintenance window as the real deadline. I don’t think that is the correct way to look at it.

The 2030 timeline is expensive and means we’re sitting in a state of being technically supported. In reality, extended support means patches and legal changes only with no new functionality. A reduced-scope safety net you are paying a surcharge for. Planning to land in extended support is not a contingency. It is a decision to pay more for less, made slowly, by not deciding.

Quick Reality Check

• The 2027 date is when ECC stops getting full support, not when you should start.
• A greenfield build started in mid-2026 likely finishes after mainstream support ends.
• Scoping and resourcing realistically need 9 to 12 months before go-live.
• “We’ll decide next quarter” is itself a decision, and usually the expensive one.

The calendar doesn’t care about your roadmap review cycle.

Three Approaches: How to Choose The Right One

Definitions aren’t the hard part. Knowing when each one fails is.

Greenfield is a clean rebuild. You stand up a new system, redesign your business processes against SAP standards, and migrate only the data you really need. Choose greenfield when your ECC environment is buried in Z-objects that encode old workarounds, when moving to public cloud (which requires it anyway), or when a merger is already forcing you to. Unfortunately, this path goes wrong consistently when teams underestimate how much history they actually have to bring along, run out of budget isn’t guaranteed, or when stakeholders and user training aren’t baked in.

Brownfield is a technical conversion of the existing system in place. The SNP migration meta-study shows that this is the most common choice for how to tackle SAP migration, and the appeal is obvious. The processes, configuration, and transaction history hold steady, but tend to fail quietly. Legacy ABAP that ran fine on a row-store database can degrade on HANA, and nobody might notice until month-end. Heavy modifications to core objects do not survive the Clean Core model. And a big-bang cutover takes every risk you have and stacks it into one weekend.

Hybrid, which SAP formally calls selective data transition, is where you hedge your bet. You move specific company codes or data domains into a new system and leave the rest in an archive. SAP advertises selective data transition as the best of both worlds. It makes sense in M&A-driven landscapes: multiple ECC systems, carve-outs, and dirty data you would rather clean early. The risk is when teams underestimate what it takes to run two systems in parallel, or don’t have the specialized tooling required.

Honestly, it’s not much of a judgment call. Here’s my own table I use when talking with teams and leadership:

Focus on Preparation

While you may argue that my next point is true in most projects, it holds true with SAP migrations. The technical conversion is the easy 20%. The preparation is the brutal 80%, even though it isn’t as fun to do.

So where do I start? The answer is always the SAP Readiness Check. I find it is a fairly honest mirror and gives me a lot of lift early on. It maps simplification items against the active configuration, runs custom code analysis through the ABAP Test Cockpit, flags incompatible add-ons, and spits out a HANA sizing projection. I pair that with a fit-gap analysis, e.g., a process-by-process walkthrough where I tag what changes, what stays, and what has to move to a BTP extension, and so on. Also, take note if any ABAP is still non-Unicode, because HANA won’t move until that’s sorted out.

The piece I usually worry about most is custom code, because that’s where the real effort hides.

My go-to analysis is SmartShift’s analysis of conversions, which found that 25% to 40% of custom objects are retirable before we even start, and that over 90% of the changes a conversion needs are technical, not functional.

Citing these numbers tends to open up the conversation and get people looking at what our starting point is. Most of what teams dread here is not architectural rethinking, but mechanical cleanup. The conclusion is usually to automate what we can instead of paying senior people to grind through it by hand. Run the usage analytics first, delete whatever nobody is calling, and let the tool do what it can.

One gotcha I watch for in this phase is the one that passes every check and is still broken. Beware the custom report that comes back syntactically clean, clears the ATC scans, and sits under a green Readiness Check. Make sure they actually render. If they fail, the usual culprit is code reading straight from the aggregate tables eliminated with S/4HANA. The logic is fine, but it just has nothing left to read after the data moves into the universal journal. My simple rule I carry into every prep phase is simple. Any custom object that reads SAP tables directly gets traced to the target data model during preparation.

The other thing that quietly eats timelines is data. The Hackett Group flags data migration as the work that starts too late and is usually the go-live bottleneck. Start as early as you can. Archive in the source system before you migrate, not after. Run two or three full mock migrations against representative data, and reconcile source against target every single time. Dodge the emergency.

Hard-Won Lessons

• The Readiness Check tells you what’s incompatible, but not what’s unused.
• Run usage analytics and delete dormant custom code before remediation, not after.
• Trace every direct-table-read custom report to the new data model during prep.
• Data archiving is a pre-migration activity, and treating it as post-go-live cleanup is how timelines slip.

Execution: SUM, Cutover, and the Big Bang Debate

Software Update Manager actually performs the conversion. I always emphasize that we should leverage its downtime-optimized mode, because it changes the cutover plan math. A shadow instance carries most of the upgrade work, custom code adaptation included. All this while production keeps running.

The big win is that the outage window shrinks to the final data switch. The Database Migration Option folds the move to HANA into that same procedure. I bake this into my normal planning because it means we are not running two separate high-stakes events back-to-back.

The tooling is the easy part, but big-bang flips the whole organization at once. It is faster, it keeps everyone aligned, and it’s the default for brownfield. The risk though, stacks into a single weekend, and that is (extremely) stressful.

On the other hand, you could choose phased rollouts by business unit or region. That tends to ease the load on the migration team and contains the damage if something breaks. Yes, it tends to lengthen the timeline and you will be running old and new side by side. Neither one is free, but when I can afford it, I lean towards the lower-risk, lower-stress approach.

KPMG lands in the same place in its migration dos and don’ts: smaller measurable steps versus the one heroic event. The only exception I make is when I’m dealing with a small, clean, single-entity brownfield, one where a well-rehearsed big-bang is truly the lower-risk path.

The key point there being “rehearsed.”

What Actually Changes and Why Your Old Reports Break

Some of what changes is cosmetic and some of it will genuinely hurt, so we need to make sure we can tell the two apart before go-live.

We all know the HANA pitch by now: in-memory, column-store, and yes, the speedy analytics. Unfortunately, none of that speed is guaranteed on poorly written ABAP. The gap between what people assume and the truth is where brownfield performance can come apart.

The change with the widest blast radius is the simplified data model. In ECC, financial data lived across separate FI, CO, CO-PA, and asset accounting tables that we reconciled at period end. In S/4HANA, the ACDOCA universal journal pulls all of it into one line-item table and the old aggregate and index tables are gone. The win is real-time reporting without the reconciliation step. The painful part is that we have to review every custom program and integration that read from those eliminated tables.

That last point with a high-risk severity is that ECC almost never sits by itself. It’s wired into EDI feeds, IDoc and RFC interfaces, middleware, and third-party applications. Many of these read SAP tables directly. The issue when the data model shifts underneath them is that the integrations do not throw an error. The takeaway is that integration testing is crucial and needs to be correctly scoped in the plan. You need a current interface catalog and end-to-end testing of every connected system before go-live.

The rest manageable, more or less. Fiori swaps the SAP GUI for a role-based browser interface, and I treat that as a behavior change for users. This is a real change management cost, not a lunch-and-learn. Embedded analytics provide real-time operational reporting without the extract step, though I wouldn’t count on it to replace BW for cross-system or historical reporting, so that investment does not just evaporate.

Also, the AI hooks through SAP BTP and Joule keep getting better. From what I’ve seen, Joule for Developers is slowly chipping away at the custom-code migration work that dominates the whole effort.

Go-Live is Not the Finish Line

Go-live really isn’t the finish line. If you treat it as such, then things tend to get expensive. Performance often degrades in the first 12 to 24 months with data growth and the poor assumptions made on cutover day didn’t quite hold up.

I put a performance review on the calendar at 3, 6, and 12 months. Gather data around the slowest custom reports and keep a line open to the people living in Fiori every day. The end-users feel the friction.

And make sure you get real data–real metrics, e.g., usage rates, error rates, helpdesk volume, and so on. If you’re not watching these data points, you won’t notice the slow bleed until it gets very expensive to fix.

Waiting Won’t Hold the Price Steady

I already covered the time you do not have. The cost is the other half of the bill, and it compounds if you wait.

The talent picture is where I see this bite first. The people who have actually run S/4HANA conversions are already few and far between. And the projections I trust put demand running 20% to 30% ahead of supply as 2027 gets closer. That gap is only going to increase stress and strain the budget.

Every quarter you wait, somebody else locks in the best people.

The teams that moved in 2022 and 2023 finished with deeper benches and better pricing. Those days are gone. The stat that tends to land hardest in budget conversations is ASUG’s: roughly half of projects now run over, with consulting fees the main driver. My risk mitigation heuristics push for more headroom in the budget as the project start get later. And I aim to bring on even more experienced SAP engineers as the risk increases.

To bring up a point hinted at in the introduction is another key facet: security.

A supported system gets patched every month. 2025 saw critical, actively exploited vulnerabilities in the SAP stack. On S/4HANA, you get those patches. On ECC past 2030, you get nothing. No patches, no remediation, just exposure. That directly equates to audit and insurance liability that grows every month the system stays in production.

The Takeaway

So let’s make this simple: stop arguing the approach in the abstract. Pull your real custom code count, your real data footprint, and your real cloud target, run them against the decision matrix.

This tells you whether you are greenfield, brownfield, or hybrid.

Then guard the preparation phase like it is the project, because it really is. The conversion itself is a weekend. The custom code triage, the data archiving, the mock migrations, and the change management are the months that decide whether finance closes on Monday. Start now, phase what you can, and treat 2030 as the penalty it is, not the deadline you are aiming at.