Half of Your S/4HANA Programme Is Ordinary Software Work. You Are Paying SAP Rates for All of It.

What Actually Happens at the End of 2027?

Nothing switches off. That is the first thing worth saying plainly, because the panic in the vendor marketing implies otherwise. On 31 December 2027 mainstream maintenance for SAP ECC ends, and your system keeps running exactly as it did on the 30th. What stops is the flow of patches, security fixes and legal change packages, which for a payroll or tax-relevant module is a slow-acting problem rather than an instant one, and the day your auditors start asking a question you cannot answer well.

There are escape hatches, and they are narrower than they look. Optional extended maintenance runs to the end of 2030 at a premium on the maintenance base, and a private-edition transition option carries some large customers further still, out toward 2033. CIO's reporting on the analyst projections is the clearest public summary of where the installed base sits: roughly 14,000 of about 35,000 ECC customers had moved to S/4HANA by the end of 2024, or 39%, with Gartner projecting around 17,000 still on ECC when the 2027 date arrives and more than 13,000 still there past 2030. IDC's projection in the same piece has 40% to 45% of ECC users remaining on the legacy platform through 2027.

The other quiet deadline already passed. Compatibility Pack usage rights, which let converted customers keep running certain ECC-era functionality inside S/4HANA during a transition, ran out on 31 May 2026 after an extension from the original end-2025 date, as the 2027 deadline guides set out. For anyone mid-conversion, that removed a bridge that a lot of plans were quietly leaning on.

The honest framing came from a customer rather than a vendor. Catherine Jestin, EVP of Digital at Airbus, told an audience last December that if you talk to the CIOs in Europe who implemented ECC6, most of them will not be finished with the migration by 2030. Airbus runs multiple SAP generations at once, heavily customised with ABAP written over decades, and has already moved finance, materials management and its helicopter division. If an organisation with that budget and that much of the work behind it is talking about 2030, a mid-market manufacturer that has not started is not looking at a 2027 problem. It is looking at a decade-long one.

Why Is Half the Installed Base Still Standing Still?

Not denial. Arithmetic. A full conversion runs from about 18 months for a clean single-instance mid-market system to several years for a multi-country landscape, and the cost range reported in the same CIO analysis spans $2 million to $1 billion depending on size and customisation depth. That is not a licensing decision with an engineering tail. It is an engineering programme with a licensing trigger, and boards have been treating it as the former.

The track record does not encourage anyone to go first. Horváth's study of S/4HANA transformations found that 60% exceed budget and schedule, and two thirds of participants were dissatisfied with the quality of the result. That last number is the interesting one. Overrunning is common in large programmes. Overrunning and then not liking what you got is a design and delivery failure, not a scheduling one.

The wider ERP picture rhymes. A 2026 compilation of ERP implementation failure data, drawing on Panorama Consulting Group's 2026 ERP Report, puts the industry-wide failure rate against stated objectives at 68%, average budget overrun at 189%, average timeline extension at 25%, and the share of projects actually achieving their objectives at 32%. The root causes it ranks highest are absence of executive sponsorship at 31%, insufficient end-user training at 29%, scope creep at 26% and over-customisation at 23%. Read that list again: none of them is a software defect.

Data is where it usually bites first. Computer Weekly's reporting found S/4HANA data migration beset by poor and fragmented strategy, which matches what anyone who has run a cutover weekend already knows: the master data nobody owns is the thing that decides whether Monday works. Forrester's advice on getting S/4HANA migration plans under control lands in the same place, which is to scope by business outcome rather than by module, and to stop treating the conversion as a technical event with a date.

The result is a standoff. Analysts now openly describe the 2027 deadline as out of reach for most customers, which reduces the fear but does not reduce the work. Every year of delay compresses the same programme into a shorter window against a tighter labour market, and that is precisely the mechanism that turns a manageable engineering project into an expensive one.

The Half of the Programme That Isn't SAP Work

Here is the exercise that changes the budget conversation. Take the programme plan, and instead of sorting tasks by module or phase, sort them by the skill each one genuinely requires. One pile needs someone who knows SAP-specific things that cannot be learned from general engineering experience: how a conversion behaves, what the data model changed, how the finance postings work, what breaks in a specific industry solution. The other pile needs a senior software engineer who is good at legacy systems, APIs and data. In most programmes we have seen described honestly, the second pile is close to half the effort, and it is being billed at the first pile's rate.

