Choosing Between SDT, Brownfield and Greenfield

These are the three standard transition strategies for moving from an ECC (or older SAP) system to S/4HANA. Greenfield means a fresh implementation: new system, new configuration, new org structure, with historical data either left behind or loaded separately as static reporting data. Brownfield means a technical conversion of the existing system: same configuration, same customizations, same master data, same transaction history, just running on the new stack and data model. SDT sits between the two: a new target system is built, but selected data objects (open items, specific master data, specific years of history, specific company codes) are migrated in from the old system using dedicated migration tooling, while everything else is rebuilt fresh. The structural fact that causes most confusion: these are business scoping decisions dressed as technical categories. Two projects both called 'brownfield' can differ enormously depending on how much cleanup, custom code remediation and process redesign is bundled into the conversion.

Greenfield fits when the current system is heavily customized, process fit is poor, the org structure needs to change (new chart of accounts, new company code structure, new controlling design), or the business wants to reset technical debt entirely. It is a mistake when the business cannot absorb process change or when the team underestimates the effort of rebuilding years of configuration from nothing. Brownfield fits when current processes work well, customizations are still valid, data volumes and history matter for compliance or reporting, and the goal is a technical platform move with minimal business disruption. It is a mistake when it is used to avoid confronting bad configuration or unsupported custom code that should have been retired years ago. SDT fits carve-outs, mergers, regional consolidations, or any scenario where the org structure changes but specific legal or financial history must legally or operationally survive the cutover. It is overkill for a single, clean, single-country system with no organizational change.

Above this decision sits the program-level business case: how much process redesign, how much risk tolerance, how much budget and timeline. Below it sit the actual technical mechanisms. Brownfield is executed with in-place conversion tooling that runs simplification item checks, custom code remediation, and data model conversion (including business partner conversion) against the live system. Greenfield is executed as a fresh SAP Activate implementation with data migration handled by standard migration cockpit or equivalent load tools, usually loading only master data and opening balances, not transaction history. SDT is executed with dedicated landscape transformation and selective migration tooling that extracts, transforms and loads chosen data sets from a source system into a freshly built target, running in parallel with a greenfield-style build of everything else. None of the three technically replaces another; they replace the older framing of 'technical upgrade versus reimplementation' as a binary choice.

A group runs six regional ECC systems after years of acquisitions. The target is one S/4HANA instance with a harmonized chart of accounts and a single controlling area. Two of the regions have clean, well-run finance operations with large open item volumes and audit requirements reaching back several years; the other four have messy, redundant configuration nobody wants to carry forward. The program decides on SDT: a single new S/4HANA system is built with the new harmonized org structure, chart of accounts and controlling design from scratch, following standard implementation methodology. For the two clean regions, open items, customer and vendor master data, and a defined window of financial history are extracted from the legacy systems and loaded into the new target using selective migration tooling, mapped against the new chart of accounts. For the other four regions, only current master data and opening balances are loaded, effectively greenfield within the same program. The result is one target system built once, with two different data-loading strategies applied to different legacy sources feeding into it.

An architect works through this as a set of weighted questions, not a checklist to tick.

Mislabeling the project causes most of the downstream damage.

Clean core thinking favors greenfield or SDT over brownfield, because brownfield by design carries forward existing custom code and configuration, some of which will conflict with the extensibility model S/4HANA and clean core practices push toward. Brownfield remains a legitimate and common path where process fit is genuinely good, but it is increasingly paired with a mandatory custom code remediation phase rather than treated as a pure technical lift. SDT is often positioned as the pragmatic middle path for organizations that want a clean core target without discarding data that has real legal or financial value. None of the three paths is deprecated; the shift is in how much cleanup is now expected to accompany brownfield rather than being optional.

This is an architecture-level decision, owned by the solution or enterprise architect together with the program sponsor, not by a technical lead alone. Functional consultants own the process fit assessment and data retention requirements that feed the decision. The handover to technical teams is a scoped statement of what moves, what is rebuilt, and what tooling executes each part.

Simplification items and how to read them is required reading before committing to brownfield, since the volume and severity of hits determines whether a technical conversion is realistic. Business partner conversion and CVI is relevant to all three paths since customer and vendor master data restructuring happens regardless of which route is chosen.