Greenfield vs Brownfield SAP S/4HANA: Choose Your Path

Most teams searching for greenfield vs brownfield SAP are really asking one question: how much of the old system do we keep? A brownfield (system conversion) converts the existing ECC system in place, history and custom code included. A greenfield (new implementation) builds a new S/4HANA system and loads only what you choose. Selective data transition (SDT), which the partner market calls bluefield, sits between the two: you build a shell and move chosen clients, company codes or years into it.

The short answer. Choose brownfield when your processes and custom code are sound and speed matters most. Choose greenfield when the process model has to change anyway. Choose SDT when only part of the business needs a reset, or when you are carving out or consolidating. Market data does not settle it. ASUG's 2026 members who converted averaged 15.8 months to go-live, and greenfield averaged 20.2 months, but those averages hide differences in scope and quality.

The path also sets what you must prove at sign-off. Brownfield proves nothing that worked in ECC has broken. Greenfield proves the new design works and every loaded record reconciles. SDT proves both. With SAP ECC mainstream maintenance ending December 2027 (per Software Modernization Services), a program scoped in Q4 2026 has about 13 months to make this call and plan the work behind it.

The three paths in one table

SAP's conversion documentation names three ways to move from ERP 6.0 to S/4HANA: system conversion, new implementation and selective data transition. The table below maps each one to the working names your steering committee will use and to what each path does to configuration, custom code, history and cutover.

Question	New implementation (greenfield)	System conversion (brownfield)	Selective data transition (SDT)
Partner or common name	Greenfield	Brownfield	Bluefield (partner label)
Configuration	Designed fresh on standard content	Converted in place	Structure carried into a shell; chosen parts moved
Custom code	Rebuilt, replaced or retired	Converted and remediated in the same system	Only the objects you move need remediation
Transactional history	Not carried unless loaded or archived	All of it, in the same system	Only the years and entities you select
Open items and master data	Loaded through the Migration Cockpit	Converted in place	Loaded for the chosen scope
Cutover shape	Staged loads; parallel running possible	One conversion event	Shell build, then selective transfer
Public Edition	Yes, the only option	No	No, per SAP Community guidance
Sign-off focus	New design works; loads reconcile	Nothing that worked has broken	Both

A note on the name. Selective data transition is sometimes marketed in the partner ecosystem as bluefield. SAPinsider's overview makes the same point. I did not find a trademark registration in the sources I checked, so before anyone writes "Bluefield" into a contract or a steering paper, ask the vendor what they mean by it and use SAP's term alongside it.

Lane 1: Greenfield

1. ECC sourceOld system stays as the reference; history stays there unless loaded
2. Build new S/4HANAFit-to-standard design; configuration built fresh
3. Migration Cockpit loadsMaster data and open items. Moves: config ✗, custom code ✗, history ✗, open items ✓
4. S/4HANA targetClean core; new custom code only where justified

Lane 2: Brownfield

1. ECC sourceFull system, database, config and history in place
2. SUM in-place conversionWhole system converted; custom code remediated. Moves: config ✓, custom code ✓ (remediated), history ✓, open items ✓
3. S/4HANA targetSame system, same history, one cutover event

Lane 3: SDT (bluefield)

1. ECC sourceClients, company codes and years in scope are defined
2. Shell copyEmpty shell with chosen structure and config. Moves: config ✓, custom code ✓ (chosen objects only)
3. Selective transferChosen clients, company codes and years move. History ✓ (selected), open items ✓ (selected)
4. S/4HANA targetBoth the shell and the transferred data reconciled before sign-off

What people actually choose: the 2025–2026 data

The three most useful benchmarks give different splits. They ask different questions, sample different people and publish at different times. Read them as signals, not a consensus.

Source: SoftwareSeni, citing ISG 2026 research. Two other write-ups report the same split. I did not find ISG's own report in the sources I checked.

Source: diginomica, reporting ASUG research. The coverage I checked did not give a bluefield or SDT share, so none is shown.

Source: SAPinsider blog on migration timelines, summarizing the 2025 benchmark. I did not confirm the greenfield and SDT shares or the sample size in the full PDF, so they are not charted.

Source: SNP Group, meta-study of the Foundry study. Shown as context only; it predates the 2026 benchmarks.

