ECC to S/4HANA: the interfaces nobody budgets for

The date that sets the plan

SAP ends mainstream maintenance for ECC on 31 December 2027. Extended maintenance is available for an additional fee, but it buys time, not interfaces. Every system that exchanges data with ECC today will have to exchange it with S/4HANA or be retired, and the organisations that own the other end of those connections work to their own calendars, not yours.

Why the interface line comes in low

The estimate is usually built from what the programme can see. Four things sit outside that view.

• Point-to-point connections. An integration platform's catalogue only knows about the flows that run through it. RFC calls from a warehouse system, IDocs sent straight to a supplier, files collected from a server by a scheduled job, and uploads through custom programs often predate the platform and were never moved onto it.
• Custom code at the edges. Many ECC interfaces rely on user exits, custom IDoc segments and bespoke programs that shape data on the way in or out. S/4HANA changes some of the structures they touch: customers and suppliers are maintained as business partners, and finance and controlling postings meet in a single journal table. An interface that reads or writes those structures directly has to change, even if the system at the other end does not.
• The other end. The bank, the payroll bureau, the logistics provider, the tax engine and the EDI network each have their own change windows and test environments. Their lead times, not yours, set the dates.
• Testing by line, not by system. A connection is not ready because a message arrives. It is ready when it has run alongside the old one and the records on both sides match. That takes elapsed time, and it is rarely in the estimate.

Count before you commit

Before the business case is signed, count the interfaces. Not an estimate from one team, but a count from three directions:

• From ECC itself: partner profiles for IDocs (transaction WE20), RFC destinations (SM59), and background jobs that read or write files (SM37).
• From the integration platform: every flow that touches ECC, whichever direction it runs.
• From the business: every file, spreadsheet and rekey that finance, procurement and HR use to move data in or out.

Then reconcile the three lists. Anything that appears on one list and not the others is an interface your plan does not yet include.

Give each interface a route

Each interface on the count takes one of four routes, and each route has a different cost.

• Retire. The process moves into standard S/4HANA, or the system at the other end is going. The cheapest route, but only once the business owner has agreed it in writing.
• Re-point. The payload and its structure still work, and only the endpoint changes. It still needs testing.
• Rebuild. The structure has changed, or the interface is point-to-point code that should move onto the integration platform you already license.
• Replace. A standard API or connector now does the job, and the custom interface can go.

A count with a route for every line gives you an interface budget built from evidence, rather than a percentage added to the ERP budget.

Sequence lines, not systems

With a count and a route for each interface, cutover can be planned one process line at a time. Each line is rebuilt, run in parallel with the old one and reconciled record by record, and it switches over only when both sides match. A single cutover weekend puts every interface risk into the same two days, when the fewest people are free to deal with the consequences.

Three questions for your programme team

1. How many interfaces touch ECC today, and how was that number produced?
2. How many run point-to-point, and who owns the far end of each?
3. Which ones post to the ledger, and how will we prove they reconcile after cutover?

If the answers are estimates, commission the count before the budget is set. An interface found during a review is a line in the plan. One found in user acceptance testing is a delay.