Start with custom code, because it is the single biggest driver of conversion effort and the biggest source of self-deception. SAP's own analysis of customer systems, summarised in SAPinsider's guidance on preparing custom code for S/4HANA, finds that more than 60% of Z-code is never executed in production, and that over half of custom ABAP is either unused or non-compliant with S/4HANA standards. Deciding which objects are dead is analysis work supported by tooling. Rebuilding the ones that survive, outside the core, is application development in a normal language against a normal API, and that is not scarce expertise.

Then the interfaces. Every ECC system of any age sits at the centre of a web of point-to-point connections: warehouse systems, CRM, ecommerce, bank files, EDI partners, tax engines, BI extracts, that one Access database in a regional office. Converting a landscape means cataloguing all of it, deciding what becomes a modern API or event contract and what gets retired, then rebuilding and testing each one. That is integration engineering. The SAP-side endpoint knowledge matters at the boundary; everything else is contracts, retries, idempotency, monitoring and reconciliation.

Then the satellite applications, which is the part most business cases forget entirely. The approval app on people's phones, the shopfloor screen, the supplier portal, the customer self-service view, the internal reporting tools that read straight from ECC tables. When the underlying system changes, all of it changes with it, and none of it is SAP work in any meaningful sense. It is TypeScript, React, API gateways, identity and a design system, which is exactly what a dedicated development team builds week in and week out at a fraction of an ERP transformation rate.

And then the data track: extraction, cleansing, deduplication, the mapping rules, and the comparison harness that proves the new system produces the same numbers as the old one for the same inputs. That is data engineering with an unusually high stakes cutover attached, and it is the workstream where an extra pair of experienced hands has the highest marginal value in the entire programme.

Clean Core Means You Are Building a Distributed System

The strategic instruction SAP has been repeating since 2023 is clean core: stop embedding custom logic inside the ERP, and move it outward through defined extensibility tiers, from key-user configuration through developer extensibility to side-by-side applications running on the platform next to the core rather than inside it. Current clean core guidance walks through those levels and the decision rules for choosing between them.

It is good advice, and it has a consequence that rarely makes it into the steering committee deck. A side-by-side extension is not an SAP object that happens to live elsewhere. It is a separate application, with its own runtime, deployment pipeline, authentication, secrets, logging, error budget, dependency updates and cloud bill, talking to the ERP across a network boundary that can be slow, rate-limited or briefly unavailable. The extension pattern itself is well documented. What is under-documented is that adopting it converts a monolith problem into a distributed systems problem.

That conversion is where a lot of clean core programmes quietly go wrong. The extension apps get staffed by functional consultants who have never had to reason about eventual consistency, retry storms, schema versioning across two release trains, or what happens to an in-flight approval when the core is down for a maintenance window. The code compiles and demos beautifully. Six months later it is the thing that pages someone at 03:00 on a month-end close, and nobody on the programme owns operability because operability was never in anyone's statement of work.

The defensible version is to treat the extension estate as a product from the first day. Contracts before implementation, versioned and published, so both sides can move independently. Idempotent writes, because the core will time out and something will retry. Observability that spans the boundary, so a failed purchase requisition can be traced from the mobile screen through the extension to the ERP without three teams comparing screenshots. Cost attribution per extension, because the platform bill is nobody's line item until it is suddenly everybody's problem. This is platform and DevOps engineering, it is a well-bounded piece of work, and it competes for exactly the people your conversion is already consuming.

Can the AI Do the Remediation?

Partly, and the honest version of the answer is more useful than either the vendor pitch or the reflexive scepticism. SAP has shipped agentic capability into the ABAP toolchain: Joule for Developers can run readiness checks across entire custom code packages, interpret and categorise the findings, and apply a mix of deterministic quick fixes and AI-generated changes carrying confidence scores. For a landscape with tens of thousands of custom objects, that is a genuine step change in the inventory and triage phase, which used to be months of tedium.

