One ECC Instance, a Few Hundred Users, and Custom Code Nobody Can Explain? You Don’t Have a Migration Problem.

You have an implementation decision. And if you start it in Q1 2027, you haven’t started it.

Before you read on – is this article about you?

This is written for one specific kind of SAP customer. You’ll know within thirty seconds whether that’s you.

• You run one production ECC instance (or two, and one of them is a legacy acquisition nobody wants to talk about)
• Your user population is in the hundreds, not thousands
• Your scope is broadly finance, procurement and HR – not a deeply industry-specific core like process manufacturing, utilities billing or clinical systems
• Your custom code exists because ECC made it easy, not because your business genuinely operates differently from your competitors
• You operate in one country, or a handful
• Your IT team is small enough to name in one breath, and owning upgrades forever is nobody’s ambition

Four of more of those? Read on – the standard 2027 advice is not written for you, and following it will cost you money.

Fewer than four? You’re probably in genuine migration territory, and the conversion-versus-selective-transition debate really does apply. This article will still be useful, but the timeline maths in the middle is the part worth your time.

Most of the noise about the December 2027 deadline is written for the wrong audience.

It’s written for the 5,000-user manufacturer with 4,000 Z-programs, three ECC instances and a decade of accumulated exceptions. For them, the conversation is genuinely about migration: brownfield, bluefield, custom code remediation, selective data transition. It’s hard, it’s expensive, and it’s why the analyst commentary reads the way it does.

But that isn’t most SAP customers.

If you’re running a single ECC instance, a few hundred users, finance and procurement plus perhaps HR, and a custom code estate that grew because ECC made it easy rather than because your business genuinely works differently – you’re being sold a problem you don’t have.

You don’t need to migrate. You need to implement.

The framing that costs smaller customers money

The default advice for an ECC customer is “convert your system.” It’s the path of least organisational resistance: nothing changes, the processes survive, nobody has to be told their spreadsheet is going away.

The trouble is that a conversion carries everything forward – including the reason your finance close takes eleven days and your requisition-to-PO cycle has four manual touchpoints. You pay for the migration, you pay for the code remediation, and at the end you arrive at a modern platform running your 2011 process design.

For a smaller organisation, that’s the expensive option twice over. You take on the longest timeline and you inherit the technical debt.

The alternative is a new implementation on SAP Cloud ERP – the public cloud edition, delivered through GROW with SAP. You keep your data, your chart of accounts logic, your supplier and customer masters. You leave behind the modifications nobody can explain.

The timeline difference is not marginal. Industry guidance, and our experience, puts well-scoped greenfield programmes at 12–18 months, and large private-cloud transformations at 12–24 months. Public cloud implementations delivered through GROW are commonly quoted at 4–9 months, with 3–6 months standard for straightforward scopes. SAP now provides more than 20 AI assistants from day one on GROW, with a toolchain explicitly designed to compress time to go-live.

That difference is the entire argument.

The maths nobody puts in the brochure

Here’s the part that tends to end the debate in a boardroom. Work backwards from 31 December 2027 using a realistic UK delivery profile – not a vendor slide.

Stage	Realistic duration
Business case, budget approval, board sign-off	2–3 months
Partner selection and procurement	2–3 months (longer via public sector frameworks)
Mobilisation, Digital Discovery Assessment, system provisioning	1 month
Fit-to-standard, configuration, extension build, integration	4–6 months
Data migration, testing, parallel run, cutover	2–3 months
Hypercare and stabilisation	2 months

That’s 13 to 18 months for a well-run public cloud implementation, before a single day of contingency.

Now add the constraint that finance directors actually live with: you don’t cut over whenever you like. Most UK organisations go live at a period boundary, and realistically at the start of a financial year. That single constraint collapses your options from “sometime in the next eighteen months” to two specific dates.

The thirty-second date calculator

The rule: take your target go-live. Subtract 18 months – 16 to deliver, 2 for the contingency you will need. That’s your decision deadline. Not your kick-off date. The date the board has to have said yes and the budget has to exist.

Now find your financial year-end:

