We Reviewed 35 SAP S/4HANA Brownfield Migrations and Where They Slipped

An SAP S/4HANA brownfield migration is often described as the lower-disruption path because it keeps much of the existing configuration, process logic, historical data, and custom development. That description is useful, but it can also make a system conversion sound more mechanical than it is. The migration keeps the history of the ERP landscape, including the parts that have become difficult to understand, test, or change.

For this review, we examined 35 documented brownfield, system-conversion, and closely related selective-conversion projects and field reports, then compared their recurring brownfield migration challenges with current SAP conversion guidance. The cases ranged from single-system conversions to large global programs with many integrations, custom objects, countries, and business units. We treated a project as having “slipped” when a dependency was discovered later than it should have been, required repeated remediation, extended rehearsal cycles, increased downtime pressure, or forced work into a later wave. That doesn’t mean the project failed. Several of the strongest projects in the sample succeeded because they found these issues early enough to correct them.

The result is a practical view of where SAP S/4HANA brownfield migration work becomes harder than the project plan suggests. The technical conversion is rarely the only critical path. Data quality, custom code, interfaces, testing, security, and change control can become the real schedule driver.

TL;DR

Across the 35 documented cases and technical retrospectives we reviewed, the same brownfield migration challenges appeared repeatedly. Teams underestimated preparation because brownfield sounded like reuse. CVI and master-data cleanup started too late. Simplification items were treated as technical tasks instead of business-impact decisions. Custom-code estimates counted objects instead of usage and dependency. Interfaces were assessed by endpoint lists rather than end-to-end process behavior. Testing focused on transactions without enough attention to roles, integrations, batch jobs, and converted data. Downtime was discussed before enough timed rehearsals existed. Parallel ECC change created retrofit pressure. The projects that handled these areas earlier had a more controlled SAP S/4HANA system conversion and fewer surprises near cutover.

Slip point: Readiness work starts after the project is already committed

The earliest schedule problem is often created before the first SUM run. A company selects the target release, signs a program plan, and announces a go-live window before it knows how many simplification items, incompatible add-ons, custom objects, data issues, and interfaces need remediation. The project then spends its first months discovering work that was never reflected in the original estimate.

SAP Readiness Check exists to expose much of that work early. SAP describes it as a planning tool that identifies relevant simplification items and provides information on areas such as custom code, add-on compatibility, sizing, and other conversion topics. The SAP Readiness Check guidance also makes clear that the output still needs interpretation and follow-up. A finding isn’t a project plan until someone connects it to a business process, owner, remediation task, test scope, and due date.

Where projects slipped, SAP Readiness Check output was sometimes treated as a technical report owned by Basis or architecture. That creates 2 problems. First, a simplification item can change business behavior even when the technical fix is straightforward. Second, the people who understand the historical reason for a custom process may not be involved until testing fails. The earlier the business and functional teams review the findings, the less likely the conversion is to discover hidden design decisions during remediation.

A stronger approach is to turn SAP Readiness Check findings into a conversion backlog before the main build starts. Each item should have a disposition: no impact, configuration change, code change, data cleanup, process change, test-only verification, or architecture decision. That backlog becomes the baseline for the SAP S/4HANA system conversion instead of an initial estimate based mainly on infrastructure and SUM duration.

The same rule applies to application scope. Surrounding BW, CRM, GTS, EWM, tax, banking, manufacturing, partner, and custom applications need to be identified before the conversion schedule is locked. An SAP S/4HANA brownfield migration preserves the core ERP history, but the ecosystem around that core still has to work after the technical change.

Slip point: CVI and master data become a late critical path

Customer/Vendor Integration is one of the clearest brownfield migration challenges that looks technical until data quality turns it into a business project. SAP S/4HANA uses Business Partner as the leading object for customer and supplier master data. SAP’s Business Partner and CVI guidance states that customers and suppliers must be converted to Business Partners for a successful move to SAP S/4HANA. That requirement reaches into number ranges, account groups, duplicate records, contacts, addresses, tax data, and custom fields.