It does not, however, remove the constraint. It moves it, in exactly the way the wider coding agent story has moved it everywhere else: generation gets cheap, and verification becomes the bottleneck. A tool that proposes ten thousand remediations creates ten thousand things a human has to accept or reject, and the acceptance decision on a finance-relevant Z-program is not a code review, it is a business risk decision. Teams that treat the confidence score as an approval will find out at cutover whether it was.

There is also a category of judgement no model can make for you, because the information is not in the code. Whether a Z-report still matters is a question about who reads it, what decision it feeds, and whether the person who commissioned it in 2011 has retired. Whether a custom pricing routine can be replaced by standard functionality is a question about whether the business is willing to change a process it has run for fifteen years. This is organisational archaeology, and it is done with interviews, usage telemetry and stakeholder meetings, not with a static analyser.

The working pattern is straightforward. Let the tooling do inventory, classification and mechanical fixes at volume. Put humans on retire-versus-rebuild decisions and on anything touching money, tax, safety or a regulator. And require a characterisation test before any remediation is accepted, so that whatever the object does today is captured as executable behaviour before anyone changes it. That last rule is the one that most reliably separates programmes that finish from programmes that keep discovering things in UAT.

Why the Rate Card Is the Real Constraint

The labour market is doing what labour markets do when a fixed deadline meets a fixed supply of specialists. A 2026 freelance day rate guide for European SAP consultants puts senior consultants with five to ten years of experience at €800 to €1,000 a day and expert or architect profiles doing S/4HANA migration and transformation work at €1,000 to €1,500, and migration advisories note that day rates have climbed 30% to 50% against a few years ago, with the squeeze tightening through 2026 and 2027 as the holdouts all start at once.

Supply is not going to rescue anyone. Recruitment analysis of SAP talent shortages in DACH and France describes a convergence of migration deadlines, AI operationalisation and a retiring ABAP generation, against German labour data showing well over a hundred thousand unfilled IT roles, with SAP profiles consistently among the hardest to source. The steepest premiums sit on the platform and integration developers, which is to say on precisely the skills the clean core strategy has just made mandatory.

Now put the two halves together. If a meaningful share of your programme is React screens, REST plumbing, data pipelines and test automation, and all of it is being delivered by a partner whose blended rate is set by the scarcity of finance conversion specialists, you are paying a specialist premium for general engineering. On a team of ten running for eighteen months, that mispricing is not a rounding error, it is a seven-figure line item that nobody ever decided to spend, because the work was never separated out to be priced on its own.

The fix is unglamorous: unbundle. Keep the scarce expertise on the scarce work and buy the rest at what the rest is worth. A senior full-stack or integration engineer in Serbia costs a fraction of an S/4HANA transformation contractor day rate, shares the full European working day, and is entirely capable of rebuilding a supplier portal or an EDI interface against a documented contract. StepTo staffs senior-led nearshore teams by name onto a client context rather than rotating people through a shared bench, which matters in a programme where continuity of context across an eighteen-month conversion is most of the value.

One caution worth stating, because it is the failure mode of naive unbundling: the split has to follow real seams. Handing an outside team a workstream that turns out to need a conversion specialist on every second question produces coordination costs that swamp the saving. Interfaces with published contracts, satellite applications with their own repositories, and test automation are clean seams. Anything that requires sitting inside the core configuration is not.

The Roadmap Freeze Nobody Puts in the Business Case

There is a cost in every ERP conversion that never appears as a line item, and it is usually the largest one. For the duration of the programme, the organisation's senior engineering attention is fully committed. The architect who would have designed the new pricing service is running interface workshops. The two best backend engineers are writing extraction logic. The product roadmap does not get cancelled, it gets quietly deferred, quarter by quarter, until an eighteen-month conversion has cost two years of product velocity.

Competitors do not pause while you convert. Neither do customers, and in a market where an increasing share of buying decisions turns on the quality of the digital surface rather than the ERP behind it, two years of frozen roadmap is a strategic cost that dwarfs the difference between two implementation quotes. The organisations that come out of these programmes strongest are not the ones that converted fastest, they are the ones that kept shipping while they converted.