Your year-end	Last go-live that keeps you on mainstream maintenance	Decision was needed by	Next realistic window	Decide by
31 December	1 January 2028	July 2026	1 January 2029	July 2027
31 March	1 April 2027	October 2025	1 April 2028	October 2026
30 April	1 May 2027	November 2025	1 May 2028	November 2026
30 June	1 July 2027	January 2026	1 July 2028	January 2027
30 September	1 October 2027	April 2026	1 October 2028	April 2027

Read that table honestly and the conclusion is uncomfortable: for most year-ends, the window that keeps you inside mainstream maintenance has already closed.

If your year-end is 31 December, you are right on the edge. Anything else, and you are almost certainly planning a go-live that lands after 31 December 2027.

Two caveats worth knowing before you panic or relax:

• A half-year cutover buys back six months. Plenty of organisations go live at their half-year rather than their year-end. It’s harder – you’re carrying comparatives across two systems – but it’s a legitimate way to pull a 2028 date back into 2027 if the appetite is there.
• Missing the date is survivable. Not knowing you’ve missed it isn’t. Extended maintenance exists precisely for this. The organisations that come out of 2028 well are the ones that costed the overlap deliberately, told their auditors, and picked a window while they still had a choice of partner. The ones that will struggle are the ones who discover the gap in November 2027.

And to be clear: if you’re only opening the conversation in Q1 2027, you are not starting a programme. You are booking a place in a queue.

The bit that will bite before the deadline does

Deadlines don’t hurt because of the date. They hurt because everyone hits them at once.

Gartner projects that around 17,000 ECC customers will still not have migrated by December 2027 – roughly half the original installed base – with around 13,000 still on ECC in some form by 2030. That is a very large number of organisations competing for the same finite pool of experienced consultants, in the same eighteen months.

Smaller customers lose that competition. Not because their programmes are less important, but because a £400k implementation doesn’t outbid a £4m one for the same delivery team. Organisations engaging partners in the second half of 2026 are already encountering compressed timelines that introduce delivery risk before the project even starts.

The practical consequence: your choice of partner narrows, your day rates rise, and the flexibility you’d normally rely on when something slips simply isn’t there.

When public cloud is the right answer — and when it isn’t

I’d rather be straight about this than sell you something that doesn’t fit.

SAP Cloud ERP (public) is likely right for you if:

• Your ECC customisations exist for historical convenience, not genuine competitive difference
• You operate in one country, or a small number covered by SAP’s delivered local versions (there are around 59 out of the box)
• Your finance and procurement processes are recognisably standard, even if they’re currently executed unusually
• You have a lean IT function and no appetite to own upgrades ever again
• You want SAP’s Business AI capability without a separate programme to earn it

It probably isn’t right for you if:

• You’re in a heavily regulated or highly specialised industry with deep process requirements
• You genuinely need core ABAP modification – public cloud allows key-user extensibility and side-by-side BTP extensions, but not traditional core modifications
• You cannot live with SAP updating all tenants on a fixed schedule twice a year, with no option to defer
• Your data residency or isolation requirements rule out multi-tenancy

Note that the constraint list is mostly about standardisation, not size. Clean core isn’t a limitation you tolerate in the public edition – it’s the mechanism by which you stop paying for upgrades for the rest of the system’s life.

What I’d do if I were you

1. Establish your real go-live window first. Year-end, period boundary, peak trading, statutory reporting. Everything else is planned backwards from that date, not forwards from today.
2. Count your custom code, then justify it. Not “can we rebuild it” – “would we commission this today?” In smaller estates, the honest answer is usually no for most of it.
3. Get a fit-to-standard assessment before you buy anything. A structured scoping exercise against SAP’s standard processes will tell you in weeks whether public cloud fits, and it costs a fraction of finding out during Realize.
4. Cost extended maintenance as a deliberate option, not a fallback. If your window genuinely lands in 2028, price it, plan it, and tell your auditors. Drifting into it is what damages credibility.
5. Secure delivery capacity earlier than feels comfortable. The constraint in 2027 will not be software. It will be people.

The 2027 date is doing something useful, even if it doesn’t feel like it. It’s forcing a question that a lot of smaller SAP customers have deferred for a decade: do we actually run our business differently, or have we just been running our software differently?

If it’s the second one, the public cloud implementation isn’t the compromise option. It’s the shorter, cheaper, and more finishable one — and it’s the only route that still fits comfortably inside the window.