Brownfield, Greenfield or Selective: AI Environment Assessment

Your migration path is the first big decision in an S/4HANA program, and it costs the most to reverse. SAP AI Solutions can replace the early guess with a scored inventory, a dependency map and effort figures for every object. Teams choose a path early, often in a steering committee meeting with half the facts. Six months later, a custom code problem or a hidden interface dependency exposes the mistake. An AI environment assessment grounds that choice in evidence. 2iSolutions US has delivered SAP work since 2005, and the pattern repeats: the path decision holds up when evidence drives it.

What Does an AI Environment Assessment Actually Deliver?

An AI environment 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. It turns an opinion about your system into measurable findings that a steering committee can challenge and approve.

An SAP environment is the full set of systems, custom code, interfaces, data stores and integrations that your business processes run on. The assessment reads that environment automatically, so analysts stop sampling and start measuring.

Here is what you receive at the end:

• 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.

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 where the money goes.

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. So the discussion stays on facts.

What the output looks like in practice

Picture a manufacturer 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.

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.

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 control, but it demands precise knowledge of how your objects connect.

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 custom code that made conversion impractical. That is why the evidence should come before the decision.

The hidden costs of each path

Every path has a cost that rarely shows up in the first proposal. Brownfield hides it in custom code remediation and in data that never got cleaned. Greenfield hides it in training, process redesign and the months when two systems run side by side. Selective hides it in the integration work that keeps split systems talking.

Finance leaders feel this most. A brownfield quote that looks cheap in January can double once remediation work surfaces in June. Therefore, a scored inventory pulls those costs forward, so the budget reflects the real project.

How Does the Assessment Compare the Three Paths?

The assessment compares paths by scoring the same inventory against each one. It estimates the effort to convert, rebuild or split each object, then totals the cost and risk per path. You compare three evidence-based scenarios instead of three opinions. Broader Deloitte technology trends analysis points to the same shift toward decisions grounded in measured data rather than assumption.

The method is simple to follow. First, the scan collects every object, its usage and its connections. Then the engine applies S/4HANA simplification rules to each object. Finally, it totals the results per path and ranks them.

The factors that move the score

Several inputs shift the outcome more than any others:

• Volume of custom code that fails S/4HANA compatibility checks.
• Share of objects that nobody uses and you can retire.
• Number of interfaces tied to third-party systems.
• Data quality in master and transactional tables.
• Count of ECC instances and company codes in scope.
• Tolerance for process change in the business.

Companies with heavy, active custom code and clean processes often land on brownfield with a remediation sprint. Those with sprawling, unused code and many instances often land on greenfield or selective. The numbers make that visible.

Reading the comparison as a steering committee

A good report shows the three paths side by side, with effort, cost, risk and timeline in one view. Executives do not need to read object lists. They need to see that path A costs more up front but removes a risk that path B leaves in place.

Because the figures trace back to named objects, anyone can challenge them. Someone asks why a pricing routine carries so much effort, and the report answers. That traceability builds trust in the final decision.

Where Does Custom Code Change the Answer?

Custom code changes the answer more often than any other factor. If a large share of your code is active, tied to interfaces and incompatible with S/4HANA, brownfield costs rise fast. If much of it is unused, however, brownfield becomes cheaper than it first looked.

Custom code means the programs, reports, enhancements and forms your teams built on top of standard SAP. Over fifteen years, that layer grows in every direction. Most of it was written for a reason, and much of it outlived that reason.

Dead code, live code and risky code

An assessment sorts custom objects into groups that need different treatment:

1. Unused objects that you can retire before migration.
2. Active objects that pass compatibility checks and move as they are.
3. Active objects that need adjustment before they run on S/4HANA.
4. Active objects that replace what standard S/4HANA now does natively.

Group four deserves attention. Many old enhancements exist because ECC lacked a feature that S/4HANA now includes. Retiring them reduces risk and shrinks the codebase. Teams that skip this step carry workarounds into a system that no longer needs them.

For a deeper view of the code decisions, an SAP custom code migration review sits alongside the assessment and feeds the same scores.

Interfaces and the quiet dependencies

Interfaces cause the surprises. A report that looks harmless may feed a warehouse system, a bank file or a partner portal. If the migration changes a table that report reads, the downstream system fails on cutover weekend.

The dependency map catches this early. It shows which objects touch which tables and which external systems consume the output. As a result, the team schedules interface testing where the risk actually sits.

