Comparing Migration Approaches: Trade-offs, Data Volume, and Deployment Fit
Explores the practical trade-offs between greenfield, brownfield, and selective data transition approaches, focusing on data volume, downtime, custom code, and deployment model constraints.
Explanation
Once the foundational concepts of greenfield, brownfield, and hybrid migration are understood, the intermediate-level work is comparing these approaches against concrete project constraints: data volume and quality, downtime tolerance, custom code footprint, integration complexity, and target deployment model. This lesson builds the analytical framework an architect uses to move from 'there are three options' to 'here is the recommended option and why.' Data volume and history is often the first practical differentiator. Brownfield conversions carry the full transactional history of the source system by default, because the conversion operates on the existing database structures and content. This is efficient in the sense that no historical data re-entry or transformation is required, but it also means that legacy data quality issues, orphaned records, and outdated master data structures come along for the ride unless a data cleansing project happens before conversion. Greenfield implementations, by contrast, typically bring over only master data and a limited window of open transactional data (open orders, open items), with historical data left in the legacy system or a dedicated archive/reporting environment. Selective data transition approaches use specialized tooling to migrate specific data selections (for example, specific company codes or a defined historical window) into a new system shell, offering a middle ground but requiring careful scoping because partial data migration can create reconciliation and reporting gaps if not planned carefully. Downtime is a second major axis. Brownfield system conversions generally require a technical downtime window during which the database and application layer are converted; the length depends on database size, custom code volume needing pre-checks, and infrastructure performance. For very large ECC systems, this downtime can be substantial unless downtime-optimized conversion techniques are used. Greenfield implementations do not have this single 'big bang' downtime constraint in the same way, but they introduce cutover complexity of their own: parallel operation of legacy and new systems, data migration cutover windows, and business process cutover coordination across potentially many go-live waves if rolled out by country or business unit. Custom code is a third differentiator, and increasingly the most strategically important one in the context of Clean Core guidance. Brownfield conversions carry forward existing custom code, which must be checked for compatibility with the target release (for example, checking for use of objects that are obsolete or restricted in S/4HANA) and ideally remediated to reduce reliance on modifications to the standard core, favoring extensions on BTP where new functionality is needed. Greenfield implementations offer a natural opportunity to leave behind unused or poorly maintained custom code, but only if the organization has strong governance to avoid simply re-creating the same technical debt in the new system under a different name. Deployment model fit is the fourth and often decisive factor. S/4HANA Public Cloud has a standardized core with a defined, limited set of extensibility options, meaning that many forms of brownfield conversion (which assume carrying forward deep customizations) are not applicable; organizations targeting public cloud most often pursue a greenfield-style implementation using cloud extensibility patterns from day one. S/4HANA on-premise and private cloud editions retain more flexibility for custom code and therefore make brownfield conversion technically viable, though not always advisable from a Clean Core standpoint. Architects should explicitly confirm the target deployment model before finalizing the migration approach recommendation, because a mismatch here can force a costly re-scoping mid-project. Finally, integration complexity should be assessed: systems with many tightly coupled point-to-point interfaces to the ECC system require careful interface inventory and re-testing regardless of approach, but brownfield conversions may preserve more interface compatibility initially, while greenfield implementations often require interface re-architecture as part of the broader redesign.
Real project scenario
A retail organization operating across 12 countries needed to decide its migration approach for a multi-year S/4HANA program. The architecture team built a scoring matrix across five dimensions: data volume/history requirements, downtime tolerance (the business could not accept more than a 48-hour cutover window during peak season), custom code footprint (an inventory found over 400 custom programs, many undocumented), integration complexity (60+ interfaces to third-party logistics and payment providers), and target deployment (private cloud, chosen for regulatory data residency reasons). The scoring matrix, presented to the steering committee, showed brownfield scored well on downtime and interface compatibility but poorly on custom code health; the final decision was a phased brownfield conversion per country, paired with a mandatory custom code remediation sprint prior to each country's cutover, rather than a single global choice.
Common mistakes
• Comparing approaches only on cost and timeline while ignoring custom code and Clean Core implications • Assuming public cloud deployment supports brownfield-style customization carryover • Underestimating downtime for brownfield conversion on very large databases without evaluating downtime-optimization techniques • Selecting a hybrid/selective data transition approach without a clear reconciliation plan for the data left behind • Failing to inventory interfaces before choosing an approach, leading to late discovery of integration rework scope
Best practices
• Build a structured comparison (data, downtime, custom code, integration, deployment fit) rather than relying on approach reputation or past project experience alone • Confirm target deployment model constraints before evaluating brownfield feasibility • Run a custom code inventory and compatibility check early, regardless of chosen approach • Plan for interface inventory and re-testing scope as a distinct workstream in the architecture • Use phased or country-by-country approaches for large multi-entity organizations rather than forcing a single global decision when constraints differ by entity
Interview angle
Expect scenario-based questions asking you to recommend an approach given specific constraints (for example, 'a customer has 40TB of data, wants minimal downtime, and is targeting public cloud — what do you recommend and why?'). Strong answers explicitly weigh multiple factors (data, downtime, custom code, deployment model, integration) rather than jumping to a single answer, and acknowledge trade-offs and residual risk in the chosen path.