Why the numbers differ. The first reason is the question. SAPinsider asks about planned deployment models, and in 2025 system conversions rose to 49% of planned deployments. ASUG reports the approach respondents actually chose, and in 2026 nearly half (47%) opted for brownfield, which takes less time at 15.8 months, on average. A plan and a choice are not the same thing, and plans change.

The second reason is the sample. ASUG's 2026 research polled 194 members about their S/4HANA adoption, infrastructure, project delivery details, AI integration, and optimization. ISG's 2026 work surveyed 200 senior SAP decision-makers. Both are self-selected groups of SAP users, not a random sample of the installed base.

The third reason is timing. SAPinsider's 2026 ERP migration benchmark covered 296 respondents surveyed between December 2025 and March 2026, and found 35% planning to switch before the end of 2026. Secondary write-ups also quote a different ASUG split, 34% pursuing brownfield strategies, 33% greenfield, and 20% hybrid, with no survey year given. Go to the primary report before you cite any of these.

Greenfield (new implementation): a clean start, paid for in time

A greenfield program builds a new S/4HANA system and moves in only what the business needs. Processes are designed against standard content, and the ECC system stays available as a reference. It is the path where the design conversation matters most, and the one where the testing evidence is easiest to misread.

When a clean start pays off

Greenfield pays off when the process model is already wrong. One migration guide describes a greenfield as a new implementation of S/4HANA built from scratch, with no legacy data or configurations carried forward. That fresh design is what lets you redesign processes instead of replicating them. Each business process gets a fit-to-standard decision, and each decision becomes a test case.

It also gives the cleanest start for a clean core. A Greenfield path allows you to embrace a "Clean Core" strategy, using the SAP Business Technology Platform for extensions rather than modifying the core code. The practical gain is that extensions are designed as side-by-side objects from day one, not inherited from ECC.

Data is the mechanical side of greenfield. Master data and open items move through the Migration Cockpit, run through the LTMC transaction in on-premise and Private Edition projects. Plan loads in waves, reconcile each wave against the source, and keep the reconciliation pack from the first mock load onward. The academy course File and Staging Table Approaches covers the mechanics.

What it costs

Time is the first cost. ASUG's 2026 members who went greenfield averaged 20.2 months to go-live, the longest of the paths they reported. The second cost is change load. Greenfield demands the most change management and redesign effort, and therefore typically takes longer than a brownfield project. Every redesigned process is a training, cutover and support change for the users who ran the old one.

The third cost is parallel running. Until cutover, ECC and the new build both need to be maintained, and interfaces, reporting and month-end may need to feed both. Budget for two landscapes and the people who support them, not just the build team.

The fourth cost is scope. ASUG's 2026 respondents who missed their dates cited business changes (55%), unexpected complexity (45%), and scope creep (42%). A greenfield program is exposed to all three, because the design is open until late in the project. Lock the fit-to-standard decisions with a governance gate and a change log.

Brownfield (system conversion): speed and history, with the old problems

A system conversion takes the existing ECC system and converts its database, configuration and history to the S/4HANA data model. In practice, the existing system ID stays the same. The system must be converted to S/4HANA in one go meaning a single big bang go-live. That single event is the core of brownfield's speed and of its risk.

What moves and what does not

Brownfield keeps everything. Configuration, transactional history, custom code, user roles and master data all carry through the conversion. That is its main advantage for a business that runs well today. Period-end comparisons, audit trails and open-item history do not need to be rebuilt.

The cost is that old problems move with them. Brownfield conversions preserve customizations and historical data but inherit technical debt. Within one system, the conversion is system-wide, so you cannot convert one company code and leave another on ECC. Executing a System Conversion walks through the Maintenance Planner, SUM and follow-up steps.

Custom code, simplification items and the tooling

The custom code is where most brownfield schedules slip. Brownfield requires extensive code remediation to ensure legacy logic remains compatible with the HANA database. Run the Simplification Item Check against the target release to see which simplification items touch your system and your custom objects. The academy's Simplification Items and the Simplification Item Check course covers how to read the results, and Custom Code Migration covers scoping and adaptation.

Why it is faster, and where the speed goes

Brownfield is the fastest path on the averages. ASUG's 2026 brownfield projects took 15.8 months. SAPinsider's 2025 analysis links the short end of its distribution to rapid conversions and the long end to older, heavily customized ECC systems. The speed is real when the system is clean. It is not a shortcut around cleanup.

Selective data transition: the middle path