The slip happens when CVI is planned as a conversion prerequisite but not funded as a data-cleanup stream. Old ECC systems often contain dormant vendors, duplicate customers, missing mandatory fields, inconsistent addresses, and records created under older governance rules. Synchronization checks surface those conditions, and the project then discovers that business data owners are needed to decide what can be corrected, merged, blocked, or retained.

A sound SAP S/4HANA brownfield migration begins CVI work early enough for several cleanup cycles. The team needs ownership for customer and supplier domains, rules for duplicate handling, mapping decisions, number-range strategy, custom-field treatment, and a process for records that keep changing while remediation is underway. A one-time cleanup extract is not enough when production ECC continues to create or update master data.

The same principle extends beyond Business Partner. Material master inconsistencies, profit-center design, cost objects, house banks, asset data, units of measure, and other domain-specific records can affect conversion or post-conversion processing. Brownfield keeps history, which is useful, but history also carries the data exceptions created over years of operation.

Teams that avoid a late data crisis set reconciliation rules before mock conversion. They know which counts must match, which exceptions are acceptable, and which business users sign off. That turns data from a vague migration concern into measurable exit criteria.

Slip point: simplification items are closed technically but not operationally

Simplification items are often where the project first sees that SAP S/4HANA isn’t an ECC upgrade with a new database. SAP has changed or removed parts of the old data model and application behavior. Some items require code changes. Others require configuration, data conversion, replacement functionality, or a business decision about how a process will work after conversion.

The Simplification Item Check is mandatory in the conversion process and is run by SUM at key points. SAP notes that unresolved errors can stop the conversion. That makes the technical dependency obvious. The less obvious problem is that a “green” technical check doesn’t prove that users understand the resulting process or that connected systems have been adapted.

This is where several brownfield migration challenges become cross-functional. A warehouse change can affect RF processes and interfaces. A finance simplification can alter reporting, reconciliation, or closing procedures. Credit management changes can alter integration with sales. Output changes can affect forms and partner communication. If those impacts are not traced into test cases and training, the issue may appear closed in the conversion tracker while it is still open in the business process.

A stronger SAP S/4HANA system conversion links every relevant simplification item to 3 things: the target design decision, the technical change, and the test evidence. The test evidence should cover the process result, not merely the transaction or program that was changed. If a simplification item affects order fulfillment, the test should prove the full order path that matters to the business.

This also improves defect triage. When a regression fails, the team can see whether the failure is tied to a known simplification item, a custom-code change, converted data, or an integration. Without that traceability, teams lose time reproducing defects and debating ownership.

Slip point: custom code is estimated by object count instead of usage and dependency

Custom code is one of the most visible workstreams in an SAP S/4HANA brownfield migration, but raw object counts can be misleading. A landscape may contain thousands of Z objects while only a smaller set is still used. At the same time, a rarely changed but business-critical enhancement can be far more difficult than many simple reports. Estimating remediation by total objects rewards counting rather than understanding.

SAP’s Custom Code Migration guidance supports S/4HANA checks and can use collected usage information to identify unused custom code. That combination matters. Usage data helps reduce the remediation surface, while ATC and related checks identify code affected by S/4HANA changes. The project still needs functional context to decide whether an object should be fixed, replaced, retired, or redesigned.

One recurring slip is starting remediation before the usage baseline is mature. Teams then spend time correcting objects that no longer matter while late-discovered active code creates schedule pressure. Another is treating each ATC finding as equal. Some findings can be fixed through repeatable patterns. Others indicate a deeper dependency on tables, transactions, or process logic that changed in SAP S/4HANA.

Franke’s documented conversion is useful because it shows the scale that can sit behind successful delivery. SAP reported more than 13,000 custom-code findings cleared and about 1,800 custom-code objects addressed in that program. The Franke brownfield conversion story also reports a weekend cutover, but that outcome came after the custom-code work, not instead of it.

Custom-code planning should therefore combine usage, criticality, remediation type, and test dependency. Create categories for retire, unchanged, quick fix, redesign, and replace with standard function. Tie each kept object to a business process and test case. That makes the code backlog smaller and gives the SAP S/4HANA migration testing team a clear reason for what must be covered.

Slip point: interface inventories miss the real dependency chain

