Where selective data transition fits

Every move from SAP ERP to SAP S/4HANA starts with one big decision: how do we get there? SAP describes three transition paths. A new implementation builds a fresh system and loads master data and open items into it. A system conversion converts the existing system in place, keeping its configuration, custom code and all of its history. Selective data transition (SDT) sits between the two: you build or reuse a target system and then move only the configuration, code and business data you choose.

SAP Learning describes SDT as moving selected business data and configuration from SAP ERP to SAP S/4HANA, and notes that it can be combined with elements of both a new implementation and a system conversion. In the market you will also hear it called "bluefield", a nickname that sits between "greenfield" (new) and "brownfield" (conversion). The nickname is informal; SAP's own term is selective data transition.

What can be selected

SDT treats the old system as a set of layers you can take or leave. SAP Learning lists four: the ABAP repository (programs and other development objects), configuration (customizing), master data, and transaction data, which can include open items plus a time slice of historical closed items, such as the last two years. Each layer is a separate decision, made by different people for different reasons.

Who delivers SDT

The data movement in SDT is a specialist job. SAP provides it through its Data Management and Landscape Transformation (DMLT) software and services, formerly known as SAP Landscape Transformation (SAP LT), which SAP uses for scenarios such as merging systems, moving business units and migrating selected applications. Since 2024 SAP has also offered lean selective data transition inside SAP Business Transformation Center, a cloud service that runs on SAP Cloud ALM and comes with RISE with SAP. It lets customers scope data by company code and time slice, extract, transform, load and validate it. Partners offer their own SDT tooling as well; whichever you use, the concepts in this course apply.

Why programs choose it

The case for SDT is usually one or more of these: the business wants to keep proven processes and some history but not 20 years of clutter; several ERP systems or clients must be merged into one; a business unit must be split off or a divested company code left behind; or downtime and data volume rule out converting everything. SAP's own messaging for lean SDT stresses a cleaner data foundation and less data to test and take live.

Contoso Motor Co. faced this choice in its Discover phase. Grace, the PMO lead, ran a short assessment with the solution architect, Dan for finance and Priya for testing. They weighed all three paths and chose a system conversion of ECC 6.0 EHP 8 to SAP S/4HANA Cloud Private Edition under RISE with SAP: Contoso runs a single ECC system with nothing to merge or carve out, most of its processes and configuration were worth keeping, and Dan wanted its full finance history in the new system. A new implementation would have meant redesigning processes the business was happy with; SDT, for example a shell conversion with a time slice, would have trimmed history Dan wanted while adding transfer design, specialist services and extra test cycles. This course replays that evaluation and asks what would have changed, especially for testing, if Contoso had picked SDT instead.