SDT is a hybrid. SAP positions it as an alternative to both system conversion and new implementation, and it is typically delivered with specialist tools and services. In practice, you build a clean target that carries the structure you need, then move only the data and the processes you have chosen.

Shell conversion and selective transfer

The mechanism is usually a shell. A Shell Conversion is a hybrid migration strategy, often called the "Empty Shell" approach, that sits between a full system conversion (Brownfield) and a new implementation (Greenfield). It is primarily used as part of a Selective Data Transition (SDT). The shell carries the company structure and configuration. The selected clients, company codes and years are then transferred into it.

The selection rules define the program. Plan for three kinds of cut:

• Clients and company codes: which legal entities or business units move, and which stay on ECC for now.
• History: which fiscal years move, and which are archived or left for reporting.
• Processes: which processes are redesigned and which are carried over as they run.

Carve-outs, consolidation and divestitures

SDT earns its place in restructuring work. System consolidation or organizational restructuring is part of the program. Selected history must move, but carrying the entire database is unnecessary. A phased rollout by company code, geography, or business unit reduces risk. The sister guide on SAP in mergers, acquisitions and divestitures covers the consolidation side in more depth.

What it needs

SDT needs specialist skill and disciplined governance. It gives granular control over what is migrated, but requires specialised tooling and expertise, and like greenfield, it typically takes longer than a straight brownfield conversion. In ASUG's 2026 sample, systems integrators and partners were the largest cost, at 37% of the budget. Staff the program for the partner work you will need, and set the scope rules before the partner signs.

The governance you need is a data-scope register: every client, company code, year and master-data object in the transfer, with an owner, an approver and a reconciliation test. The academy course Selective Data Transition Concepts sets out the decisions in more detail.

BrownfieldLow change appetite, high value in config and history. Convert in place, prove nothing broke, and schedule the debt paydown.

SDTHigh change appetite and high value in selected history or structure. Shell build plus selective transfer; prove both sides.

Reassess or two-tierLow change appetite and low value in existing setup. Question the scope before you pick a path; a two-tier plan may fit.

GreenfieldHigh change appetite and low value in existing setup. Rebuild on standard content, load master data and open items.

How deployment target narrows your options

Before you score any criteria, check the target. The target decides which paths are on the table at all.

Public Edition: new implementation only

If the target is SAP Cloud ERP Public Edition, the path is fixed. A 2025 naming change grouped the former Public and Private Edition products under SAP Cloud ERP. Organizations moving from SAP ECC to Public Edition must use a new implementation approach, commonly called greenfield. Public Edition does not support a brownfield conversion, per one 2026 guide, so an ECC system with years of custom ABAP cannot be converted into it.

That does not make Public Edition a clean-slate choice for everyone. It means the program must accept redesign, retirement and selective migration of legacy functions. Treat it as a business transformation with a data load, not a technical move. The academy's RISE with SAP and GROW with SAP for Delivery Teams course is the place to start on the operating-model side.

Private Edition and on-premise: all three paths

Private Edition and on-premise keep the full set of options. Private Edition offers new implementation, system conversion, or selective transition as deployment routes, and on-premise follows the same pattern, using the new implementation method, system conversions, or selective data transition. If your ECC system is heavily customized and you need to keep history, this is the only target where brownfield and SDT remain available.

Keep two decisions separate. Organizations must separately decide on their system transformation approach and their operational model, with RISE with SAP primarily addressing the latter. The transformation path is what this guide is about. The hosting and contract model is covered in RISE vs GROW with SAP. Check the AI-related capabilities for your target edition too. A Community post I checked states that the full Joule and embedded capabilities are available in private cloud only, so confirm the current position with SAP before you rely on it.

Ten decision criteria and a scoring model

Market splits show what other companies picked. These ten criteria show what your landscape can carry. Score them from your own inventory: ATC results, interface counts, a data-scope register and a dated deadline. The scoring method below is our editorial model, not an SAP or ASUG method.

