AboutServicesWorkArticles
← Back to Services

ERP Modernization & SAP ECC Exit: The Engineering Around the Migration Nobody Scoped

Every ERP migration has two projects inside it. There is the one in the plan (the new system, the process design, the system integrator), and there is the one that surfaces in month four, when somebody counts the interfaces.

That second project is ours. The eighty custom integrations, the reports that finance depends on and nobody owns, the warehouse terminals talking to a database view, the customer portal reading straight from the old tables, the twenty years of data that has to arrive in the new system in a shape it will accept. It is rarely in the original scope and it is frequently what determines the date.

Why this is on the calendar now

Mainstream maintenance for SAP ECC 6.0 ends on 31 December 2027. Extended maintenance can carry a company to the end of 2030, at a premium and with reduced scope. A large share of the installed base has not started, migrations commonly take eighteen to thirty-six months, and the partners and hyperscaler capacity to do them are being booked now.

The same pressure exists away from SAP. Oracle EBS customers face their own support horizon, Dynamics AX and NAV installations are being pushed towards Business Central and Dynamics 365, and a long tail of companies run an ERP that was heavily customised a decade ago by people who have since left.

Whatever the destination, the shape of the problem is the same: the ERP is not an island, and the things attached to it are usually undocumented.

What we do

Interface discovery and inventory

Before anything can be planned, someone has to establish what actually talks to the ERP. We do that empirically (reading database logs, network traffic, scheduled jobs, integration middleware configuration and source code), rather than by circulating a questionnaire and hoping.

The output is an inventory of every interface with its direction, protocol, frequency, data volume, business owner where one can be found, and an assessment of whether it must be rebuilt, can be retired, or can be adapted. Clients regularly find between two and five times as many interfaces as they expected, and a meaningful number turn out to serve nothing at all.

Rebuilding the integration layer

We rebuild the interfaces that have to survive, and we prefer to rebuild them against an abstraction rather than pointing them at the new system directly. An integration layer between your satellite applications and the ERP means the next migration (and there will be one) does not repeat this exercise. It also lets you move applications across in waves instead of a single cutover weekend.

Work here spans IDoc and BAPI interfaces, OData services, SOAP endpoints from an earlier era, flat file and SFTP exchanges that still run half of European B2B, message queues, and modern REST APIs on the new side.

Data migration engineering

Extraction, cleansing, transformation, load and (the part usually underestimated) reconciliation. We build the migration as repeatable code, not as a one-off script, so it can be run dozens of times against increasingly clean data with the results compared automatically each time.

Reconciliation is where credibility lives. Finance will not sign off on a migration because the load succeeded; they sign off because balances match, counts match, and the differences that remain are explained and accepted in writing.

Custom applications that outlive the ERP

Most companies have applications built around the old ERP that encode something the ERP could not do: a configurator, a pricing tool, a shop-floor terminal, a customer portal, a planning spreadsheet that became load-bearing. Some should be retired into the new system's standard functionality. Some are genuine competitive advantage and should be rebuilt properly as applications in their own right, no longer welded to a database schema that is about to change.

We help you tell the two apart, and then build the ones worth keeping.

Reporting and the shadow data estate

Every long-lived ERP grows a layer of reports, extracts and spreadsheets outside it. These break loudly at cutover and they are almost never in the plan. We inventory them, identify the ones the business genuinely runs on, and rebuild them against the new data model or against a reporting layer that insulates them from it.

Decommissioning and data retention

The old system holds records you are legally required to keep for years after it is switched off. Keeping ECC running read-only for a decade is an expensive way to satisfy a retention rule. We build extraction into an accessible archive with the search and export paths auditors and tax authorities actually ask for, so the old system can be turned off.

What this is not

We are not an SAP functional consultancy. We do not configure FI/CO, we do not design your process templates, and we are not the partner who runs the S/4HANA programme. Those are specialist roles and you should engage a specialist for them.

