SAP S/4HANA Is Not a Migration Project. It's a Data Architecture Decision.

An S/4HANA programme succeeds or overruns on decisions about data, not on the cutover. Which entities, master data and custom code move, what happens to the BW estate under the same 2027 deadline, and where business definitions live afterwards decide the cost. Treat it as a data architecture decision first and a migration second.

Ask ten CIOs how their S/4HANA programme is going and you will hear ten versions of the same story. The timeline moved. The budget moved. The scope grew. And somewhere around month eight, someone asked the question that should have been asked on day one: what exactly are we moving, and why?

The 2027 deadline has turned this into a pressure cooker. Mainstream maintenance for SAP ECC 6.0 enhancement packages 6 to 8 ends on 31 December 2027. Extended maintenance runs to the end of 2030 at a premium SAP set at two percentage points on support fees, and beyond 2030 SAP's transition option is available only through RISE with SAP. A lot of organisations are discovering that buying time is not the same as having a plan.

The deadline is real. The readiness isn't.

#Why S/4HANA Programmes Keep Overrunning

What this means for you: the evidence points at how programmes are designed, not at the platform or its tooling.

Gartner's figures, reported in June 2025, set the scale. At the end of 2024, only 39% of SAP's roughly 35,000 ECC customers had moved to S/4HANA, nearly a decade after the platform launched. At that pace, Gartner projected around 17,000 holdouts, close to half the ECC base, still on the old system when 2027 arrives. Gartner has also worked with clients planning migration programmes of three to seven years.

The programmes already underway are not going smoothly either. ISG's February 2026 study of 200 senior decision makers at large global companies found that nearly 60% of SAP migration projects ran late and over budget. Fewer than one in five organisations reimplemented their processes when they moved to S/4HANA, and 49% did little or no re-engineering, preserving legacy processes and data. Most are carrying yesterday's complexity into tomorrow's platform.

ISG's own diagnosis was governance: programmes that span several systems integrators and specialists without clear decision rights, acceptance criteria or ownership across them. Cost follows the same pattern. It scales with how customised and fragmented the landscape is, which is why programme costs vary so widely from one estate to the next.

#What a Data Architecture Decision Actually Covers

What this means for you: each line below is a decision that either happens deliberately before migration or by default during it.

A data architecture decision, in an SAP S/4HANA programme, is the set of choices about what the target landscape should contain — its organisational structure, master data, chart of accounts, custom code, historical data and analytics — made on purpose rather than inherited from ECC. A migration project asks how to move what exists. An architecture decision asks what deserves to exist.

#Start With the Data Architecture, Not the Cutover Plan

What this means for you: a migration is the cheapest moment you will get to fix the data foundation, and most programmes spend it relocating what already exists.

Real S/4HANA data architecture work starts with unglamorous questions. Which company codes, plants and legal entities actually need to exist in the new world? Which master data has never been reconciled across regions? Where did custom code grow because the standard process was never properly understood?

Consolidation is where the value hides. Collapsing several ECC instances into one governed S/4HANA landscape, cleaning master data before it moves rather than after, and retiring customisations the new platform handles natively turns a forced upgrade into a genuine simplification. Skip that work and you have paid migration prices to relocate the mess.

#Sequence the decisions before the move

This is why sequencing matters. Application portfolio rationalisation comes first, so you know which systems deserve a place in the target state. The architecture of the scalable end state comes next. Migration follows, not the other way round.

#The BW Question Nobody Budgets For

What this means for you: the same 2027 clock runs on the analytics side, and it is usually the part of the landscape nobody has looked at.

Mainstream maintenance for SAP BW 7.5 also ends at the close of 2027, with extended maintenance available to 2030. Many organisations have a carefully planned ERP programme and a BW landscape nobody has opened in years. BW tends to hold two decades of accumulated business logic: start routines, end routines, hard-coded exit variables, and transformations whose authors left long ago.

That is why a proper BW assessment has to come before any decision about where to go. A good one inventories the data models, data flows, queries and reports that are actually used, separates them from the ones that exist out of habit, and sizes the real migration effort rather than the optimistic one.

#The assessment decides the route

The routes are genuinely different. SAP BW/4HANA, which SAP has committed to maintain until at least the end of 2040, suits teams that want to preserve and modernise their warehouse. SAP Business Data Cloud, which brings together SAP Datasphere, SAP BW and SAP Databricks, suits teams that want to retire the old warehouse and build on data products instead. Some will lift first and reshape later through SAP BW Bridge.

The four realistic paths out of BW 7.5, and how to choose between BW Bridge and a full Datasphere rebuild, are covered in depth elsewhere. The point here is narrower: the ERP plan and the BW plan have to be one plan, because S/4HANA changes the structures the BW extractors read from.

#Why a Migration Factory Beats a Migration Project

What this means for you: predictability comes from repetition, not heroics, so the way objects move matters as much as where they go.

Once the destination is clear, hand-converting hundreds or thousands of BW objects one at a time is how timelines disappear. A migration factory treats the work as a repeatable production line instead.

The first wave teaches the team what the landscape is really like. Each wave after it moves faster and with fewer surprises, because the patterns and the exceptions are already known. It is also a direct answer to the governance gap ISG found: acceptance criteria, decision rights and ownership are built into the factory's operating model rather than negotiated per object.

#The Analytics Layer Is Where the Business Feels It

What this means for you: if the numbers on the dashboard do not match the ledger, no one will credit the architecture underneath.

Finance doesn't care that your data model is elegant. It cares that the margin on the dashboard matches the margin in the ledger.

Commercial teams do not care which InfoProvider feeds a report. They care whether they can trust it on Monday morning. SAP analytics is where all the architecture work becomes visible, and where trust is won or lost.

