ECC to S/4HANA: how to choose your path, and when a bridge makes sense

Every SAP ECC customer is already choosing a path to S/4HANA, whether they've started or not. Waiting is a path too, and usually the most expensive one. Here is how the deadlines actually work, what each path costs you in time and risk, and the questions I ask before recommending one.

The deadlines, accurately

Two things are commonly misread. First, the 2033 option is not an extension for everyone. It's a paid cloud subscription, available to buy from 2028, that requires moving ECC into SAP's private cloud before the end of 2030 and completing the move to S/4HANA by the end of 2033. Second, none of these dates changes the real constraint: experienced SAP people will be scarce in 2029, when everyone who waited starts at once.

The four paths

Brownfield: convert the system you have

A system conversion moves your existing ECC system to S/4HANA in place. Configuration, custom code and your full history come along. It's usually the fastest route with the least change for users, but it carries your technical debt forward and needs a single, well-rehearsed cutover.

Greenfield: start clean

A new implementation rebuilds your processes on SAP's current standards and brings over master data and open items. It's the most change and usually the longest timeline, and it produces the cleanest system. It fits companies with heavy customization, several ECC systems to consolidate, or a real appetite to change how they work.

Selective data transition: choose what moves

The middle path builds a new or emptied system and moves only what you choose, such as certain company codes or years of history. It keeps valuable history while cleaning up the rest, but it needs specialist tools and more planning and governance than either extreme.

Bridge first: move now, convert later

Some companies move ECC as it is into SAP's private cloud first, then convert to S/4HANA as a separate project. It's the least disruptive step in the near term and hands infrastructure operations to SAP, but it doesn't remove the S/4HANA decision. It works when timing or team capacity is the real constraint, as long as the conversion date is set before you sign.

Typical ranges for a single mid-size system. Size, custom code, data volume and testing decide your actual timeline.

Five questions that decide it

1. How much of your custom code is actually used? Usage data from SAP's readiness tools often shows much of it never runs. Retire it before you move it.
2. One system or several? Multiple ECC instances push toward consolidation, which favors greenfield or a selective transition.
3. How much history do you truly need online? Regulators and auditors set the floor. Archiving can cover the rest.
4. How much change can the business absorb this year? Month-end close, peak season and other programs all compete for the same people.
5. What will you be licensing? In SAP's cloud subscriptions, cost follows users and what their roles allow. Cleaning up users and roles before the order is final avoids paying for access nobody uses.

RISE changes who runs what, not whether you need help

Moving into SAP's private cloud shifts infrastructure, operating system, database and technical Basis operations to SAP. Application work stays with you or a provider: functional support, custom code, interfaces, roles and security, testing and release planning. Map that split before you sign, or the gaps show up during your first serious incident.

What I'd do in the next 90 days

1. Run a readiness assessment: SAP's readiness check, a custom code analysis and an interface inventory.
2. Clean up users and roles before any commercial commitment.
3. Price at least two paths side by side, including a bridge, with timelines set around your blackout periods.
4. Ask about vendor funding. Programs sometimes offset assessment or migration costs when the scope qualifies.
5. Set the decision date, and if you bridge, the conversion date too.

The worst path is the one chosen by default in 2029.