It is possible and a recommended approach. SAP Activate methodology includes content and accelerators for SDT projects. They could be found in the Roadmap Viewer(opens in new tab).

Summarized information could be found in SDT Whitepaper. Details can be provided by SDT Community members on the project basis.

The time frame for the implementation of a SDT project with a Selective Data Transition to SAP S/4HANA depends on various factors. Please see question “What are the costs? What about the complexity and the duration of this approach?“ for the typical cost drivers which in turn also influence the overall complexity and duration of such a project.

The costs and complexity depend on the scope of the selective data migration and the overall projects-For example,  a shell conversion approach with limited adoptions (e.g. CoA harmonization) will be more standardized with less costs and complexity than migrating data into a newly installed S/4HANA system. In addition, the complexity can increase if too many activities, which can be done upfront or after the transition to S/4HANA, will be covered with the SDT.

Typical cost drivers include:

· The number of relevant source systems and clients

· The release level of the source systems (e.g. “ancient” sources such as SAP R/3 4.6 will mean higher efforts than using SAP ECC or Suite on HANA as sources)

· The design of the target system landscape, i.e. the number of systems, clients, and location (on premise vs. private cloud)

· The number of phases or waves of production cutovers

· Possible requirements for downtime minimization (performance tuning) or near-zero downtime

· Modules and business processes in use

· Testing and Industry specific data validation requirements

· Regions, users and end user-trainings

· Potential SAP system decommissioning

· Retrofitting reporting requirements or integration with Data Warehouses and / or Data Lakes

Selective Data Transition (SDT) can be implemented in different project methodologies such as PMI, Prince, or hybrid approaches. For certain streams of the project (e.g. code remediation), also agile methodologies such as SCRUM may be advisable. However, while SDT can be embedded in different project methodologies, certain project aspects are centered around sequential test cycles which are followed by functional tests according to classical SLO (System Landscape Optimization) best practices. This implementation approach – while compatible with various project management standards and procedures – is tested and proven in 20+ years and countless transformation projects including technical transformations, system upgrades, system consolidations, and harmonization and M&A scenarios.

The recommendation whether to do all preparation (like process harmonization, system consolidation), migration and post-processing steps in one project or divide it into two or more projects depends on the customer’s situation. For example, if there is a business case that requires the move to SAP S/4HANA fast to allow execution of digitalization projects (maybe for a dedicated company code).

There is no safeguarding and no sign-off of intermediate or end results and key deliverables by SAP for projects delivered by a partner, yet. However, members of the SAP S/4HANA Selective Data Transition Engagement have agreed to qualitative standards and common approaches utilizing SAP Activate methodology and deliverables as well as quality gates defined therein. The partners are using their own tools and products among other solution. SAP is hosting member of this group.

SAP does not certify, qualify, endorse or rate a solution, approach or product of partners nor does SAP highlight or recommend a specific solution, approach or product of partners to carry out a Selective Data Transition.

SAP advises its customers to be conscious about possible implications related to SAP S/4HANA Selective Data Transition. In case inconsistencies or other issues in the regular SAP transactions arise during an SAP S/4HANA Selective Data Transition project executed by SAP, these may be possibly tracked and corrected by SAP under the SAP Support Agreements.

Inconsistencies or issues which arise from the use of non-SAP tools are not covered by the SAP Support Agreements and may prevent SAP from being able to identify and assist in the correction of potential problems which, in turn, may possibly result in unsatisfactory software performance for which SAP cannot be held responsible.

A project quality gate is a formal element of the SDT project method where key deliverables are checked against defined objectives or standards. Q-Gates are part of project work and executed by the partner serving the customer in the project. SAP performs SDT Q-Gates only for projects where SAP delivers the SDT migration. SAP does not provide quality assurance (and thus Q-Gates) for SDT projects performed by Partners with non-SAP SDT Tools or Products.

A Quality Gate provides oversight and early visibility into potential risks and issues. It has a profound impact on reducing project risk and driving Customer Value.

Five Quality Gates are scheduled to prove whether we are able to:

• Be on track

• Complete our deliverables according to plan

• Fit for purpose

• Systematically manage the risks

• Start the next phase without delay

Note: A Quality Gate does not represent a check by SAP and SDTE in regard to technical, functional and business logic of the Selective Data Transition project running under a partners' responsibility. 