Criterion	How to measure it	Leans brownfield when	Leans greenfield or SDT when
Custom code volume	ATC and Readiness Check counts by object type, with remediation effort	Remediation fits inside the schedule with capacity to spare	The backlog would consume most of the program
Data history needs	Years required for audit, tax and period comparisons	Full history must stay in one system	Only a few years or entities must move (SDT), or history can be archived (greenfield)
Number of ECC instances	Systems, clients, company codes and shared master data	One instance and one process template	Several instances with divergent processes
Process fit	Fit-to-standard gap on the core processes	Most processes fit standard after review	The process model itself must change
Downtime tolerance	Permitted cutover window and the business calendar	A long single window is acceptable	Only short windows, so staged loads are needed
M&A and divestiture	Pending deals and entities to separate or combine	No pending deal touches the landscape	A carve-out, divestiture or consolidation is pending (SDT)
Timeline to 2027 or 2030	Months from scope sign-off to the ECC end date	The date is fixed and the team needs the fastest route	There is room to redesign before the date
Budget	Funding for partners, parallel running and change	Funding is tight and custom code is clean	Funding covers redesign, parallel running and loads
Skills	Internal ABAP, conversion and data migration depth	Strong internal conversion and ABAP skills	Strong process design, or a specialist partner for SDT
Regulatory retention	Legal retention periods for financial data and audit trails	Conversion keeps the required history in place	Retention is met by archive or read-only ECC, or by a selected data set

How to score it

1. Apply hard constraints first. If the target is Public Edition, the answer is greenfield and you do not score.
2. Have the steering committee set the weights before anyone scores. As a starting point, weight custom code, history and deadline at double. Record any change.
3. Score each criterion from 1 to 5 for each path, where 5 means the criterion strongly favors that path.
4. Total the weighted scores. If two paths are within a few points, decide on the evidence you can produce by the sign-off date, not on the higher total.

1. Is the target SAP Cloud ERP Public Edition?Yes → new implementation (greenfield) only · No → next question
2. Do you need only some clients, company codes or years?Yes → selective data transition · No → next question
3. Is the process model sound, and can the custom code be remediated inside the deadline?Yes → brownfield (system conversion) · No → greenfield, or a two-tier plan

What each path does to testing, data validation and cutover

The path decides the evidence pack. All three need gates, but each gate proves something different.

Path	Testing must prove	Data validation must prove	Cutover must prove
Greenfield	Each redesigned process runs end to end and users can do their jobs in it	Each load wave reconciles to source, with variances explained and signed	Mock loads hit the runbook timings and hypercare exit criteria are met
Brownfield	Existing processes behave as before, plus simplification-item impacts and remediated custom code	Before-and-after totals match on trial balances, open items, stock and key reports	Conversion rehearsals fit the downtime window, with a rollback point
SDT	Both: the new shell works end to end and the moved scope still runs	Each transferred scope reconciles, and data left behind is shown to be untouched	Both evidence sets, plus the seam between moved and unmoved data

Greenfield. The common mistake is treating loads as a data task. Each fit-to-standard decision should become a test case, and the UAT plan should follow those cases. ISG's researchers argue that buyers need named delivery owners and independent checks on data readiness and integration testing, To effectively govern SAP migration, enterprises need to explicitly define delivery ownership and maintain independent oversight of critical activities such as data readiness, integration testing and change management. Use the data reconciliation and validation sign-off course to build the load evidence, and the Data Migration Reconciliation Checklist to keep it.

Brownfield. Your regression set is the business you already run: period close, order-to-cash, procure-to-pay and the interfaces that feed them. Capture the same reports and totals from ECC before the conversion, then repeat them on the converted copy. Add simplification-item tests scoped from the Simplification Item Check results. The Simplification Item Check course covers how to read them, and the phase-by-phase testing plan shows where these tests sit.

SDT. You prove both sets of evidence, plus the seam. Intercompany postings, shared master data and interfaces that cross the boundary are where moved and unmoved data disagree. Write one test per boundary and keep it in the scope register. ISG's research points to a lack of clear decision-making rights and acceptance criteria between integrators as a primary driver of delays. Put acceptance criteria for each partner in the contract before the seam tests start.

Cutover. Early estimates often leave out the stretch when ECC and S/4HANA run side by side during testing and cutover. Custom code remediation, and the dual-run period when ECC and S/4HANA operate in parallel during testing and cutover, are consistently omitted from initial migration estimates. Rehearse with the Mock Cutover Rehearsal Tracker and the data migration testing course.

Cost and timeline: what drives each path

Cost and duration depend on system size, data volume, custom code and deployment model. No path has a fixed price, but each one spends money in a different place.

Cost drivers by path