A proper semantic layer — one place where measures, hierarchies and business definitions are defined once and reused everywhere — is what stops three departments producing three revenue figures from the same source system. Getting that layer right during the migration, instead of rebuilding reports one at a time afterwards, is one of the highest returns in the whole programme.

It is also where analytics continuity during conversion is protected or lost, and where the reporting tools themselves are decided, including the routes for BusinessObjects before BI 4.3 support ends.

#Industry Accelerators Change Where You Start

What this means for you: time spent rebuilding what is common to your industry is time not spent on what is unique to you.

Every SAP data programme starts from a blank page unless someone has already done the modelling for the industry. Accelerators exist to move that starting line, not to cut corners.

For consumer packaged goods, the CPG Intelligence Accelerator starts from pre-built product, customer, channel, geography and time models, so measures such as promotion return, sell-through and distribution are modelled once rather than rediscovered on every engagement. For utilities, the Utilities Intelligence Accelerator starts from governed asset, outage, customer and crew data domains with the KPI definitions operations teams run their days on.

The point of an accelerator is to spend programme time on what is unique to the client. That is how a timeline compresses without the governance being compromised.

#Why the SAP Foundation Decides What AI Can Do

What this means for you: almost every enterprise AI agent you are being pitched will act on data that lives in SAP.

An agent that reconciles invoices, adjusts inventory or recommends a price change is only as trustworthy as the S/4HANA and BW data underneath it. Duplicate master data, inconsistent hierarchies and undocumented transformation logic do not disappear when intelligence is added on top. They scale.

The organisations that get real value from agentic AI will be the ones that treated SAP modernisation as a data architecture exercise first and an AI exercise second — the same reason AI governance turns out to be an engineering problem rather than a policy one.

#When a Technical Conversion Is the Right Call

What this means for you: not every landscape needs redesign before 2027, and pretending otherwise wastes the time you do have.

A straight system conversion, moving ECC to S/4HANA with the processes largely as they are, is a defensible choice in some estates. A single instance that sits close to standard, with clean master data, little custom code and one chart of accounts, has little to consolidate and much to gain from moving soon.

Deferring process redesign until after go-live is also legitimate when the business genuinely cannot absorb change now — during a merger, say, or a peak trading year. The condition is that the deferral is a decision with a date and an owner, not a gap in the plan. Extended maintenance or RISE with SAP can buy that time; they cannot make the decisions for you.

#Three Questions to Ask Before You Sign the Migration Plan

What this means for you: these can be answered before the plan is signed, and each "no" is cheaper to fix now than after cutover.

1. What are we consolidating or retiring, and who decided? If the plan is to move everything as it is, the budget is being spent on relocation rather than improvement. A good answer names the entities, instances and customisations that will not survive, and the person who signed that off.
2. Has anyone assessed the BW landscape against the same 2027 deadline? If the ERP plan and the analytics plan live in separate conversations, one of them will surprise you. A good answer is a usage-based inventory and a chosen route.
3. Where does the semantic layer live, and who owns it after go-live? If the answer is unclear, the dashboards will drift, and so will trust in the numbers. A good answer names the platform, the definitions it holds and the team accountable for them.

This sequencing is the core of our S/4HANA transformation and SAP BW modernisation work: decide what deserves to exist, then move it.

The 2027 deadline will pass whether a company is ready or not. What each organisation does with the time between now and then decides whether S/4HANA becomes a cost it absorbs or a foundation it builds on.

#Frequently Asked Questions

#When does SAP ECC mainstream maintenance end?

Mainstream maintenance for SAP ECC 6.0 enhancement packages 6 to 8 ends on 31 December 2027. Extended maintenance is available to the end of 2030 at a premium SAP set at two percentage points on support fees, and beyond 2030 SAP's transition option is offered only through RISE with SAP. Earlier enhancement packages have already left mainstream maintenance.

#Is moving to S/4HANA a migration or a reimplementation?

It depends on the landscape, and the choice is a data architecture decision either way. ISG's February 2026 study found fewer than one in five organisations reimplement their processes when they move. A conversion suits a single, near-standard instance with clean master data; a heavily customised or multi-instance estate usually gains more from consolidating and redesigning first.

#What happens to SAP BW when we move to S/4HANA?

SAP BW 7.5 leaves mainstream maintenance at the end of 2027, with extended maintenance to 2030, so it needs its own decision on the same timetable. The routes are SAP BW/4HANA, maintained until at least 2040; SAP Datasphere within SAP Business Data Cloud; or a staged move through SAP BW Bridge. A usage-based assessment of the BW estate decides which.

#What is an SAP migration factory?

A migration factory moves objects such as BW models, flows and reports as a repeatable production line rather than one at a time. Objects are classified by pattern, converted in waves using standard patterns and automation, tested against acceptance criteria agreed in advance, and signed off in batches. Each wave learns from the last, which is where the predictability comes from.

#Why does the semantic layer matter in an S/4HANA programme?

The semantic layer is where measures, hierarchies and business definitions are defined once and reused by every report and model. Without it, departments produce different figures from the same source system and trust in the numbers erodes after go-live. Designing it during the migration costs less than rebuilding reports individually afterwards and protects reporting through the conversion.

Unolabs is a Data and AI first engineering consultancy, headquartered in the United Kingdom with engineering operations in Pune and active engagements across the UK, Australia, and Hong Kong. We help enterprises build the architectural foundation for autonomous AI execution — governed data platforms, semantic intelligence, and agentic systems that enterprises can stand behind.

If you are weighing how to sequence your S/4HANA and BW decisions before 2027, book a discovery call and we will work through it with you.