Interface inventories often begin as spreadsheets listing sender, receiver, protocol, frequency, and owner. That is necessary, but it is not enough for an SAP S/4HANA brownfield migration. The core SAP system can change tables, APIs, IDoc behavior, authorization, output, batch sequencing, and data structures that an external system depends on. A technically active interface can still produce the wrong business result.

SAP’s current system-conversion guidance warns that conversion affects surrounding applications and calls for landscape assessment and interface management. The integrated system-conversion toolchain guidance treats the ERP system as part of a connected landscape rather than an isolated technical object. That is the right model for interface work.

The slip usually appears when the project validates connectivity but not semantics. A file reaches its endpoint, an IDoc is green, or an API returns HTTP 200, yet the downstream posting, status, quantity, pricing, or reference data is wrong. These defects are especially expensive late in the project because they often cross company boundaries and require vendor or partner coordination.

For each interface, document the business event that starts it, the expected transformation, the receiving business outcome, and the recovery path. Include batch jobs that create interface data and jobs that consume it. Test negative cases such as missing master data, duplicate messages, timeout, replay, and partial processing. An SAP S/4HANA system conversion should prove that the interface can fail safely as well as succeed.

Interface scope also needs cleanup. Some SAP S/4HANA brownfield migration programs carry old connections because nobody wants to remove them during conversion. That is understandable, but each retained interface adds testing and support cost. If runtime history shows that an interface has been inactive or replaced, retire it before the migration wave where possible.

Slip point: testing is treated as a final phase instead of a design input

Testing is where late decisions become visible, which is why weak test planning can make an otherwise competent migration look unstable. SAP S/4HANA migration testing has to cover more than whether transactions open. Converted data, changed code, roles, outputs, jobs, integrations, performance, and closing or planning cycles can all alter the result of an existing business process.

The strongest public example in our review was Nestlé’s 2025 Zone AOA conversion. SAP’s Nestlé Innovation Awards case reports 70,000 test cases, more than 1,500 automated regression scripts, 100,000 remediation activities, and a risk-based test approach tied to simplification items, impacted roles, and remediated custom transactions. Those numbers reflect an unusually large program, but the test principle scales down: coverage should follow change and business risk.

Projects slip when test scope is built from a generic process list after remediation is already underway. By then, the team may have no reliable map between changed objects and business processes. That makes it hard to know which regression tests are essential. It also encourages broad manual testing that consumes time without necessarily covering the highest-risk dependencies.

A better SAP S/4HANA migration testing model starts while readiness and code analysis are still running. Build a trace from simplification items, custom-code changes, interface changes, and security changes to test scenarios. Add converted-data checks to the same test pack. Then add end-to-end business cycles such as period close, MRP, procurement, order fulfillment, warehouse activity, asset processing, or industry-specific runs.

SAP S/4HANA migration testing should also use production-like roles. A process that works under SAP_ALL or a broad project role can still fail on day 1. Include job users and interface users, not only dialog users. That exposes missing authorizations before cutover.

Slip point: downtime becomes a target before it becomes a measured result

Downtime is often discussed early because executives want a go-live window. The risk comes when the target is set before the project has completed enough rehearsals to know what actually drives the outage. Database size matters, but so do table conversion, finance migration, data inconsistencies, SPDD and SPAU handling, technical performance, post-conversion tasks, validation, interfaces, and business sign-off.

SAP explicitly recommends repeated test runs for downtime-focused procedures. Its project sequence for SAP downtime reduction begins with a sandbox conversion and uses test runs to identify long-running tables and other constraints. That means downtime planning is empirical. The project learns by timing real conversion steps against a realistic copy of production.

The first rehearsal should be treated as measurement, not as proof that the final cutover plan works. Record each SUM phase, manual step, data validation, interface restart, smoke test, and decision gate. After the run, separate technical execution time from waiting time. Waiting for an owner, an approval, a missing credential, or a late validation can consume more business downtime than a program runtime.

SAP downtime-reduction methods can shift some conversion work into uptime. SAP’s current SAP downtime-reduction conversion documentation describes finance and inventory conversion work that can move out of the outage for supported scenarios. It also comes with prerequisites and planning requirements. The tool should be selected because the measured business-downtime need justifies it, not because the project wants an impressive target before understanding the source system.