Unfortunately, no general statement is possible. The actual downtime heavily depends on the size of the system (i.e. the volume of data to be transferred) and also on dependencies of tasks within the cutover activities (e.g. hybrid approach with finance postings and DB migrations). For large systems and customers with specific (i.e. short) downtime windows there are options for downtime optimizations from all members. This might  include scope, organizational, hardware and other technology measures and combinations of them.

A selective data transfer from SAP S/4HANA to SAP S/4HANA  can be utilized to implement for example a carve-out scenario in a classical transformation scenario in the context of M&A (Mergers & Acquisitions). There may be restrictions or additional considerations depending on the choice of tools, technology and release levels. For example, it is usually not possible to implement downgrades, i.e. migrations from a higher release to a lower release.

The Selective Data Transition supports migration to SAP S/4HANA Private Cloud Edition (PCE) provided within SAP RISE transition package. The solution must follow the SAP Cloud roadmap and strategy and can therefore only be implemented in coordination with SAP RISE services. It must be ensured that the migration is carried out with and according to the standards, methods, content and, if necessary, also on a technology / platform provided by SAP. The Selective Data Transition also suits for the SAP S/4HANA On-Premise Edition. A Selective Data Transition into the SAP S/4HANA Public Cloud is not supported.

Regarding the costs and efforts involved in a selective transfer (“Is a Selective Data Transition cheaper?”): Usually, when choosing the best, most suited, and most practical approach for the data transfer (i.e. the data migration), the costs and efforts involved are not the initial driver for decision making. Instead, it is important to consider different questions before, and then compare the possible solutions. In this comparison, the overall costs and efforts are typically one of several crucial factors.

When comparing between approaches, the options next to the Selective Data Transition are typically “greenfield” approach and “brownfield” approach. To give an idea, this is an incomplete list of things to be considered when comparing the overall SDT costs and efforts in comparison to a “greenfield” and “brownfield” approach:

• With SDT, a smaller HANA DB size is possible which means a possible reduction of hardware costs, software licenses & subscriptions, and simplicity in system landscape management (e.g. backups, restore, system copies to non-production systems, performance, etc.)
• With SDT, it is possible to keep a higher level of business continuity, simplify historical reporting, and make the transition to S/4HANA easier for end users.
• With SDT, it is possible to minimize the external impact of a S/4HANA transition, e.g. by ensuring that open purchase orders or customer orders or invoices keep the same document number in S/4HANA as they had before.
• The implementation of a selective data transfer however can mean increased efforts for the implementation of the data selection rules and for testing.
• For all approaches, but especially for SDT and greenfield, legacy SAP system retirement (decommissioning) should be considered.
• With SDT, but also with greenfield, it is possible to implement a phased approach of data migration, e.g. company code by company code.
• SDT can help minimize downtime requirements, i.e. a reduced runtime of the actual data migration is feasible.
• SDT may involve a dedicated project methodology (test cycles) and test methodology to not only involve business processes, but also data integrity across modules, processes and time slices.
• With SDT, but also with greenfield, it is possible to include data cleansing and exclude “rubbish” data.

In a New Implementation, e.g. using the greenfield approach, the SAP S/4HANA migration cockpit is SAP’s recommended tool of choice to migration business data to the SAP S/4HANA target system. It loads data via SAP standard API and offered preconfigured data migration for master data, open items and balances.

Some data areas in a selective transfer may be based on the Migration Cockpit, but above and beyond this, SDT typically uses a dedicated set of specialized tools, combined with expert services. Typically, this includes migrating a certain amount of historical data. For example, you could transfer financial documents of the last 2 years, or you could transfer data belonging to long running projects.

One of the key strengths of the Selective Data Transition is that it represents an attractive mixture of the “brownfield” and “greenfield” approaches, because it combines advantages from both approaches. SDT offers customers a high level of flexibility with multiple options in the context of data selection, transfer and process harmonization to the future SAP S/4HANA system.

Typically, preserving business process, ensuring business continuity are among these. Of course, also allowing customers to cherry pick between existing processes and using new and improved S/4HANA options (e.g. Fiori applications) while providing a subset of historical data from the legacy SAP systems is a key strength of the SDT approach.

The Selective Data Transition approach works for all industries. However, to cover certain industry specific processes and requirements, or perform consistent data selection and transfer in industry specific data models (e.g. in SAP industry solutions such as IS-U or AFS), special transformation content or expertise may be required. This may impact the choice of tooling or implementation partner (Community).

