Roni Rechter

When SAP IS-U Migration Stops Being the Lower-Risk Option

Disclosure before anything else: I lead AI programs at MaxBill, which sells billing software that competes for some of the work described below. Before that I spent years running billing implementations for utilities, EV charge point operators and telecoms across Europe and the US. That is where I learned that the SAP IS-U migration decision usually gets made for reasons that have nothing to do with risk.

So I have a conflict. Read accordingly. But notice that almost everything published on SAP IS-U end of life has one too, running the other direction. Search the topic and you get page after page from firms whose revenue is S/4HANA Utilities implementation. They are competent and often right. They also cannot write the sentence "you should consider leaving SAP," because that sentence has no line item.

This is the SAP IS-U migration vs replacement decision written by someone with the opposite bias, including the cases where staying with SAP is clearly correct. There are several.

The window is 2026, not 2027

The date everyone quotes is wrong by about two years, in the direction that hurts.

Mainstream maintenance for SAP Business Suite 7, the platform underneath classic IS-U, ends 31 December 2027. Optional extended maintenance carries support to the end of 2030 at a maintenance surcharge, reported at around two percentage points. After that, no standard support.

Now put a delivery timeline against it. IS-U to S/4HANA Utilities transformations are routinely quoted at 18 to 36 months, and that is the implementation, not the run-up. Add the business case, target architecture work, procurement and partner selection in front of it and you are looking at another six to twelve months before anyone writes a line of configuration.

Work backwards. A decision reached in early 2027 puts go-live somewhere in 2029 or 2030, which means you are paying the extended-maintenance surcharge through the whole delivery and betting the project doesn't slip past the point where support ends entirely. A decision reached in 2026 gives you the first comfortable path.

There is a second constraint that gets less attention and matters more. The S/4HANA Utilities consulting market is tight and the specialists are scarce, and every utility on IS-U is reading the same calendar. Capacity is being allocated now. Deciding late doesn't just compress your timeline, it determines which team you get.

If you operate in the UK there is a third pressure stacking on top: MHHS is forcing CIS decisions across suppliers at the same time as the IS-U replacement wave, and Kraken has just gained the structural independence to sell as a neutral platform rather than a competitor's software. Three forces converging on the same procurement cycle.

None of this dictates one target architecture. It does mean the decision itself has a deadline that arrives well before SAP's.

Five paths, not two

The framing that causes bad decisions is "migrate or replace." There are five, and two of them are usually missing from the shortlist.

1. System conversion (brownfield). A technical move that carries the existing system, processes and data model forward, subject to mandatory remediation. S/4HANA runs only on HANA, the data model is simplified, Business Partner becomes the leading master data entity through Customer-Vendor Integration, and the interface shifts to role-based Fiori apps. Even a "technical only" conversion touches device management, billing, FI-CA and EDM.

Right when: your processes fit, custom code volume is manageable, data quality is good, and regulatory history has to stay operationally live.

Failure mode: the lower delivery burden is real and the lower total cost isn't. You have paid to carry twenty years of accumulated exception handling onto a platform that will be expensive to change for the next ten.

2. Selective data transition. Retain chosen business objects and history, redesign everything else. The most technically demanding option and often the most honest one.

Right when: parts of the estate are excellent and parts are unsalvageable, and you can articulate which is which by object.

Failure mode: nobody owns the boundary. The scope of "selective" gets renegotiated every sprint.

3. Greenfield S/4HANA Utilities. New process and data design, still SAP, no assumption that legacy configuration or custom code moves.

Right when: SAP competence is a strategic asset, FI/CO integration runs deep, and the problem is your processes rather than your platform.

Failure mode: greenfield is a redesign programme wearing a migration budget. Scope growth is the default outcome, not the risk.

4. Non-SAP CIS replacement. The option the literature omits. Kraken, Gentrack, powercloud, MaxBill and others are all live alternatives, and Kraken's demerger from Octopus at an $8.65bn valuation has made this a different conversation than it was two years ago. The spun-out company is contracted to serve more than 70 million accounts across 27 countries, with over $500m in contracted annual revenue.

Right when: your meter-to-cash processes are commodity, not differentiating, the SAP estate's value is mostly sunk, and you need change delivery measured in weeks.

Failure mode, and I say this selling into it: deep SAP financial integration is the thing that kills these projects. If FI-CA is load-bearing across your finance close, if your market communication is built, working and audited, or if in-house SAP skills are your only real IT capability, a non-SAP CIS moves your integration risk instead of removing it. It also puts you in a smaller vendor ecosystem. Both of those are costs, and neither shows up in a demo.

5. Deliberate hold with phased coexistence. Run IS-U alongside a target platform for a defined window, with system-of-record ownership assigned per domain and a dated retirement plan.

Right when: continuity requirements are severe, data remediation is unfinished, or the organisation cannot absorb the change yet.

Failure mode: coexistence without exit criteria stops being a strategy and becomes two systems you run forever. It removes cutover risk and adds synchronisation, reconciliation and operating complexity every day it runs. Time-bound it in writing or don't do it.

