Why the Migration Path Is the Decision That Matters Most
Your migration path is the first big decision in an S/4HANA program, and it costs the most to reverse. Teams often choose a path early, sometimes in a steering committee meeting with only half the facts on the table. Then, six months later, a custom code problem or a hidden interface dependency exposes the mistake. By that point, budgets are committed, timelines are public and reversing course is painful.
The alternative is to replace the early guess with evidence. With SAP AI Solutions, you can generate a scored inventory, a dependency map and effort figures for every object in your landscape before anyone commits to a direction. An AI landscape assessment grounds the choice in measurable findings instead of opinion.
2iSolutions US has delivered SAP work since 2005, and the pattern repeats from one program to the next: the path decision holds up when evidence drives it. This article explains what an AI landscape assessment delivers, how the three migration paths differ, and how the findings translate into a decision your steering committee can challenge and approve with confidence.
What Does an AI Landscape Assessment Actually Deliver?
An AI landscape assessment scans your SAP system and produces a scored inventory of custom objects, a readiness rating, a dependency map, effort and cost per object, and a recommended migration path. In short, it turns an opinion about your system into measurable findings.
First, a definition. An SAP landscape is the full set of systems, custom code, interfaces, data stores and integrations that your business processes run on. The assessment reads that landscape automatically, so analysts stop sampling and start measuring. Instead of reviewing a handful of programs and extrapolating, you see the whole picture.
Here is what you receive at the end of the assessment:
A scored inventory of custom objects, with each item rated for usage and risk.
A readiness rating with named blockers, not a vague green, amber or red.
Effort and cost per object, so the budget has a source.
A dependency map that shows which objects, interfaces and tables rely on each other.
A recommended path: brownfield, greenfield or selective.
Each of these outputs answers a question that steering committees usually argue about without data. How much custom code do we really have? Which parts of it are still in use? What will it cost to carry forward? What breaks if we move one piece but not another?
Why per-object detail matters
A project-level estimate hides the problem. A single heavily modified pricing routine can cost more than two hundred small reports combined. Because the assessment prices objects individually, you see exactly where the money goes, and you can decide which objects deserve the investment.
Per-object scoring also changes the conversation with the business. Instead of arguing about whether custom code is "a lot," you can point to the specific objects that block the path. The discussion stays on facts, and stakeholders who might otherwise defend their favorite customizations can see the cost attached to each one.
What the output looks like in practice
Picture a manufacturer that has been running ECC for fifteen years. The scan lists every custom program, flags the ones nobody has run in two years, and ties the rest to the interfaces they feed. The report might show that a third of the custom code is dead weight. That finding alone changes the effort figure for every path, because code that nobody uses does not need to be converted, tested or rebuilt.
How Do Brownfield, Greenfield and Selective Paths Differ?
Brownfield converts your existing system to S/4HANA and keeps your history and configuration. Greenfield builds a new system from scratch and migrates only chosen data. Selective, sometimes called hybrid, moves specific company codes, modules or data sets while leaving the rest. Each path suits a different system condition.
Brownfield is a system conversion that carries your current processes, custom code and data into S/4HANA. It is the fastest route when the system is clean. However, it also carries every flaw forward, so a decade of workarounds comes with you.
Greenfield is a new rollout that starts from a clean S/4HANA system. You redesign processes and load only the data you choose. The price is higher effort, longer timelines and heavier change management. In return, you leave accumulated process debt behind.
Selective migration sits between the two. For example, you might convert one business unit and rebuild another, or move a subset of historical data. It gives you control, but it demands precise knowledge of how your objects connect. Without a dependency map, selective migration is where hidden interfaces cause the most damage.
Where each path usually fits
Brownfield suits organizations with stable processes and modest custom code. Greenfield suits companies that want to retire years of process debt or merge several ECC instances. Selective suits groups with mixed conditions, such as a healthy finance core and a tangled logistics layer.
Those are tendencies, not rules. Plenty of firms assumed they were brownfield candidates, then found their custom code or interfaces told a different story. That gap between assumption and reality is exactly what the assessment is designed to close.
How the Assessment Findings Point to a Path
The value of the assessment is that each finding maps to a path decision. You are no longer asking which path sounds right. You are reading what your own system says about which path it can support.
Consider how common findings influence the recommendation:
Low custom code volume and a clean readiness rating point toward brownfield, because there is little to carry forward that could hurt you.
Heavy modification, many unused objects and named blockers point toward greenfield, because converting that code would carry debt into the new system.
Uneven readiness across modules or company codes point toward selective, because some areas are ready to convert while others are not.
A dense dependency map signals risk for any path that splits the system, so selective plans need extra care.
Because effort and cost are priced per object, you can also compare the paths on money, not just on principle. A greenfield rebuild may look expensive until you see how much a brownfield conversion would spend on objects that should never have been migrated. Likewise, a brownfield path may look cheap until the assessment names the handful of blockers that will consume most of the budget.
Connecting the Assessment to Your Target Platform
The path decision does not stand alone. It sits inside a broader architecture choice about where your processes will run and how they will connect. Many organizations are weighing a move toward SAP S/4HANA Cloud, and the assessment helps here too. Custom objects that depend on tightly coupled modifications are harder to carry into a cloud model, so the per-object scoring shows early which items will need rework or replacement.
The same applies to extensibility. Rather than keeping heavy modifications inside the core, many teams plan to rebuild differentiating logic on SAP BTP. The assessment helps you decide which custom objects are worth rebuilding that way and which can simply be retired. Objects with no usage in two years are the obvious candidates for retirement, and removing them early shrinks both the effort and the risk.
Interfaces deserve the same attention. A dependency map that links each custom program to the interfaces it feeds gives you a realistic view of integration work. That is where SAP AI Integration becomes practical: the scan reads connections automatically, so integration effort is estimated from the actual landscape instead of from interviews and memory.
How to Use the Assessment in a Steering Committee
An assessment only helps if it changes how decisions get made. The goal is a steering committee that can challenge the findings and approve a path with open eyes, rather than ratifying a preference that someone arrived with.
A practical approach looks like this:
Run the scan across the full landscape before any path is discussed, so no one anchors on an early opinion.
Review the readiness rating and the named blockers first, since they set the boundaries for what is realistic.
Walk through the per-object effort and cost figures, focusing on the few objects that drive most of the spend.
Use the dependency map to test each path, asking what breaks if a given object or interface moves, stays or is retired.
Compare the recommended path against your business goals, and document why you accept or override it.
This sequence keeps the debate grounded. When someone argues that custom code is manageable, the inventory answers. When someone insists on a full rebuild, the cost per object shows whether that spending is justified. The recommendation becomes a starting point for discussion rather than a verdict, and the committee retains ownership of the final call.
It also protects the program later. If a surprise appears six months in, you can trace it back to a documented decision and a known finding. That makes it easier to adjust scope calmly, instead of reopening the entire path debate under pressure.
Common Mistakes the Assessment Helps You Avoid
Several mistakes recur when teams pick a path without evidence, and an AI landscape assessment addresses each one directly.
The first is assuming the system is cleaner than it is. A decade of workarounds hides in custom code that few people remember writing. Scoring every object for usage and risk brings those workarounds into view.
The second is estimating at the project level. A single large number conceals the pricing routine, or the handful of heavily modified objects, that will dominate the effort. Per-object costing exposes them before the budget is fixed.
The third is overlooking dependencies. A report that looks harmless may feed an interface that a downstream process relies on. The dependency map shows these links, so selective moves do not break something no one knew existed.
The fourth is carrying dead weight forward. If a third of your custom code has not run in two years, converting it wastes time and money. Finding it early shrinks the scope of every path at once.
Each of these mistakes is cheap to prevent at the start and expensive to fix midway. That asymmetry is the strongest argument for assessing before deciding.
FAQ
Q: What does an AI landscape assessment produce?
It produces a scored inventory of custom objects, a readiness rating with named blockers, a dependency map, effort and cost per object, and a recommended migration path of brownfield, greenfield or selective.
Q: Why is per-object pricing better than a project-level estimate?
A project-level estimate hides where the money goes. A single heavily modified pricing routine can cost more than two hundred small reports combined, so pricing objects individually shows exactly which items drive the budget and which can be retired.
Q: Can I still choose a path other than the one recommended?
Yes. The recommendation is a starting point for your steering committee, which can challenge the findings and approve a different path. The advantage is that the decision is made against measurable evidence rather than assumption.
Conclusion
The migration path is the costliest decision to reverse in an S/4HANA program, and an AI landscape assessment replaces early guesses with a scored inventory, a dependency map and effort figures for every object. By reading what your own system says, your team can choose brownfield, greenfield or selective with confidence. As experience since 2005 shows, the path decision holds up when evidence drives it. To explore more, visit 2iSolutions US.
Ready to base your migration path on evidence instead of assumptions? Our certified experts are here to help you assess your landscape and plan your next step. Contact us at info@2isolutionsus.com to get started today.
Top comments (0)