A System Conversion is an in-place conversion of the existing ECC system, the full set of data remains in the system. In addition also the business processes configured in the system remain basically as they are, except necessary adaptations resulting from data model changes or simplifications.

A Selective Data Transition is a data migration into S/4HANA system with selective scope and individual transformations. The ECC system will be still available after the migration. Within a Selective Data Transition, you get the option to transfer less data and leave selected data behind. For example, data belonging to obsolete company codes could be left behind. You also have the possibility to select process- or module-wise which processes you want to continue with.

In the end there is no right or wrong. Each customer must choose the option that will enable them to continuously introduce SAP innovations in the future.

Yes, it’s mandatory functionality in S/4HANA. It is also can be activated in ECC as a pre-project together with new G/L and the ledger solution.

Technical activation of NewGL itself is mandatory in S/4HANA even if parallel ledgers and doc split are not used.

In standard scenarios, i.e. the System Conversion, no new G/L functionalities ( e.g. new parallel ledgers, document split) can be introduced during the transition project. Depending on choice of implementation partner and tooling, the NewGL can be implemented during the SDT project.

Material valuation is done only using Material Ledger functionality in S/4HANA. Material Leger technical activation is mandatory. Actual Costing functionality is optional.

It is necessary to use Business Partners to manage customers and vendors roles on S/4HANA. However, the business partner functionality can be introduced either during the migration to S/4HANA or before.

The new cash management data will be built up by standard transactions, reading data from various modules.

Special Ledger still working, but it’s possible to move the data into the universal journal. Special Ledgers are part of the compatibility scope. Keep in mind the end of maintenance for special solutions. Available in the Note 2269324.

No, it does not work.

Data and process harmonization can be integrated into a Selective Data Transition project and approach. For example, a harmonization on master data and transactional data is possible (e.g. customer, vendors, or chart of accounts). 

Such a data cleanup is not required before a selective migration. In certain cases, however, it makes sense to prepare the system or data before the actual Selective Data Transition (SDT) project with preparational steps, especially when for example several systems or formerly separate clients are to be migrated into one single S/4HANA system.

To determine the relevant data for a selective S/4HANA data transition it is possible to delimit the relevant data by either time slices (e.g. fiscal years), organizational units (e.g. company codes), or a combination of the two dimensions. For example, this makes it possible to migrate the last two years of data for a subset of the available company codes in a SDT migration approach.

Data of 3rd party add-ons can technically be migrated by any selective data transfer. However, the availability and integration of this add-on should be checked with the 3rd party software vendor before the selective migration. After the migration, the correct function of the add-on with the migrated data needs to be verified in end to end process testing.

There is no simple right or wrong when it comes to the question as to what data to include or exclude in a Selective Data Transition. The correct choice it depends on very customer specific business requirements and the technical feasibility of delimiting the data correctly and consistently to implement such a selective transition.

Typical considerations when deciding on the amount of historical data include:

• Requirements of end users for day-to-day business processes
• Legal requirements, e.g. for preserving the last x years of finance data. Of course, data can be preserved for auditing purposes directly in S/4HANA. However, the use of a system decommissioning solution may be more optimal from a TCO perspective
• Reporting requirements, especially for year-on-year reporting
• Industry or regional requirements to keep certain data
• Technical constraints or sizing of the future system as well as TCO considerations when running potentially large SAP HANA databases

The complexity of an SDT project increases if the time slice is too short. Recommendation to migrate at least the last complete fiscal year.

Tool support for replatforming is possible, especially during preparation steps such as analysis of the as-is situation, data extraction and preparation. The final data migration should be performed using the standard SAP application and its interfaces.

Yes, this is possible by systems, clients, company codes or groups of company codes.  An evaluation is typically required before the implementation to plan the different waves and to reduce complexity (interfaces, intercompany, double maintenance, master data management, reporting, consolidation,…)

When migrating to S/4HANA selectively it is typically required to carefully consider archives and historical / legacy SAP data. Depending on local legislature and industry requirements, legacy data needs to be kept and made available for several years. For some cases, it may be a valid option to simply keep the legacy SAP system up and running for this time.

However, even with virtualization of SAP servers there may be downsides to this approach:

• No selective data destruction is possible
• No “legal hold” scenario is possible
• Legacy systems still need to be kept available for several years (or decades) which may be difficult for old systems in terms of cloud provider or hardware maintenance when running on premise

These considerations need to be applied to each and every legacy system, therefore it is recommended especially for system landscapes with several legacy systems to consider a retention management solution.