Daily Archives: August 3, 2026

Every SAP migration conversation starts the same way. The slides show a clean before-and-after. ECC on the left (slow, rigid, expensive). S/4HANA on the right (fast, intelligent, cloud-ready). The migration timeline looks achievable. The business case looks solid. The pre-sales team is confident. Then the discovery phase begins. And someone finally looks at the custom code.

The Number Nobody Puts in the Business Case

The average SAP ECC system carries approximately 22,000 custom objects and 2.7 million lines of executable custom code.

Up to 80% of the entire ECC code base in many environments consists of individual extensions including Z-programs, customer-specific modifications, bespoke reports, workarounds built to compensate for processes that were never properly designed in the first place.

Of that custom code, up to 40% is either unused or redundant. Nobody uses it. Nobody knows why it was built. The people who built it left years ago. And yet, it all has to be assessed, triaged, and resolved before a migration can complete safely.

A thorough remediation cycle from discovery, triage, rewrite, regression testing, and to integration validation takes six to twelve months for a mid-to-large ECC landscape. This is the number that almost never appears in the original business case.

Why Custom Code Becomes the Migration Anchor

There are three things that slow an ECC-to-S/4HANA migration to a halt. Data quality is one. Process redesign is another. Custom code is the third (this is one most frequently underestimated).

Here is why.

Custom code in ECC was often built to compensate for broken or missing processes. The standard SAP functionality did not match how the business actually worked, so developers back then had built workarounds. Those workarounds accumulated over years, became load-bearing, and are now embedded in critical business flows that nobody fully understands.

Things most teams discover mid-migration:

• The custom code touches decommissioned SAP objects that no longer exist in S/4HANA
• The underlying business process code that was compensating for the workarounds was never documented
• Regression testing reveals dependencies that nobody knew existed
• The remediation timeline extends by months — and so does the go-live date

 What the Qube Way builds in from the start:

• Process mining on real event logs to identify what the code is actually doing in practice
• A triage decision on each custom object: remediate, replace with standard SAP functionality, or retire
• Migration in structured waves, each scoped as a Qube with its own outcome and success metric
• Regression testing built into every wave, not left until the end
• Custom logic rebuilt as cloud-native extensions on SAP BTP compliant with Clean Core, not carrying forward the debt

The difference is not technical capability. It is sequencing. Process before platform. Always.

The Clean Core Opportunity Most Migrations Miss

SAP’s 2026 guidance is clear: custom logic built going forward should live on SAP BTP as cloud-native extensions that consume S/4HANA APIs and not as modifications to the core.

This is not just a technical recommendation. It is a strategic reset, making life easier going forward.

A migration that goes through proper custom code triage is an opportunity to retire 30 years of accumulated workarounds and rebuild the system around how the business actually wants to operate, not how it was forced to operate when the process was broken and a developer patched over the gap.

Enterprises are spending more on transformation than ever before. The enterprise agile transformation services market hit $49 billion in 2025. It’s growing at 18.5% annually and is projected to reach $193 billion by 2034. And yet, 70% of digital transformations still fail to meet their objectives in 2026.

Now read that again. A $49 billion market. A 70% failure rate. Something is structurally wrong and it isn’t the budget.

The Agility Paradox

The data shows that 78% of enterprises with over 1,000 employees have adopted at least one formal agile framework across three or more business units. 72% now say they prioritise business agility over IT-only agility. 83% of companies cite faster delivery to customers as their top transformation goal.

Though they’re buying agility, they’re not achieving it.

The reason is simple, and nobody in the room wants to say it: most enterprises are applying agile methods to broken processes. Sprints on the wrong problem don’t deliver outcomes faster. They just fail faster.

What Agile Was Never Designed to Fix

Agile is a delivery methodology. It tells you how to ship software in increments. It does not tell you whether the process underneath that software is worth building in the first place.

This is the gap. And it’s where transformations collapse.

An automotive manufacturer runs sprints to build a production planning module in SAP. The module ships on time. The team celebrates. Six months later, planners are still working off spreadsheets, because the planning process itself was never redesigned before the technology was configured around it.

The agile delivery was fine. The process underneath it was broken. Hence, the outcome was the same as before SAP. Now imagine such failures happening across three geographies, five business units, and a multi-year program, and you get the 70% failure rate.

The Missing Piece: One Outcome Number, Agreed Upfront

TecQubes’ Qube Way is built around a single discipline that most transformation programs skip entirely: define one measurable outcome before you build anything.

Not a project charter. Not a set of KPIs. One number agreed between the client and the delivery team that we will be judged on when the Qube is done.

This changes everything about how work gets done.

Traditional programme approach:

• Large scope defined upfront
• 18–36 month delivery cycle
• Value measured at the end — if at all
• Process redesign happens in theory, during workshops
• Go-live is the finish line

The Qube Way:

• One process, one outcome number, agreed before work begins
• Delivery in weeks, not years
• Process is redesigned first, technology is configured around it
• Go-live is a milestone
• Stack Qubes to transform the value chain, function by function

For a manufacturing client that TecQubes worked with, seven Qubes or seven outcome numbers were agreed upfront. After implementation, production planning cycle grew 25% faster. Inventory accuracy improved by 30%. Order-to-cash cycle became 20% faster. Procurement costs went down by 15%. Shopfloor logging was 100% automated. Each Qube handed over before the next one began.

No big bang. No 18-month wait for value.

The $49 Billion Market Keeps Getting This Wrong

The agile services industry has a commercial incentive problem. Larger programmes mean larger contracts. Longer timelines mean longer revenue streams. Measuring outcomes at the end of a multi-year engagement means the vendor is long gone before anyone notices the value never materialised.

There is no commercial incentive to keep programmes small. There is no structural accountability for the outcome number. The methodology gets the credit when things go well, and the client gets the blame when they don’t.

The Qube Way inverts this. Every engagement has an outcome number we commit to from day one. If we cannot name the number upfront, we do not start.

Key Takeaways

1. Agile methodology does not fix broken processes. It accelerates them, good or bad. Before any sprint plan is written, the process underneath needs to be mapped, measured, and redesigned. Technology built on a broken process delivers a broken outcome faster.

2. One outcome number, agreed before work begins, is the only thing that makes transformation accountable. Not a roadmap. Not a project charter. One number – production planning cycle time, order-to-cash days, procurement cost per transaction – that the delivery team is judged on when the engagement ends.

Enterprises that achieved success in business transformation in 2026 are not running bigger programmes. They are rather running smaller ones, with sharper accountability, and stacking provable wins into the transformation their board had mandated years ago.

What is the one process costing your enterprise the most right now? That is where to start.