• Brownfield: custom code remediation, regression test volume and conversion tooling. Redesign cost is lower, but the debt stays. Keeping customization debt, one vendor guide argues, adds recurring costs for infrastructure, upgrade management and custom code regression testing on each release.
• Greenfield: process redesign, change management, data cleansing and load build, and parallel running. Parallel running is often underestimated. Legacy systems often do not get fully turned off, so that cost never goes away.
• SDT: shell build, specialist tooling and partner hours, scope governance, and running two data sets through the same test cycles. The shell conversion term covers the build.

Durations

ASUG's 2026 members averaged 15.8 months for brownfield and 20.2 months for greenfield. The bars below show those averages only. The sources I checked did not give an ASUG SDT average, so none is shown.

Source: diginomica, reporting ASUG research, 2026. Averages across self-selected members with different scope. Check the start and go-live definitions before you reuse them.

Vendor guides publish other ranges, and they do not agree with each other. One puts brownfield at 12-18 months and greenfield at 24-36 months. A mid-market guide gives 6–12 months for brownfield and 12–24 months for greenfield. Use these to challenge your estimate, not to set it.

Overrun data. Horváth's 2025 study of 200 large SAP users found that 60% exceed budget; only 8% finish on schedule. The same study put the average implementation 30% longer than originally anticipated. Its main cause was scope expansion, ahead of suboptimal project delivery and poorly managed data transition. Some write-ups describe the 30% as a budget overrun instead. One reports that completed S/4HANA projects ran an average of 30% over budget. Check the primary report before you quote the number.

ISG's February 2026 report found that nearly 60 percent of SAP migrations are behind schedule and over budget, most often due to underestimated complexity, expansion of scope and internal capacity constraints. Its separate Index Insider analysis reported 58% of SAP migrations over budget and behind schedule, and only 15% on budget and on time. The ISG figures use different samples and definitions, so neither compares directly with ASUG's member averages.

1. Q4 2026Path and target decisionScoping record names the edition, the path and the hard constraints
2. Q1 2027Evidence baselineReadiness Check, custom code sizing and a data-scope register
3. 2027Build and rehearseMock loads or conversion rehearsals, with reconciliation at each gate
4. 31 Dec 2027ERP 6.0 mainstream maintenance endsFor Enhancement Packages 6 through 8
5. 2030Extended maintenance endsExtra fees apply under extended maintenance

Hybrid and phased variants

Most large programs end up as a variant of the three paths. Two patterns come up often.

Convert first, then optimize

Convert the system technically, then release process and extension waves after cutover. A brownfield migration is viable for organizations with well-maintained ECC systems that have current support packs, clean customizations and operational alignment. ASUG also advises starting with minimal necessary changes to achieve some transformative value, avoiding overly ambitious brownfield approaches.

Converted coreECC configuration, history and data on S/4HANA through system conversion, same system

Remediated custom codeOnly objects that passed the ATC and remediation gates stay; the rest are retired

Clean-core extensionsNew logic built on SAP Business Technology Platform, added after cutover

Process innovation wavesRedesigned processes released one area at a time, each with its own UAT

Moving custom logic out of the core also reduces later test effort. Isolating custom development on SAP BTP instead of modifying the S/4HANA core reduces the volume of custom objects that require regression testing at every upgrade cycle. Keep the conversion baseline. Each innovation wave changes a process, so it needs UAT on that process and regression on everything else.

Wave-by-wave greenfield

Build the target once, then move business units in waves. Each wave has its own load, cutover and interface switch, and ECC stays live until the last wave. SAP's own learning material shows a mixed pattern as well: a converted Private Edition for headquarters, with a Public Edition subsidiary alongside it. For example, the SAP ECC system is converted to SAP S/4HANA Cloud Private Edition for the headquarters, and SAP S/4HANA Cloud Public Edition is deployed for a specific line of business, subsidiary, or in-house start-up. Each wave multiplies reconciliation and N+1 test runs, so plan the cycles with the N+1 landscape testing guide.

Worked scenarios: three archetypes

These are composite archetypes, not client cases. The paths are our judgment. The reasoning is the part to reuse.

Single-instance manufacturer

Profile: one ECC production system, moderate custom code concentrated in planning and quality, a long history that auditors request, and a 2027 deadline. Path: brownfield, provided the ATC backlog fits the schedule. The process model works and history stays in place. Run a fit-to-standard review alongside, and schedule the debt paydown after cutover. Sign-off evidence: regression across planning and costing, plus before-and-after checks on stock and cost values. Planning changes such as the MRP Live setup need their own test cases.

Multi-ECC global group