The same discipline applies even without specialized downtime methods. Run more than one mock cutover. Keep the runbook versioned. Set entry and exit criteria. Treat the rollback point as a decision that can actually be executed, not a line in a slide deck.

Slip point: Fiori roles security and controls arrive after functional testing

Brownfield teams often prioritize keeping business processes working, which can push user experience and security changes later. That becomes risky when SAP Fiori adoption, role redesign, GRC controls, or infrastructure changes are part of the same release. The converted process may work in SAP GUI for a project user while the intended Fiori app or production role still fails.

The University of Toronto’s conversion shows why preparation beyond SUM matters. SAP reports that the university used Early Adopter Care to identify conversion and integration preparation steps during its SAP S/4HANA system-conversion program. The project also combined core ERP modernization with broader user and HR changes. The lesson for smaller programs is that technical readiness and user readiness should be tracked together when they share the same go-live.

Security must be retested against the S/4HANA design. Changed transactions, CDS-based applications, Fiori catalogs, OData services, new apps, and altered process responsibilities can affect access. A role copied from ECC isn’t automatically proof that the control design still works. Segregation-of-duties rules may also need review when transactions or job responsibilities change.

This is one of the common brownfield migration challenges because the project is trying to preserve processes while the platform introduces new access patterns. The safer sequence is to decide the day-1 user experience early, build production-like roles before final regression, and include negative authorization testing. Confirm who can post, approve, change master data, run critical jobs, and administer the system.

Control owners should also validate audit evidence and automated controls after conversion. A report can run successfully and still return different data if its underlying logic changed. Treat controls as business-critical scenarios in SAP S/4HANA migration testing rather than a separate compliance exercise at the end.

Slip point: parallel ECC change creates retrofit and freeze problems

Large SAP programs rarely get a quiet source system. Business projects continue while the conversion team works on a copy of ECC. Emergency fixes are transported. Regulatory changes arrive. New interfaces are added. Every source-system change after the conversion track branches creates a decision about whether and how that change reaches the S/4HANA track.

SAP Cloud ALM now includes support for retrofit in SAP S/4HANA conversion and upgrade scenarios. Its conversion retrofit guidance uses remote ATC and Simplification Database checks to categorize certain workbench and customizing objects for automatic or manual handling. The existence of tooling does not remove the need for governance. Someone still has to decide which changes are allowed, when they are imported, and how they are retested.

Projects slip when the dual-maintenance strategy is defined after the development freeze becomes politically impossible. Business teams then push urgent ECC changes while the conversion project tries to keep S/4HANA stable. That creates transport collisions, duplicate remediation, and uncertainty about which version of a custom object was tested.

A safer SAP S/4HANA brownfield migration defines change lanes early. Classify source-system changes as mandatory, deferrable, or conversion-conflicting. Require impact analysis against the S/4HANA remediation backlog. Set recurring retrofit windows rather than moving changes ad hoc. Keep a clear record of which ECC transports reached which S/4HANA system and which regression tests were rerun.

The freeze should be progressive. A full business freeze months before go-live is rarely realistic, but certain high-risk areas can freeze earlier than others. Stable conversion scope reduces late test churn and gives the cutover team a known baseline.

Slip point: clean core and innovation expand the brownfield scope

An SAP S/4HANA brownfield migration is chosen because the company wants to preserve useful investment. The tension starts when the same program is asked to clean decades of custom code, redesign processes, launch Fiori broadly, move infrastructure, replace integration technology, adopt new SAP modules, and remove every non-standard extension. Each goal can be valid. Doing all of them in the conversion wave can turn a reuse strategy into an uncontrolled transformation.

BMW Group’s large migration program is instructive because SAP describes a factory model that separates build, migration, and conversion work across many systems. The BMW migration-factory case shows how repeatable methods and explicit scope can support a multi-system program. The useful lesson isn’t the scale. It is that standard conversion work and optional innovation need different decision rules.

For each requested change, ask whether it is mandatory for S/4HANA, required for business continuity, needed to retire an unsupported dependency, or optional improvement. Mandatory work belongs in the conversion. Optional work should compete for scope based on value and risk. This prevents the SAP S/4HANA system conversion from becoming a holding area for every modernization idea that has waited for funding.