Data quality can reverse the recommendation

This is the part that decides projects and gets one paragraph in most vendor material.

Three defects show up in nearly every IS-U estate I have worked in: duplicate business partners, incomplete move-in and move-out histories, and device-to-location relationships that no longer resolve. The volume varies. The presence doesn't.

Run the arithmetic on the first one. A supplier with 1.2 million business partners and a 4% duplicate rate is holding roughly 48,000 records that need adjudication. Adjudication means a human deciding which of two records owns the contract, the balance and the dispute history, because no rule engine gets that right without supervision. At even five minutes each that is around 4,000 hours of work that has to complete before your first credible mock migration, not after.

Those same 48,000 records mean opposite things depending on target path, and that is what flips the decision.

Under conversion, you must cleanse them and preserve the legacy relationships, because operational continuity depends on the old model still being true. You pay full remediation cost and buy nothing structurally new. The duplicates come back, because the process that created them came with you.

Under replacement, the same defects become the evidence for redesigned identity, relationship and stewardship rules. You still pay for remediation, because that cost is not avoidable on any path, but you pay it into a target where the defect class is closed instead of reproduced.

So data profiling is not a downstream workstream. It is an input to the path decision, and running it after you have picked the path puts the two in the wrong order.

The trap to name explicitly: no new platform fixes data. Migration tooling moves what you give it. Whoever owns the source data owns the outcome, and if nobody is accountable for that by name, the platform question is premature.

Tool choice is downstream of the target-state choice

BODS or EMIGALL is the most-asked question in the SAP IS-U community and close to the least consequential. You will also encounter LSMW and LTMC, whose applicability depends entirely on your source release, target release and supported conversion path.

None of these tools decide whether you should migrate or replace. Tooling follows scope: source and target releases, data volume, business object complexity, transformation rules, validation requirements and reconciliation design. Choose the target state, define the data scope, then let those constraints select the tool.

The SAP Community threads on ECC-to-S/4 tooling are useful and they answer implementation questions. They do not answer the retain-versus-redesign question, and reading them as though they do is how utilities end up having chosen a path by accident.

One practical filter. Before committing to any tooling pattern, run a proof of concept on your three worst objects, the ones with the broken relationships and the incomplete history, with full reconciliation controls. Not the clean ones. Anybody's tool moves the clean ones.

And if a prospective partner leads with tooling before target state, you have learned what they are selling.

Decide what moves, what transforms, and what stays merely retrievable

Every object gets one of four dispositions: migrate, transform, archive with accessible retrieval, or leave behind under a controlled retirement plan.

Work through active and inactive customers, contracts, supply points, devices, billing documents, payment history, collections records and market communications. Legal, regulatory, audit and dispute-management requirements come first and are non-negotiable. Establish what you are obliged to keep and in what accessible form before anyone proposes reducing scope for delivery reasons.

Then require traceability: every legacy object maps to a target object, an archive record, or a signed disposition decision. No silent drops.

Data scope is not a technical detail downstream of the plan. It sets the cutover scope, the parallel-run duration, the interface design, the reporting surface and the date you can actually decommission anything. Utilities that skip the disposition policy discover their retirement date is undefined, which means the old system's cost never leaves the budget.

One variable almost nobody prices

Whatever platform you land on becomes the substrate for every automation decision you make for the next decade, and this is where I will admit my interest is not neutral.

Most production AI in billing today keeps a human as the last gate: the model proposes, a person approves. The systems worth building next don't. They configure tariffs, resolve exceptions and act on accounts without per-item review, which turns the engineering problem from accuracy into accountability.

Accumulated exception handling is what makes that unsafe. Every undocumented special case in your billing logic is a branch nobody can bound the blast radius of. A conversion that faithfully preserves twenty years of exceptions preserves exactly what will block autonomous operation, and you will not find that cost in any migration business case.

That is an argument for redesign, and I benefit from it. Weigh it accordingly. But ask the question of whoever is quoting your brownfield conversion, because they will not raise it.

The questions to answer before you pick a partner

  1. Which of our legacy processes create actual differentiation, and which are accumulated exception handling we have stopped questioning?
  2. Which of our data do we trust, by object, with a named owner?
  3. Which history must remain operationally live, and which only needs to be retrievable under audit?
  4. How much process change can this organisation absorb in 24 months, honestly, given the last programme?
  5. If SAP's maintenance deadline vanished tomorrow, would we still choose this target?

That last one is the whole thing. If the answer is no, you are not making a strategy decision, you are complying with someone else's roadmap and calling it one.

The decision logic underneath all of this is short. Migrate when retaining your processes and history is demonstrably the lower risk. Replace when retaining them perpetuates the risk. Hold with coexistence when neither extreme is safe yet, with exit criteria and a date.

What you should not do is let a maintenance deadline choose for you, which is what happens by default in 2027.

I'm building a scored decision matrix for this: process fit, technical debt, data quality, custom code volume, integration complexity, regulatory history, timeline, delivery risk and TCO, weighted to your own priorities. If you want it when it's finished, get in touch.

Sources