Profile: four ECC instances with different charts of accounts and process variants, and a board that wants one template. Path: greenfield for the global template, with wave loads of master data and open items from each instance. If one instance holds history the group must keep, use SDT for that instance alone. Why not convert in place: four brownfield conversions would carry four process models into the new system. Sign-off evidence: reconciliation per instance and per wave, intercompany eliminations and consolidated reporting. The Intercompany and Elimination Test Matrix covers the eliminations.

Carve-out under deadline

Profile: a parent sells a business unit, the separation date is fixed, and the unit's data sits with the parent's shared ECC client. Path: SDT. Build a shell with the unit's company codes and structure, move the open items and the years auditors need, and cover shared services under a transition services agreement. Why not the others: brownfield cannot convert one company code and leave the rest behind, and greenfield is rarely the fastest route to a fixed date with the history a buyer needs. Sign-off evidence: carved-out balances reconciled to the pre-close position, access cutoff tests and proof that the parent's data stays clean. The Carve-Out Data Separation and Access Cutoff Plan and the M&A consolidation guide cover the detail.

The bottom line

Choose the path your evidence can support by the gate, not the one the survey favors. Brownfield is the fastest route when the process model and custom code are sound. Greenfield earns its time when the process model has to change. SDT fits partial scope, carve-outs and consolidations, and it demands the most governance. Write the evidence pack into the scoping record now, while the 2027 date still leaves room to act.

Frequently asked questions

What is the difference between greenfield and brownfield in SAP?

A brownfield migration takes the existing ECC system and technically converts it to run on S/4HANA, preserving existing configurations, custom code, and data models. Greenfield starts fresh: processes are redesigned, custom code is rationalized, and the system is built around SAP standards rather than legacy assumptions. The greenfield and brownfield glossary entries give the terms in more detail.

What is bluefield in SAP S/4HANA?

Bluefield is the partner and user-group name for selective data transition. Bluefield, formally Selective Data Transition, is a hybrid. An ASUG article prints the name with a registered-trademark symbol, Bluefield® Migration, which suggests a registered mark. I did not check a trademark register, so use SAP's term in contracts.

Which is better for S/4HANA, greenfield or brownfield?

Neither is better in general. A brownfield migration is viable for organizations with well-maintained ECC systems, while greenfield implementations suit firms undergoing deep restructuring or dealing with fragmented architectures. Score the ten criteria above and let the hard constraints, especially the target edition, make the first cut.

Is selective data transition the same as bluefield?

In practice, yes. SAP's term is selective data transition, and bluefield is the partner label for the same middle path. Unlike brownfield and greenfield, which handle SAP S/4 HANA migration with a broad brush, bluefield allows businesses to be more selective in their migrations. Name the scope explicitly in the contract either way.

Can I do a brownfield conversion to SAP S/4HANA Cloud Public Edition?

No. System conversion is not supported for SAP S/4HANA Cloud Public Edition. Moving from ECC to Public Edition is a new implementation, while conversion targets Private Edition or on-premise. Put the target edition and the allowed path in the scoping record before design starts.

How long does a greenfield vs brownfield S/4HANA project take?

ASUG's 2026 members averaged 15.8 months for brownfield and 20.2 months for greenfield, as charted above. Those are averages across members with different scope, so treat them as a reference point. Horváth's 2025 research found that implementations ran 30% longer than originally anticipated, so build a buffer into either path.

What are the steps in an SAP brownfield implementation?

A brownfield project usually starts with the Readiness Check, then sizes custom code and simplification impacts. Next comes the custom code migration work, the system conversion execution with the Maintenance Planner and SUM, and then regression and before-and-after checks. The last steps are conversion rehearsals and the cutover and downtime plan.

Sources