The way to keep shipping is structural, not heroic. Run two tracks with separate teams and separate accountability. The internal team owns the core: process design, configuration, finance, the decisions that require institutional knowledge and cannot be delegated. A second team, staffed externally, carries the surrounding estate, the satellite applications, the interface rebuilds, the test automation, and the ordinary product roadmap that must not stop. The two tracks meet at published contracts and a shared release calendar rather than in a daily coordination meeting.

This is the shape senior augmentation is genuinely good at, and it is worth being explicit about why the timezone matters more here than in ordinary product work. A conversion programme generates decisions continuously, and most of them are small, urgent and blocking: which field maps where, whether this exception is real, whose approval is needed. A team that shares your working day resolves those the same morning. A team nine hours away resolves them tomorrow, and in a programme with a hard cutover date, a queue of one-day decisions is how a schedule slips without anyone doing anything wrong.

Plan for after go-live too. The satellite estate you build during the programme does not stop needing engineers on the Monday after cutover, and the internal team will be consumed by hypercare for months. Continuity of the external team through the stabilisation period is worth negotiating up front rather than discovering you need it in week two.

Test Automation Is the Deliverable You Will Wish You Had Started With

Ask what proportion of a conversion budget goes to testing and the answers cluster embarrassingly high, because the surface being tested is not the ERP alone. It is every business process end to end, across every interface, for every country variant, at production data volumes. Most organisations do this with people: an army of business users in a room for six weeks, executing scripts in a spreadsheet, and a defect log that grows faster than it is closed.

That approach has two defects of its own. It is slow, which means it happens once, late, when the cost of a finding is at its maximum. And it is not repeatable, so the second dress rehearsal costs as much as the first, and the regression suite you needed for the next release does not exist when the programme disbands. With only 32% of ERP implementations achieving their stated objectives, the mechanism behind most of the shortfall is rarely an untested feature. It is an untested combination, and combinations are what manual scripts miss.

The asset that actually de-risks the cutover is a dual-run comparison harness: feed the same inputs to old and new, compare the outputs, and make the differences a report someone reviews every morning. Every discrepancy is either a defect or a deliberate process change, and forcing that classification early is what stops the go-live weekend from becoming a discovery exercise. Building it is pipeline and automation engineering, it can start long before configuration is finished, and it pays for itself the first time it catches a rounding difference in tax that would otherwise have surfaced in a customer invoice.

Around that harness sits the ordinary work of automated regression across the interface estate and the satellite applications, plus performance testing at real volumes rather than at demo volumes. None of it needs conversion expertise. All of it needs disciplined QA automation engineers who will still be maintaining the suite after go-live, which is the argument for staffing it as a durable capability rather than as a phase of the programme.

How Should You Split the Work?

Weeks one to four: inventory, before anyone argues about approach. Run the custom code analysis and get the list of objects that have not executed in production in the last year. Catalogue every interface with its owner, protocol, volume and criticality. Register every satellite application, including the ones IT does not officially know about. This is cheap, it is mostly tooling plus interviews, and it converts a debate about strategy into a list with counts on it.

Weeks five to eight: classify. Tag each item retire, replace with standard, or rebuild. Then tag each rebuild with the skill it genuinely needs: conversion specialist, general senior engineer, data engineer, QA automation. That second tagging pass is the one that produces the number this whole article is about, and it is usually the first time anyone in the programme sees how much of the plan does not require the scarcest people on it.

Weeks nine to twelve: stand up the second track. Give the non-specialist workstreams their own team, their own repositories and their own delivery cadence, and make the boundary a published API contract rather than a shared backlog. Start the dual-run comparison harness in the same window, because everything downstream gets safer once it exists, and because it is the workstream with the longest lead time and the least visible progress in month one.

Through the rest of the programme: hold the seam. The pressure to pull the second team into core configuration work will be constant and will always be justified by an urgent deadline. Every time it happens, the cost advantage and the parallelism both erode, and you end up with one large team billed at specialist rates again. Protect the contract boundary the same way you would protect a service boundary in production, because that is functionally what it is.

If your organisation has neither the bench nor the appetite to run two tracks, the pragmatic move is to scope the second track as an external deliverable with its own owner, its own budget and its own acceptance criteria. That is a well-bounded engagement, it is measurable, and it does not require anyone to reorganise the core programme to accommodate it. It is also, not incidentally, the shape of engagement a custom software partner can commit to on outcomes rather than on hours.