Intro
Brownfield S/4HANA programmes are often presented as controlled technical migrations: a defined conversion path, a confident SI timeline, and a business case shaped around licence optimisation, cloud transition, and reduced ERP risk.
Twelve to eighteen months later, the conversation can look very different: remediation budgets, delayed cutovers, unresolved data issues, change requests, and uncomfortable questions about why finance, supply chain, or operations are still carrying workarounds on the new core.
The business case is rarely wrong about the need for a modern ERP. The risk is that it underestimates what conversion really costs once custom code, data quality, integration, testing, and operating-model change collide under deadline pressure.
Executive summary
Executive sponsors should treat brownfield S/4HANA as a business transformation with a technical spine, not a technical project with a business wrapper.
The financial risk concentrates in three places:
1. Custom code that is counted but not understood
2. Data that must move, but does not have funded business ownership
3. Cutover decisions that are deferred until there is no room left to negotiate
Before major spend is released, boards should ask for evidence that custom-code disposition is tied to business criticality, data migration has named executive owners outside IT, and cutover governance defines who can stop, defer, or reduce scope before go-live.
Without those controls, programmes can appear funded on paper while quietly creating future cost through change requests, remediation work, operational disruption, and reputational damage.
Custom code is where optimism hides
Every brownfield SAP landscape carries years of custom objects, interfaces, reports, enhancements, and workarounds. Many were built for good reasons. Some are obsolete. Some quietly protect revenue, compliance, pricing, reporting, or customer promise.
Technical tooling can identify and count custom code. It cannot decide what the business still depends on. That judgement requires process owners, finance, operations, compliance, and architecture in the same conversation.
The risk is assuming one remediation wave will be enough, only to discover later that “simple” extensions support rebates, statutory reporting, warehouse operations, or month-end controls.
Boards should expect a clear disposition model:
1. Retire
2. Replace with standard
3. Rebuild or re-implement
4. Carry forward with a funded maintenance plan
Each category needs an owner, a cost view, a decision date, and a consequence if the decision slips.
Data migration is a leadership problem
Data migration is often described as a technical activity. In reality, it is a leadership problem with technical execution.
Migration plans may list objects, volumes, mock loads, and reconciliation cycles. The expensive question is whether the data is good enough to run the business after go-live. Customer records, products, suppliers, pricing, open financial items, assets, and inventory can all carry years of inconsistency from the legacy estate.
Boards should challenge three things early:
1. Who signs off data quality by domain?
2. What happens if a domain misses the cleansing window?
3. Is parallel run, reconciliation, or additional business support funded, or merely assumed?
If the answer is “IT will cleanse it”, the programme is probably carrying hidden business risk. IT can move data. The business must own whether that data is complete, accurate, usable, and safe to operate with.
Cutover governance beats heroic weekends
Cutover plans often look convincing in steering packs. The real test comes when defects, data issues, integration gaps, and business readiness concerns compete against a fixed go-live date.
Under pressure, scope can slip into hypercare without a clear decision record. Workarounds become accepted. Manual controls multiply. Support teams inherit unresolved design choices. The board hears that go-live was achieved, while the business continues paying for stabilisation.
Executives should pre-agree cutover tripwires before the final weeks:
1. Which issues trigger a date move?
2. Which issues trigger scope reduction?
3. Who has authority to make that decision?
4. What minimum process set must work on day one?
5. What must be true for the business to stay legal, serve customers, collect cash, and close the books?
A strong cutover governance model is not pessimism. It is insurance against making the most expensive decisions when the organisation is tired, politically committed, and running out of options.
Practical leadership takeaway
The right board question is not “Is the S/4HANA conversion technically possible?” The better question is “Do we understand where cost, ownership, and operational risk will appear once the programme is under pressure?”
Before approving a brownfield S/4HANA programme, leadership teams should ask:
1. Which custom objects are business-critical, and who has approved their future treatment?
2. Which data domains are most likely to block go-live, and who owns them outside IT?
3. What assumptions are being made about cleansing, reconciliation, testing, and business availability?
4. Which cutover risks would cause us to delay rather than force the date?
5. What evidence will prove the business can operate safely on day one?
Independent architecture assurance is most valuable in the first third of the programme, not at dress rehearsal. That is when sponsors still have time to challenge SI assumptions, correct underfunded workstreams, and prevent a controlled migration from becoming a long and expensive recovery exercise.