1. Conversion Guide for SAP S/4HANA 2025 (Document Version 3.0, FPS02), SAP SE (SAP Help Portal), 2026-10-07
2. ECC to S/4HANA: Brownfield, Greenfield or Selective Data Transition?, SAPinsider
3. Brownfield, Greenfield or Bluefield: Choosing the Right SAP Migration Path With the Data, SoftwareSeni (citing ISG 2026)
4. How are ERP customers faring with AI readiness? ASUG research reveals S/4HANA migrations are accelerating, diginomica (ASUG research), 2026-10-06
5. SAP S/4HANA migration timelines: the average, the range and the factors behind both, SAPinsider blog, 2025
6. Rising up to the cloud: SNP publishes meta-study on S/4HANA migrations, SNP Group
7. SAP ECC to SAP S/4HANA Migration, Software Modernization Services (vendor page)
8. SAP brownfield migration: what it preserves and when to use it, ITchamps
9. SAP Greenfield Implementation: 2026 CIO Strategy Guide, ITchamps
10. Why 60% of SAP Migrations Fail (And How to Succeed), ITchamps, 2026
11. SAP Cloud Migration Budget Overrun Causes and How to Prevent Them, Kagool
12. Why SAP Migrations Fail at a Rate That Should Concern Every Decision Maker, SoftwareSeni
13. Firms Moving to SAP S/4HANA Prioritize Short-Term Stability Over Long-Term Transformation: ISG Study, ISG, 2026-02-02
14. Index Insider: Only 15% of SAP Migrations Are on Time and on Budget, ISG
15. Why 60% of SAP S/4HANA Migrations Miss Their Deadline, Qyrus (citing ISG, February 2026)
16. Most SAP migrations bust budgets and project timelines, research finds, EasySAM, 2026-02-06
17. SAP Cloud ERP vs. S/4HANA Cloud: Public or Private?, NBS
18. Defining the SAP Cloud ERP Solutions and Implementation Methods, SAP Learning
19. Greenfield vs Brownfield vs Bluefield: S/4HANA Migration, Embee
20. Bluefield: Navigating a Best-of-Both-Worlds Approach to SAP S/4HANA Migration, ASUG
21. Mitigate Risks and Downtime for Your Utility's Digital Transformation with a Bluefield Migration, ASUG, 2025-10-29
22. Why Organizations Should Consider Modular Cloud Solutions Before Full S/4HANA Adoption, ASUG, 2025-06-26
23. How CFOs Can Compare SAP S/4HANA Migration Costs and Estimates, LeverX
24. SAP ECC to S/4HANA Migration Strategies: Brownfield, Greenfield, and Selective (Bluefield) Transition, Orpington Technologies (citing ASUG research)
25. ECC to S/4HANA Migration: The End-to-End Guide (2026), The Sign-Off Table
26. Testing an ECC to S/4HANA migration: a phase-by-phase plan, The Sign-Off Table
27. Brownfield vs greenfield for S/4HANA: a decision tree, The Sign-Off Table
28. The S/4HANA migration by the numbers, and what they mean for your test plan, The Sign-Off Table
29. SAP N+1 Landscape Testing, The Sign-Off Table
30. MRP Live in S/4HANA: MD01N vs Classic MRP Setup, The Sign-Off Table
31. SAP in mergers, acquisitions and divestitures, The Sign-Off Table
32. RISE vs GROW with SAP: Which One Fits You in 2026?, The Sign-Off Table
33. Migration Cockpit, The Sign-Off Table glossary
34. LTMC, The Sign-Off Table glossary
35. Selective data transition, The Sign-Off Table glossary
36. Shell conversion, The Sign-Off Table glossary
37. Greenfield, The Sign-Off Table glossary
38. Brownfield, The Sign-Off Table glossary
39. SAP S/4HANA Migration Cockpit: File and Staging Table Approaches, The Sign-Off Table Academy
40. Data Reconciliation and Validation Sign-Off, The Sign-Off Table Academy
41. Selective Data Transition Concepts, The Sign-Off Table Academy
42. RISE with SAP and GROW with SAP for Delivery Teams, The Sign-Off Table Academy
43. SAP Readiness Check for SAP S/4HANA, The Sign-Off Table Academy
44. Simplification Items and the Simplification Item Check, The Sign-Off Table Academy
45. Custom Code Migration: Scoping, Remote ATC and Adaptation, The Sign-Off Table Academy
46. Executing a System Conversion: Maintenance Planner, SUM and Follow-Up, The Sign-Off Table Academy
47. Conversion Cutover and Downtime Planning, The Sign-Off Table Academy
48. Testing Data Migration: Mock Loads, Reconciliation and Sign-Off, The Sign-Off Table Academy
49. Data Migration Reconciliation Checklist, The Sign-Off Table templates
50. Mock Cutover Rehearsal Tracker, The Sign-Off Table templates
51. SAP Intercompany and Elimination Test Matrix, The Sign-Off Table templates
52. SAP Carve-Out Data Separation and Access Cutoff Plan, The Sign-Off Table templates