How Do Cloud and Platform Plans Affect the Path?

Your target architecture shapes the migration path. Moving to SAP S/4HANA Cloud limits how much custom code you can carry, so it pushes many companies toward greenfield or toward a clean-core approach. On-premise and private cloud options allow more flexibility, and brownfield stays practical there.

Clean core is a design principle that keeps the SAP system close to standard and moves custom logic into separate extensions. It keeps upgrades simple, because the core stays untouched. The assessment tells you how far your current code sits from that target.

Where extensions live

When custom logic cannot stay in the core, it moves to a side-by-side platform. SAP BTP, the Business Technology Platform, is SAP's platform for building extensions, integrations and analytics outside the core system. Many teams rebuild their most valuable custom objects there.

The assessment flags which objects are candidates for that move. It separates code worth rebuilding as an extension from code worth dropping. That split drives both the effort figure and the choice of path.

Where AI fits beyond the assessment

Assessment is only one use of AI in an SAP program. Once the system runs on S/4HANA, the same data supports forecasting, document processing and guided decisions. Teams exploring SAP AI Solutions benefit when the migration leaves them with clean data and a tidy core. A messy conversion makes every later project harder.

Planning for that early matters. A path that looks cheaper today can block those use cases tomorrow. If a company expects to add SAP AI Integration across finance and supply chain, it needs a clean data foundation and well-documented interfaces. The assessment gives you both.

What Evidence Should You Take to the Decision Meeting?

Bring the scored inventory, the three-path comparison, the dependency map and a list of named blockers. Add a timeline per path and a cost range with its assumptions. This pack lets a steering committee choose a path in one session instead of three.

A useful decision pack contains these items:

1. A one-page summary comparing the three paths on cost, time and risk.
2. The top twenty objects by effort, with an owner for each.
3. The interface list with the systems that consume your data.
4. Data quality findings by module.
5. A proposed sequence of waves, if selective is on the table.

Questions to ask before you sign off

Ask the hard questions in the room. What share of the custom code is active? Which interfaces break if we convert in place? What does the business lose if we rebuild a process? Which assumptions drive the cost range, and who owns them?

If the pack cannot answer these, the decision is not ready. Push for another week of analysis rather than another year of rework.

Matching the path to the people

Path choice also depends on who will run the change. A greenfield program needs strong process owners in every function. A brownfield program needs skilled developers who can fix code at speed. A selective program needs architects who track dependencies across waves.

This is where talent planning meets the technical plan. Companies that choose a path without checking their staffing often stall midway. The assessment output tells you which skills the path demands, so you can hire or contract before the gap hurts.

Frequently Asked Questions

Q. How long does an AI environment assessment take?

A. Most assessments run a few weeks, depending on system size and access. The scan itself is quick, and most of the time goes to validating findings with your business and technical owners. 2iSolutions US scopes the timeline once it knows how many systems are in play.

Q. Can an assessment recommend a path I did not expect?

A. Yes, and that is often the point. Companies that planned a brownfield conversion sometimes learn that their custom code makes selective or greenfield cheaper. The scoring follows the evidence, not the plan you walked in with.

Q. Does the assessment replace my SAP team's judgment?

A. No. It supplies measured findings, and your experts decide what to do with them. Their knowledge of the business explains why certain objects exist and which ones the company must keep.

Q. What is the difference between an SAP S/4HANA assessment and an SAP ECC assessment?

A. An SAP ECC assessment examines your current system: its code, data, interfaces and usage. An SAP S/4HANA assessment measures how ready that system is for the target and what must change. Most programs need both views, and the AI scan produces them together.

Q. Is selective migration harder to manage than the other paths?

A. It can be, because you manage two states at once and keep interfaces working between them. The dependency map reduces that risk by showing exactly where the seams run. Teams with clear wave planning handle it well.

Choosing a Path You Can Defend

A migration path is only as good as the evidence behind it. Brownfield, greenfield and selective each win under specific conditions, and your system decides which conditions you have. A scored inventory, a dependency map and per-object effort figures replace guesses with numbers that survive scrutiny.

The payoff arrives after go-live. Budgets hold, cutover weekends stay quiet, and the business sees fewer surprises. Teams that decided on facts spend their energy on the program instead of defending an early assumption.

2iSolutions US pairs the assessment with SAP Migration Services and the skilled consultants to carry the chosen path through delivery. That link between analysis and execution keeps the plan intact once the work begins.