Clean-core work should follow the same logic. Remove unused custom code before paying to remediate it. Replace custom work with standard functions when the fit is clear and the business can absorb the change. Move side-by-side extensions only when the target architecture is understood and support ownership exists. “Clean core” is a direction for reducing unnecessary core modification. It is not a reason to force every historical deviation out of the system during one release.

A successful brownfield program can deliberately sequence innovation after technical conversion. SAP itself has described brownfield as a way to create a foundation for later transformation. That is often safer than tying the conversion date to every future-state ambition.

What the stronger migrations did differently

The successful cases in the 35-project review didn’t avoid complexity. They made it visible early and created evidence before cutover. Franke reported clearing more than 13,000 custom-code findings before a weekend conversion. Nestlé reported multiple NZDT test cycles, a large risk-based test estate, role remediation, and broad rehearsal at global scale. BMW used a migration factory model across many systems. These examples differ in size, yet the working habits are similar.

SAP’s own conversion of its corporate ERP reinforces the same principle. In the SAP Runs SAP account of its S/4HANA conversion, SAP describes brownfield as a technical conversion path that can support step-by-step transformation rather than requiring every change at once. That is a useful guardrail for scope.

The practical differences can be summarized in the table below.

The stronger programs also used gates. A test cycle didn’t finish because a calendar date arrived. It finished when critical defects were closed or accepted under clear rules. A cutover rehearsal didn’t pass because SUM completed. It passed when conversion, interfaces, roles, jobs, validation, and business sign-off all fit the required window.

That distinction is important because brownfield projects can appear technically green while operational readiness is still incomplete. The SAP S/4HANA migration testing plan, cutover plan, and support model need to use the same definition of “ready.”

A safer SAP S/4HANA brownfield migration sequence

A safer sequence begins with discovery before delivery commitments harden. Run SAP Readiness Check, collect custom-code usage, inventory interfaces, assess add-ons, size HANA, and identify CVI or other master-data prerequisites. Use the findings to estimate remediation by workstream. Don’t move directly from a tool report to a fixed go-live date without business owners reviewing the impact.

Next, create the conversion backlog and establish governance. Use the same project structure for simplification items, code, data, interfaces, roles, testing, and cutover. SAP’s Cloud ALM system-conversion planning guidance provides a system-conversion roadmap template with phases, tasks, and quality gates. A tool can’t replace ownership, but a common structure helps prevent technical and business workstreams from tracking different definitions of completion.

Then begin the long-lead cleanup. CVI and master-data work should start early. So should code retirement, add-on decisions, interface owner confirmation, and security design. These items can require business decisions or third parties, which makes them poor candidates for the last quarter of the project.

Run a sandbox conversion before the project expects precision. Use it to expose checks, conversion runtime, SPAU or SPDD volume, post-conversion work, and data behavior. The first run is where the team learns. The second should prove that the fixes are repeatable. Later rehearsals should increasingly resemble production in size, sequence, people, credentials, and validation.

Build SAP S/4HANA migration testing from change evidence. Include high-value process flows, critical custom code, integration chains, converted data, batch cycles, roles, and controls. Use production-like accounts. Automate stable regression where the return is clear, but don’t confuse automation count with coverage quality.

Finally, protect the cutover baseline. Tighten the ECC change process, execute planned retrofit, freeze high-risk areas, and make the go/no-go gates explicit. The best cutover runbooks state the owner, expected duration, evidence, dependency, and rollback implication for every critical step. They also include the business validation that occurs after SUM completes.

This sequence does not remove brownfield migration challenges. It moves them earlier, when they are cheaper to solve and less likely to threaten the production date.

Conclusion

The 35 migrations we reviewed show why SAP S/4HANA brownfield migration work is easy to underestimate. Brownfield preserves useful configuration, process knowledge, and historical data, but it also preserves dependencies that have accumulated over years. The conversion program has to identify which of those dependencies still matter and which should be removed before they consume remediation and testing effort.

