A SAP S/4HANA® Selective Data Transition goes beyond a standard New Implementation or System Conversion. It includes a host of options, related to the handling of software & data provisioning, requiring additional expert services and tools to accomplish.
The benefits of the Selective Data Transition approach are diverse and often customer specific.
The term “selective” is often used to describe a restrictive migration of current data, including master data, open items, and balances. This is not what the SAP S/4HANA® Selective Data Transition approach is about in terms of methodology, scope, and disruption to the business.
The SAP S/4HANA® Selective Data Transition is an alternative to a System Conversion and New Implementation to move to SAP S/4HANA®. This option is all about combining the benefits of both approaches without their limitations: use the innovations in S/4HANA®, while selectively leveraging / re-using your investment. Selective Data Transition gives you the flexibility to adapt customization, data, and processes in your new SAP S/4HANA® system.
This transition methodology maps your current system's data and processes to a new setup. All relations and interdependencies between the different items stay intact. It also enables a direct further-on processing of partly delivered sales orders migrated from ECC without any cutover effort in SAP S/4HANA®. The complete reporting and lookup functionalities can be used in the new system, and the ECC system will not be needed anymore for daily business.
To provide SAP customers with a reliable and proven migration approach in their migration to SAP S/4HANA®, SAP established an expert group of partners – the SAP S/4HANA® Selective Data Transition Engagement. Formed in 2018, this working group unites the system landscape transformation experts of five companies: cbs, Datavard, Natuvion, SAP, and SNP.
The mission of this working group is to establish and adhere to joint standards, methods, and processes that are co-developed with SAP for a secure, yet flexible migration to SAP S/4HANA®. This alignment of the five companies aims to ensure high quality, reduced risk, shorter time to value, and cost-reduction of moves to SAP S/4HANA®, through effective standardization.
The joint standards mainly focus on three areas:
It is possible to use the Selective Data Transition approach in combination with SAP Activate. The project management stream of the Selective Data Transition Engagement is providing information and best practices around this project management approach.
The project management stream of the SAP S/4HANA® Selective Data Transition Engagement provides best practices, benchmarks, and KPIs for project management of Selective Data Transitions. These are loosely aligned with the SAP Activate Methodology.
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. 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 methodologies such as SCRUM may be advisable. However, while SDT can be embedded in different project methodologies, certain project aspects are centered around test cycles which are either sequential or overlapping implementation tests following 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. 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 performance tuning a SDT, or using additional services such as Near-Zero-Downtime-Approach (NZDT).
A selective data transfer from SAP S/4HANA® to SAP S/4HANA® basically works and 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 suits for the SAP S/4HANA® On-Premise. In principle, the Selective Data Transition also supports a migration to the Private Cloud. The solution must follow the SAP Cloud roadmap and strategy and can therefore only be implemented in coordination with SAP. 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. A Selective Data Transition into the 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 “green field” approach and “brown field” approach. To give an idea, this is an incomplete list of things to be considered when comparing the overall costs and efforts in comparison to a “green field” and “brown field” approach:
· With SDT, a smaller HANA DB size is possible which means a possible reduction of hardware costs, software licenses, 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 Green Field, legacy SAP system retirement (decommissioning) should be considered.
· With SDT, but also with green field, it is possible to implement a phased approach of data migration, e.g. region by region.
· 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 Green Field, it is possible to include data cleansing and exclude “rubbish” data
In a New Implementation, e.g. using the Green Field 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 “brown field” and “green field” 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 from ECC into a new S/4HANA® system. 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 possible no need to activate it before. Could be activated before together with new G/L and the ledger solution.
New G/L does not need to be active before moving to SAP S/4HANA.
In standard scenarios, i.e. the System Conversion, no new G/L functionalities can be introduced e.g. new parallel ledgers, document split. Depending on choice of implementation partner and tooling, the NewGL can be implemented in the context of the SDT.
Standard and moving average price could be used as before, no need for a change. Additional ML functionality can be implemented at a later state.
It is necessary to use Business Partners instead of customers and vendors 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.
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.
“Old” 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 addons 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 addon 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
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. In fact, it is a big advantage of the Selective Data Transition (SDT) approach to enable and facilitate roll out projects which migrate a company and its data to S/4HANA® in several waves. 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.