A clean core roadmap is a structured plan for understanding what you're migrating, making intentional decisions about what to keep, and arriving in S/4HANA with a system that's fit for purpose rather than carrying decades of technical debt.
Brownfield migrations need this because you're not just moving your configuration, you're carrying every workaround, custom Z transaction, and piece of unarchived data from the last 10-20 years directly into your new system.
Key steps for brownfield success:
- Analyse custom code first to understand what you have and what can be retired or replaced
- Right-size your data based on which processes you're actually keeping
- Make deliberate process decisions armed with knowledge of your code and data reality
- Start before programme launch, not during it, when changes are expensive
How much baggage does a typical brownfield migration carry?
If you're planning a brownfield migration to S/4HANA, you already know the pitch: keep your existing configuration, preserve your business logic, migrate faster than a greenfield. It sounds like a sensible option, and in many ways it is.
But there's a catch that most organizations discover too late. Brownfield doesn't mean clean. It means carrying everything you've built over the last 10, 15, 20 years directly into your new system.
What comes with you in a brownfield migration
In our experience, the typical brownfield environment arrives at the migration starting line carrying far more complexity than the project team expects:
- Hundreds of Z transactions, many of which no one can clearly explain the purpose of
- Years of accumulated data, including master data that's duplicated, incomplete, or simply wrong
- Business processes that diverged from SAP standard long ago and were patched with custom code rather than redesigned
- A growing body of technical debt that's rarely reviewed and almost never remediated
When organizations discover this complexity
The organizations that struggle most are the ones that assume migration will be straightforward because they're keeping their existing system. They find the complexity only when they're already in flight, when it's expensive to change course and the pressure to deliver is at its highest.
The clean core conversation needs to happen before the programme begins, not during it.
There's a broader reason why organizations keep arriving at this point unprepared and it's not just about planning discipline.
The traditional model for running SAP programmes relies on expensive systems integrator resource to produce the analysis and documentation that should inform every major decision.
That model is slow, costly, and commercially misaligned with your goals. The Deshoring Manifesto makes the case that Agentic AI can replace a significant portion of that SI dependency, compressing timelines, reducing cost, and producing better-informed decisions.
Which technical debt slows brownfield migrations the most?
Not all technical debt is equal. Some of it is manageable. Some of it will genuinely stop a programme in its tracks. The three areas where we consistently see the most friction are custom code, data volume, and process divergence.
Custom code: the biggest surprise
This is consistently the biggest surprise. Organisations know they have custom code. They often don't know how much, what it actually does, or how complex it is to migrate or retire.
A large, undocumented custom code estate creates risk at every stage. The specific problems are:
- Code that quietly replicates functionality that now exists in S/4HANA standard
- Code with no clear owner and no documentation
- Code that touches core data structures that change in the move to S/4HANA
The only way to get ahead of this is to analyse your custom code estate before your programme begins.
That analysis tells you what you're dealing with, which objects can be retired, which can be replaced by standard functionality, and which genuinely need to be migrated or rewritten. Done early, it compresses your design phase significantly and removes a major source of late-stage risk.
Until recently, the practical barrier to doing this was time and cost. Producing a thorough custom code analysis through traditional consulting methods takes months and consumes significant senior resource.
Deshoring changes that equation. By replacing the human bottleneck with Agentic AI, it's now possible to extract, classify, and document an entire ABAP estate in days rather than months, and to do it at a fraction of the cost.
The insight that used to arrive too late now arrives before your programme begins, when it can actually change your design decisions.
Data volume and quality: the underestimated cost
Legacy data volume is one of the most underestimated costs in a brownfield migration. More data means:
- Longer migration runtimes
- Higher cloud infrastructure costs
- More complexity in validation and sign-off
The value in S/4HANA comes from relevant, trusted data, not volume.
Organizations that approach data right-sizing with the same rigour they apply to technical design run faster, spend less, and arrive in S/4HANA with a data foundation they can actually build on. Legacy data that doesn't support your future processes is a liability, not an asset.
Process divergence from SAP standard
Over time, most organizations drift away from SAP standard processes, sometimes for good reasons, often because it was easier to build a workaround than to challenge the business requirement at the time.
In a brownfield migration, every process divergence is a decision point: do you keep the customization, revert to standard, or use this as an opportunity to redesign?
Organizations that don't understand their processes before they start can't make those decisions intentionally. They end up either migrating everything as-is, or discovering mid-programme that a process needs to change when it's already been built.
Organizations that know their processes can make deliberate choices about what to keep, what to change, and what to standardize. That clarity enables continuous improvement from go-live, rather than firefighting the consequences of decisions that were never made consciously.
Why do organizations underestimate their data complexity?
Organizations underestimate their data volume and complexity almost universally. There are two reasons for this.
Data volumes grow quietly
First, data volumes grow quietly over time. Most organizations don't have a clear real-time picture of what's actually in their system until they run a formal assessment, and the numbers are routinely much larger than expected.
Data complexity isn't just about volume
Second, data complexity isn't just about volume. It's about the relationships between data objects, dependencies on custom structures, and the knock-on effects of data quality issues on downstream processes.
A single master data problem can cascade through an entire business process in ways that aren't obvious until you're testing.
This is why data assessment needs to happen early, not just before cutover. The later you find a data problem, the more expensive it is to fix.
What is the right sequence for brownfield clean core preparation?
One of the most common questions we get is about sequencing. Where do you start? Do you tackle data first, or process, or code? The answer matters more than most people realise, because doing the wrong things in the wrong order means revisiting work you've already completed.
The recommended sequence
Our recommendation is to:
- Start with custom code
- Address data second
- Tackle process standardisation last
Why custom code comes first
You need to understand what your custom code does before you can make process decisions, because the analysis regularly surfaces fit-to-standard opportunities that change your design scope entirely.
If you've already designed your future processes around a custom transaction that turns out to replicate standard S/4HANA functionality, you've wasted time and created rework.
Why data comes second
Data right-sizing is most effective once you know which processes you're keeping. When the target process landscape is clear, you can define what data you actually need to support it, and make informed decisions about what to archive, historize, or simply leave behind.
Why process optimization comes last
Process optimization depends on both custom code and data understanding. When you know what your custom code does and what your data looks like, you can make genuinely informed decisions about which processes to standardize, which to redesign, and which to carry forward as-is.
Organizations that try to tackle process standardization first tend to revisit those decisions repeatedly as the code analysis and data assessment surface things they didn't know about.
Where is the fastest value in brownfield preparation?
If you're looking for the single highest-leverage activity you can undertake before your programme begins, it's custom code analysis. It's not glamorous, but nothing else comes close for the speed and quality of insight it delivers.
What custom code analysis gives you
A thorough custom code analysis provides:
- Immediate clarity on the scope and complexity of your Z estate
- Fit-to-standard opportunities that directly reduce your build scope
- Identification of code that can be retired entirely
- Documentation your design team needs to move quickly
It also de-risks sign-off, UAT, and cutover by ensuring your team understands what they're testing and why. On a large programme, it can compress your design phase by weeks and remove a category of risk that would otherwise sit unresolved until late in the delivery.
The traditional challenge
The challenge has always been the time and cost involved in producing that analysis manually. Building a complete picture of a large custom code estate through traditional consulting methods takes months and consumes significant senior resource.
That's precisely why many organizations skip it, or do it too shallowly, and why it remains one of the most common sources of mid-programme surprises.
The Deshoring model replaces that dependency with Agentic AI that delivers the same depth of analysis faster, at lower cost, and without the commercial bias of a systems integrator who benefits from complexity.
How does ABAPBanZAI change the economics of custom code analysis?
Our AI solution, ABAPBanZAI, changes the economics of custom code analysis entirely. It connects directly to your SAP environment and:
- Extracts your entire ABAP codebase
- Uses AI to reverse-engineer functional specifications
- Classifies every object by type and complexity
- Maps each piece of code to the business process it supports
- Produces a fully interactive documentation wiki
What would take a team of consultants months to produce manually, ABAPBanZAI delivers in days.
The S4SensAI integration
Paired with S4SensAI's Agentic SAP Architect, that analysis can then be evaluated directly against the full S/4HANA standard functionality set, giving you a prioritised list of fit-to-standard opportunities and clean core recommendations built on your actual code, not assumptions about it.
The result is a clean core roadmap grounded in evidence rather than estimates, produced at a speed that changes what's possible at the front end of a programme.
What value does brownfield deliver beyond go-live?
The conventional view of a brownfield migration is that it's a constrained exercise. You're locked into your existing system, limited in what you can change, and largely focused on getting to S/4HANA without breaking anything.
Brownfield as strategic opportunity
Done well, a brownfield migration is one of the best opportunities you'll have to:
- Understand your SAP landscape
- Make deliberate decisions about what to carry forward
- Arrive in your new system with a platform that genuinely serves your business rather than carrying accumulated technical debt
A clean core roadmap turns that opportunity into a structured path. By focusing first on what's clean enough to realize value quickly, and then optimizing over time, you can balance speed, risk, and long-term sustainability in a way that a purely technical migration approach simply doesn't allow.
The post-go-live benefits
The benefits extend well beyond go-live:
- Clean core adherence lowers your cost of change after migration
- Composable architecture through BTP and modern ABAP increases flexibility
- Reduced custom code burden means absorbing SAP's quarterly functionality releases without constant rework
The organizations that invest in getting this right before their migration don't just have a smoother go-live. They have a system that keeps delivering value in the years that follow.
Where should you start your brownfield clean core journey?
If you're planning a brownfield S/4HANA migration, the clean core conversation is one you want to have before your programme is in flight.
The earlier you understand your custom code estate, your data landscape, and where your processes diverge from standard, the more options you have, and the less those decisions will cost you later.
If you'd like to see how ABAPBanZAI and S4SensAI can accelerate your clean core roadmap, read the manifesto.
If you have any questions, we're happy to walk you through it.