We are the engineering team that works alongside that partner on everything the ERP touches but that the ERP programme does not cover. In practice we are engaged either directly by the client to protect their side of the programme, or as a subcontractor to the systems integrator running it.

If you are looking for someone to own the whole S/4HANA conversion, we will tell you we are not that, and we would rather do it in the first conversation than the third.

Where we work

Alongside an S/4HANA programme: integration rebuild, data migration engineering, satellite application work, and decommissioning of the legacy estate.

Migrations away from SAP entirely: to Odoo, Dynamics 365 Business Central, ERPNext, Netsuite or an industry-specific system, most common among mid-sized companies for whom S/4HANA is disproportionate. Here the integration and data work is the majority of the project.

Oracle, Dynamics AX/NAV and Infor estates facing the same lifecycle pressure with less attention on them.

Companies not migrating at all, who have decided to stay put for now and need the surrounding systems modernised, the interfaces made supportable, and the risk reduced while they wait.

How engagements run

Discovery, three to six weeks. Interface inventory, data quality assessment, satellite application review, and a written report on what the surrounding estate actually looks like. This is deliberately available as a standalone engagement: several clients have used it to renegotiate the scope and the price of a systems integrator's proposal, which more than paid for it.

Build, running in parallel with the main programme: integration layer, migration pipeline, application rebuilds, on your schedule and against your cutover date.

Cutover support, including the rehearsals, the reconciliation runs and the hypercare period where the interfaces that were never quite exercised in test finally are.

Decommissioning, once the new system is stable and the archive has been signed off.

Technology

Java, .NET, Python, Node.js and PHP on the application side; SAP interface technologies including IDoc, BAPI, RFC and OData; middleware including MuleSoft, Apache Camel, Kafka and Azure Integration Services; SQL Server, Oracle, DB2, HANA and PostgreSQL; AWS and Azure. Where the existing estate runs on something older (Delphi, VB6, PowerBuilder, COBOL adjacent to the ERP), that is familiar ground rather than a surprise.

Frequently asked questions

When exactly does SAP ECC support end?

Mainstream maintenance for SAP ECC 6.0 ends on 31 December 2027. Extended maintenance is available to the end of 2030 at additional cost and with reduced scope. Confirm the specifics for your enhancement pack and contract with SAP directly, since terms differ.

We have already appointed a systems integrator. Where do you fit?

Beside them. The integrator owns the ERP conversion; we own the estate around it: interfaces, data engineering, satellite applications, reporting and decommissioning. That division is common, it keeps the integrator focused on the system they specialise in, and it means someone is accountable for the parts that usually fall between contracts.

Is it realistic to move off SAP entirely?

For some companies, yes. It depends on how much of what you do is standard, how much sits in customisation, and whether a smaller platform can carry your volume and your regulatory requirements. It is a genuine option for mid-sized manufacturers and distributors and a poor one for complex multinational groups. The discovery phase gives you the evidence to decide rather than the argument.

How long does the interface inventory take?

Three to six weeks for most mid-sized estates. It is largely bounded by access: how quickly we can get to logs, source code, middleware configuration and the people who remember why something exists.

Can you keep the old system available for audit after we switch it off?

Yes. We build extraction into a queryable archive with the retention period, search and export capability your auditors and tax authorities require. That is usually far cheaper than keeping a licensed ERP running read-only for a decade.

What if we decide not to migrate yet?

That is a legitimate decision, particularly with extended maintenance available to 2030. The work then is reducing risk in the meantime: documenting and stabilising interfaces, retiring what nothing uses, and modernising the applications around the ERP so that when you do move, the surrounding estate is not the obstacle.

Get started

Tell us what you run, where you are in the decision, and whether an integrator is already appointed. We will tell you what the surrounding estate is likely to cost you and where we would start.

Contact us to scope an interface and data discovery.

Related services

Ready to get started with this service?

Get in Touch
← Back to All Services