The recurring slip points were not mysterious. Readiness findings were translated too slowly into owned work. CVI exposed old data problems. Simplification items crossed into business processes. Custom code was counted before it was classified. Interfaces were tested as connections rather than process chains. Testing was planned after change scope. Downtime targets came before enough rehearsals. Roles and controls arrived late. Parallel ECC change created retrofit pressure. Innovation expanded the conversion scope.

A controlled SAP S/4HANA system conversion handles those brownfield migration challenges as one program rather than separate technical tasks. It starts long-lead cleanup early, ties changes to test evidence, rehearses the full cutover, and keeps optional modernization from obscuring mandatory conversion work. That is what turns a brownfield project from a technical upgrade narrative into a migration plan that can survive contact with a real ECC landscape.

FAQs

What is an SAP S/4HANA brownfield migration?

An SAP S/4HANA brownfield migration converts an existing SAP ERP or ECC system to SAP S/4HANA while retaining much of the current configuration, historical data, and process design. SAP commonly calls this path a system conversion.

Is brownfield the same as an SAP S/4HANA system conversion?

In SAP transition terminology, brownfield generally means SAP S/4HANA system conversion. The existing SAP ERP system is converted rather than rebuilt. Some projects use brownfield more loosely, so the exact technical path should be stated in the project scope.

What usually causes brownfield migration delays?

Common causes include late CVI cleanup, unresolved simplification items, underestimated custom code, undocumented interfaces, weak regression coverage, and cutover tasks that exceed rehearsal estimates. Parallel ECC change can also create retrofit rework.

Why is CVI important in a brownfield conversion?

SAP S/4HANA uses Business Partner as the leading object for customer and supplier master data. Existing records need the required CVI setup and synchronization. Data inconsistencies, duplicates, number ranges, and custom fields can make CVI a major preparation stream.

When should SAP Readiness Check be run?

SAP Readiness Check should be run early enough to affect scope estimates, remediation planning, and architecture decisions. Teams should refresh it as the source system changes and convert findings into owned actions.

How should custom code be assessed for SAP S/4HANA?

Start with usage information to identify code that can be retired. Then run S/4HANA custom-code checks and classify active objects by business criticality and remediation type. Object count alone is a weak effort estimate.

How much testing does a brownfield migration need?

SAP S/4HANA migration testing should follow business risk and change impact. Cover changed processes, custom code, interfaces, converted data, roles, batch jobs, reports, and critical business cycles. Include failure and recovery paths for high-risk flows.

Why do interfaces fail after a technically successful conversion?

Connectivity can stay healthy while payload structure, authorization, reference data, batch sequence, or downstream behavior changes. Interface testing should confirm the business result and recovery method rather than only message delivery.

How many mock conversions should a brownfield project run?

There is no fixed number. Run enough cycles to make conversion steps repeatable, close major findings, measure downtime, and prove the production runbook. Large or low-downtime environments often need more rehearsals.

What is the role of SUM in SAP S/4HANA brownfield migration?

Software Update Manager executes core technical parts of the conversion, including software update and data-conversion activities. Depending on the source database and procedure, DMO can combine database migration with conversion.

Should data be archived before a brownfield migration?

Archive or delete data only under approved business, legal, and retention rules. If data reduction is planned, do it early enough for the new footprint to be reflected in sizing and mock-conversion results.

Does brownfield mean Business processes do not change?

No. SAP S/4HANA simplifications and mandatory changes can alter process behavior even in a reuse-led conversion. Separate mandatory changes from optional redesign so the conversion scope stays controlled.

What is the biggest cutover mistake in a brownfield project?

A common mistake is treating SUM completion as the end of cutover. Production readiness also depends on post-conversion tasks, interfaces, jobs, security, data checks, smoke tests, and business validation.

How should parallel ECC changes be managed during conversion?

Define dual-maintenance and retrofit rules before heavy remediation. Classify ECC changes by urgency and conversion impact, move approved changes through planned windows, and retest affected SAP S/4HANA objects.

How do you know a brownfield migration is ready for Go-Live?

Critical checks should be clear, data reconciled, high-risk tests passed, production roles proven, interfaces and jobs ready, defects accepted under defined rules, and cutover timing demonstrated. Business owners should understand any remaining workaround before release.