Skip to Content
Personal Insights

How do you Migrate to SAP S/4HANA

Latest updates:


All roads lead to SAP S/4HANA

“It’s no longer a question of whether to migrate but rather when to migrate to SAP S/4HANA”

In this blog post, I will focus on how to migrate to a new SAP S/4HANA system, independent of the source environment. I’ll also talk about SAP Best Practices and tools that you can use out of the box – at no cost which is NEW.

When it comes to SAP S/4HANA, there are a lot of options on how to get there. We nailed it down to three so called transition scenarios. Depending on the deployment model (Cloud (SaaS), HEC (IaaS) or On-premise) and maturity level (S/4HANA Finance or full S/4HANA Enterprise Management), the path to a digital future looks more like a labyrinth than a straight line. This is the case, because you may have a lot of requirements to carry over and don’t want to digest too many changes at a time. However, you also might be trapped with too many corridors that you want to try out before you even realize that it means changes to your custom coding as well as changes in how your system works today.

But let’s back up a little bit. I mentioned SAP’s three transition scenarios for SAP S/4HANA:



  • Scenario 1: New Implementation
    This is a new implementation of SAP S/4HANA (green field): customers who are migrating from a non-SAP legacy system or from an SAP ERP system and implementing a fresh system that requires an initial data load. In this scenario, the SAP S/4HANA system is implemented, and master and transactional data are migrated from the legacy system, thus standard data migration tools and content has to be used.
  • Scenario 2: System Conversion
    This is a complete conversion of an existing SAP Business Suite system to SAP S/4HANA (lift & shift): customers who want to change their current SAP ERP system to SAP S/4HANA. This scenario is technically based on Software Update Manager (SUM) with Database Migration Option (DMO) in case the customer is not yet on SAP HANA as the underlying database.
  • Scenario 3: Landscape Transformation
    This is a consolidation of current regional SAP systems into one global SAP S/4HANA system or a split out of different parts of a system: customers who want to consolidate their landscape or carve out selected entities (such as a company code) or processes into a single SAP S/4HANA system.


Coming back to the labyrinth, scenarios 2 and 3 are a lot like that: it looks simple from afar and really great with all the options and possibilities. However, sometimes you simply can’t make your way through it, especially when the labyrinth is really tricky due to the uber-customized old environment that you might be running on and your non-committal to change.

I guess you’re continually reading this because you want to change to a digital company, and you already got the message that SAP S/4HANA is the future and the answer to those issues arising with the digital world. You simply can’t risk your business with standstill on future IT investments, so you actually want the change. And at least somehow, this change will also involve your UI with new user interfaces (aka Fiori). Change that you need because there was actually a lot of room for improvement in the old ERP transaction world… In addition, it will involve changes in your processes as you actually aim for a simplification here, too.

So why not start fresh? Use a green field approach and implement a clean new SAP S/4HANA system! With this approach, you’ll have the opportunity to take the straight route without being trapped in the labyrinth of your old environment. Below are the tools and the SAP Best Practices content, which will help you in your transformation:


Data Migration to SAP S/4HANA in an on-premise or HEC hosted environment:

SAP Data Services is a key element of SAP’s solutions for Enterprise Information Management (EIM). SAP Data Services provides capabilities for data extraction, transformation, and load (ETL), as well as data quality management, and text data processing. The good news is that you can use the ETL capabilities of SAP Data Services for your SAP S/4HANA system without owning a costly SAP Data Services license (for more information continue reading). But you may consider to acquire that additional license (in case you don’t own it already) to perform data cleansing and de-duplicate your data before the load.


More information:
Download Now! Rapid Data Migration to SAP S/4HANA, on-premise edition

Access the content:
SAP Service Marketplace – RDM for S4HANA On Prem

Demo video:
SAP S/4HANA, On-premise Edition: Migrate Your Data – YouTube

How-to guide:
A better way to migrate your SAP data with Rapi… | SCN


Data Migration to SAP S/4HANA offered as a SaaS model Cloud:

For SAP S/4HANA Cloud, SAP offers the built-in S/4HANA Migration Cockpit. This tool is available as part of the built-in Manage Your Solution Fiori application. You can execute data migrations directly out of this application via simple file upload and migrate your non-SAP or SAP legacy data. The data-migration objects are proposed based on the pre-configured business processes that were selected when the system was configured.


More information:
Watch the Demo: Migration to the Cloud | SCN

Demo video:
SAP S/4HANA, Cloud Editions: Migrate Your Data – YouTube

The Data Migration Guys:
Introducing the Data Migration Guys | SCN


While the above mentioned tools, including best practices content, are all available for no money, the best way to start fresh is to begin with clean and trusted data.


What will you take with you from your legacy systems into SAP S/4HANA?

Data Quality – you don’t want to just push your existing data problems into a new system, do you? SAP S/4HANA is the core of your digital enterprise, the postmodern ERP system for the information age. Success depends not just on going live with S/4HANA, but with running a real time enterprise where decisions and actions are based on high quality, dependable data. That is why data quality matters.

SAP Data Services has Data Quality capabilities for profiling, cleansing and de-duplication of data. It can even help you feed the migration templates that are used in the S/4HANA Migration Cockpit. Take the opportunity and try it!

Below is a comparison of the free Data Integration capabilities for ETL (aka basic data migration) or full use of SAP Data Services (aka data migration pro):



Bottom line

This blog post provided an overview on how to migrate to SAP S/4HANA by choosing from 3 transition scenarios, focusing on the New Implementation one. In addition to this, it introduced you to the process of data migration to SAP S/4HANA, on-premise or cloud by using SAP Data Services and SAP’s built in S/4HANA Migration Cockpit.



For more information on data migration to SAP, feel free to check out the Data Migration SCN Community, the new SAP Data Migration book, the new data migration online training, the recorded webinars, and The Data Migration Guys.


Still questions? Below is the link to our Q&A:
The DM Guys Episode 9, OpenSAP, Data Migration to SAP S/4HANA and more…..

You must be Logged on to comment or reply to a post.
  • Dear Frank,


    Appreciate the tons of effort put to dedicate, understand and articulate the content.

    I am a functional consultant and just on the verge of starting my career in SAP S/4 HANA. Confused as of where to start, what to acquire and how to comprehend the HANA "Space". Request your


    Vijay B

  • Hi Frank,


    we are migrating the customer masters data from ecc to hana from sap bods(data service designer), as we downloaded the standard packages from sap market place , when we try to import the ATL files present in package in to BODS system,it asks for password,Could you tell me which password is to be given for the ATL file to import from Rapid data migration package from sap market place. please reach me to <deleted> for private message if needed.




    • Hi Hari,

      There is no password (blank), please just hit enter or click ok. Password should be left blank as also stated in the documentation. Did you download the docu package on the Service Marketplace, too? Also, please check out all the content attached to the associated SAP note.



      • Hi Frank,

        as we are able to execute up to idoc generate step , after there is a DF_DM_UPDATE_LKP, which is doing data transort to MM_MARA.dat

        as we are getting unable to write C:/temp/MM_MARA.dat in system,Please Guide on this



  • Hi Frank,

    We are executing the standard lookup jobs (DM_BPFDM_Lookups) as per the guide RDM_S4H_OP_DS42XV1_Quick_Guide_EN_XX.docx , then we are able to execute successfully the Job_DM_Lookups_Initialise job, and for the Second step the Job_DM_Lookups_FileToApp , it try to fill all 555 lookup tables in the job monitor and gives the error Cannot open file <C:/Migration_S4HANA/Lookup_Log/Log_Job_DM_Lookups_FileToApp_20160715023607.csv>. , as we couldnt find the file mentioned in the downloaded Rds Package, Could you please guide us to overcome the error,



  • Hi Frank,

    A very well written blog. Being part of an organization which it about to go through scenario 2 migration in the near future, i found this blog very helpful.


    Ahmed Nawaz

  • Frank,

             Would you mind me asking how much effort is involved in adding the RDM tool to an existing environment? We are halfway through our implementation of 1511 and have found we need help especially with BP migration. As such we believe your RDM tool will be perfect for our migration needs.

    We have BI.

    We do not have Solman.

    We have ECC 1511 S4Hana

    We have received the following statement from our implementation partner in regards the effort to install RDM

    "Data Services instance (at least 1 maybe more) Similar application to the Business Objects application and therefore similar time to install and configure – say 5 –7 working days."

    They have also said it is mandatory that we install Sol Manager to be able to install RDM. Whilst this does not appear to be the case according to the requirements doc from the marketplace for the new RDM release.

    Can you confirm the time to install and the need or not for Sol Man?


    Ross Goodman

    • Hi Ross,

      SolMan is not required and the installation should be done with all the configuration within a week. To be honest, our intern here does it in one day. But this is a lab environment and does not include testing and resolving authorization issues.

      Please follow the Config Guide, download the SAP note that is available on the RDM to S/4HANA landing page in the SMP and you should be good. Please let me know in case of anymore questions.



  • Hi Frank,

    Thank you for a very well written blog. We have FSCD and FICO modules that we use in our ECC 6 system, we are planning to move to s/4 HANA (HEC). I understand that we can use DS to migrate data from ECC to S/4, can you please help me on below item.

    Is it possible to go for FICO and FSCD greenfield implementation on s/4 HANA (HEC) and migrate all the data that is currently available in ECC (2.5 TB) to s/4 HANA. If yes, can you please share an high level procedure to migrate data from ECC to s/4 HANA structure.

    Thank you in advance.


    • Hi Narender,

      You would actually load the FI data using the Rapid Data Migration approach with DS into HEC deployments as we treat this private cloud option as OP basically. But you won't migrate the data directly into any HANA tables and rather use interfaces. that having said, you would archive as much as possible in the old system, close as much as you can and migrate the master data objects followed by the open items. You should leave your historic data behind as you should be audit proof by not posting closed FI documents (interface load means posting the data).


  • HI Frank,
    Thanks for the blog,

    For new implementations - scenario 1, on premise, we can migrate the master and transactional data, limited to 48+ objects identified for RDM tool.

    However with SAP Data Services 4.2, is it possible to migrate the legacy transactional data from SAP ECC 6.0 to new S/4 HANA system on premise. Please advise. Appreciate your help


    • Hi Swamy,

      RDM is actually content and not a tool. The tool indeed is DS 4.2 and RDM provide you with the pre-built project to be imported into DS. You can use the 48+ objects as is, you could enhance them and you could even build any objects that are not part of the Best Practices standard. And yes, you could directly connect to the SAP ERP source system tables to read the data from there, doing the mapping in the DS tool with the help of our mapping sheets and load the data via the interfaces as given in the RDM content.


      • Hi Frank,

        I think the question here is - is there anything preventing the load of historic data into S/4 HANA using Data Services? i.e. not with SLT, or system conversion?
        In other words, can I load Master Data, Open Items (I am sure you can load these) and historic data (closed documents/GL postings etc.)
        In my mind there should be no such limitation?

        Thanks in advance,

        • Hi Malan,
          You could do things like this in a Landscape Transformation scenario with SAP LT. The migration tools as described in the New Implementation scenario above would post the FI documents again via the interfaces which would be a double posting that your auditors probably won't like...

  • Hi Frank:

    To be more specific, SAP FS-CD(Sub ledger) system requires all open and cleared transactions from ECC 6.0 to be migrated S/4 HANA due to Insurance contract agreements and reversal/reset requirements.
    Please advise whether we can migrate FS-CD data via DS 4.2 using RDS content.
    Thanks in advance.

    • Hi Sengottian,

      Based on your requirement, I'd suggest you to consider the System Conversion approach in this blog that would help you to get all the data into S/4HANA system.


  • Hello Frank,

    I have two questions to you regarding data migration:

    1) Whats the data migration strategy for AS JAVA and Portal systems?
    2) Do we have information on set of interfaces which is supported with 1610 release?

    Thanks in advance for your help.


    • Hi Saddy,

      My blog post is about legacy data migration for new implementations (green field) of SAP S/4HANA. In that case you install a new SAP S/4HANA ABAP system and don't have the need to convert the Java stack (system conversion needs a stack split). You can still run you AS Java and your Portal as is.
      You'll find the list of migration obejcts and the interfaces for the 1610 Rapid Data Migration content under the link below:

      Best regards,

    • The Data Services way is for New Implementations. SAP LT (not SLT Replication Server) for the System Conversion scenario. This is best suited for SAP ERP to S/4HANA OP but there is no pre-defined content yet. Also TDMS doesn't have any pre-delivered content for such a migration and I personally thought it should be used more for test systems rather than productive environments. But it's technically possible. However, both TDMS and SAP LT require additional licenses.

  • Hi Frank,

    Thanks for detail information . I need clarification for migration to S/4 HANA..WE are using SAP ECC but are keen to move only FICO to S/4 HANA platform and other logistics modules in ECC i.e. oracle database .Can we migrate only one module to HANA database and keep other modules on existing database? Kindly suggest

    Manoj Pillai

    • Hi Manoj,

      You could. First of all, the System Conversion does it always all at once. As it includes a DB migration (in case Oracle to HANA DB) you cannot pick and choose. But if you start with a new greenfield S/4HANA that you just want to use for FI, that's possible. However, maybe you don't want to migrate everything with data migration (as legacy data migration usually means you don't migrate history and try to archive as much as possible) but are looking to use the power of SAP S/4HANA for Finance. Then there is the use case of running a so called Central Finance system (which replicates data from your still existing ERP FI module. Also, SAP offers S/4HANA Finance. You could do a System Conversion to this. Then everything will be running on HANA DB (also Logistics) but only Finance will use the new data model (S/4HANA). The Logistics part would be the same as before just on a different DB. Then you have a Suite on HANA system with Finance in S/4 (what we called sFIN or Simple Finance before).


  • Hi Frank,

    Thank you for this detailed explanation and the 'data migration episodes'.

    I'm a migration consultant; majorly using LSMW until now!
    I'm excited to learn new tools offered by SAP in context of data migration.

    Can you please help me to clear below doubts related to data migration?

    1. New implementation (Greenfield) vs System conversion

    If legacy system is on non-HANA db, only then the system conversion method can be used.

    if legacy system is on HANA db (and on ECC 6.0), greenfield approach can be used (by redesigning and optimizing the business processes) to migrate to S/4 HANA.

    2. Is 'SAP data migration cockpit (on-premise)' (mentioned in DATA migration guys Episode 10) covered in your Data migration book?
    If not, can you please share some documents related to the same?

    3. There are 48 objects (now 50) in-scope of migration using RDM. What about other objects? Can we create tools for remaining objects using Data services?

    Thank you in advance for your feedback.

    P.S: I'll looking forward to read and explore new data migration techniques using this book!

    • Hi Gaurav,

      Thanks for getting in touch!
      Let me answer your questions right away:

      1) Greenfield vs. Conversion
      In general, Greenfield (New Implementation) and System Conversion can both be used in the mentioned cases. It does not matter whether the source SAP ERP system is on HANA DB yet or not. There are other things to consider and the decision should also be business driven.
      Is the source system ECC 6.0 running on Unicode with minimal custom code only? Then most likely a System Conversion is possible. In case the system is a lower release or non-Unicode, you will need an additional upgrade step. For ECC 6.0 (any Enhancement Package) on Unicode we have a one-step approach - independent of the DB (meaning we can do the DB migration on the fly).
      New Implementation always can be done. Doesn't matter whether Unicode, HANA or even SAP at all - everyone can implement Greenfield. Then the way to do it is a proper data migration.
      In case the customer wants to go back to standard and/or has an older, highly customized system, then a Greenfield approach should be considered. Also a proper data cleansing exercise can only be done in case you implement fresh. Otherwise, the data will be converted into the new S/4HANA structures 1:1.

      2) Resources for S/4HANA Migration Cockpit
      Unfortunately, we are just mentioning the Migration Cockpit in the "Data Migration with SAP" book. The book mostly covers Rapid Data Migration with SAP Data Services and LSMW, but it's a great resource for these two tools! Reason is that we just started with the Migration Cockpit development when we had the final delivery date for the book.
      The good news is that we're working on a new book called "Migration to SAP S/4HANA"! However, this hasn't been published yet.

      3) Enhancements of the RDM content
      You're right, the amount of pre-built Rapid Data Migration (RDM) objects for SAP Data Services (DS) might not be enough for your specific project. Sometimes you need field or table enhancements, sometimes complete own custom objects. The good thing is that you can enhance the Data Service content as much as you want. RDM is just a starting point - Best Practices to jump start your data migration. We even provide an Enhancement Guide if you download the package. In a typical project you won't build that content from scratch but copy (better to say it in DS language: "replicate") an existing DS job from the delivered DS project and do the changes according to the Enhancement Guide.

      Hope this helps!

      Best regards,

  • Hi Frank,


    I am a big fan and user of BPDMs/AIO/BPFDMs/RDS pacakage. I have few questions with s4 package though.


    Do you have a road map for S4 RDS Data migration (Data services- on premise new implementation) ? I know current available version is on patch 2 which released with 1610. But do you have a roadmap of how business partner migration will be? Currently we are using a BAPI to migrate and as far as i know RFCs are not known for their performance.

    Do you know if the BP migration will be rewritten to an idoc in the near future ?

    Bp migration content doesn't really address all the validations as the previous versions, is it in the roadmap to develop all the validation ?




    • Hi Krishna,

      First of all, thank you so much for supporting our Rapid Data Migration solution.

      I'd like to clarify some questions from your comments in order to better understand your inquires.

      1. What is the current BAPI you are using for the BP object?
      2. What are the validations you think they are not addressed?




        1. What is the current BAPI you are using for the BP object?
          • RFC_CVI_EI_INBOUND_MAIN, this what BPDM jobs are using.
        2. What are the validations you think they are not addressed?
          1. if you look at the job Job_DM_BusinessPartner_RFC in latest bpdm package. Its basically a wrapper of BP/Customer/Vendor/Contact Master. But if you take look at workflow that are specific to supplier or a customer – like company code data or Purchasing data of vendor and compare it with previous job like – Job_DM_Vendor_IDOC, i have osberved lot of basic lookup validation are missing.Please find the details in screen shot .


        • Hi Krishna,

          Thanks a lot for using the Rapid data migration solution, we are development team of the solution, below are answers for your questions:

          1. The current version of the solution is S/4 HANA 1610 OP, we also have new release for S/4 HANA 1709 OP in the Q3 of this year.
          2. For business partner object, we use the RFC RFC_CVI_EI_INBOUND_MAIN to load data to S/4 HANA, there is no iDoc available for Business Partner in S/4 HANA, RFC is the only way to load data to S/4 HANA at the moment.
          3. Job_DM_Vendor_IDOC was one object in our rapid data migration to SAP ERP solution, the object Job_DM_Vendor_IDOC and Job_DM_Vendor_IDOC IDOC are not available any more in Rapid data migration S/4 HANA OP solution, they have been replaced by Job_DM_BusinessPartner_BAPI.
          4. We will keep enhancing the object Business Partner as well as the whole solution based on the customer requirement/feedback.
          5. Regarding the question ‘Bp migration content doesn’t really address all the validations as the previous versions, is it in the roadmap to develop all the validation’, usually we develop the validation rule based on the API interface definition, Business partner uses RFC but Vendor uses iDoc, this is why they have different numbers of validation rule, let me know the fields if you think we are missing validation rule in the business Partner object, we can enhance the DS job.



          • Thanks for the update.Here is observation and suggestions:

            Observation - 

            RFC_CVI_EI_INBOUND_MAIN. has structures for LFA1-LFB1-LFM1-WY3T and KNA1-KNB1-KNVV-KNVP and KNVK etc. So basically its a huge wrapper of cremas&debmas with Business partner BUPA create function module. (I might be over simplifying, just speaking in metadata terms.)

            Suggestion - 

            I think we can take the exisiting ERP solutions Vendor_IDOC and Customer_IDOC jobs and apply all the validation that we have in companycode/purchasing views etc.. in Business_Partner_RFC job.  I think we can resuse the exisitng ERP validation in below data flows -

            for Vendor ---






            For Customer ---




            And so on !!

            Migration Services - 


            I think migration services is the most under appreciated tool in the whole package. But if we get all these validations in place, we can leverage this tool to the most. I have been using migration services from its early version.

            Suggestions --


            Adding a source system identifier to the lookup tables help us use the package for multiple source systems with a single point maintenance. Today we have to create different lookup schema for different sources to achieve lookup maintenance for multiple source migration project.

            Apologies for a long wish list.





            If you would like to discuss further feel free to reach me

  • Hi Frank,

    We're going to implement S/4HANA on-premise (1610).

    Supposed that we don't implement "SAP Best Practices for S/4HANA 1610", do we still have S/4HANA Migration cockpit for data loading tool?



  • Hi Monis,

    The SAP S/4HANA Migration Cockpit will still be there (t-code LTMC), for the documentation please refer to the Best Practices Scope Item BH5. But it's not necessary to activate any Best Practices content. Did you consider using Rapid Data Migration for your 1610 migration? That might be the better option for your release as the content for LTMC is still pretty basic in the On-premise version. More coming by the end of the year!


  • Hi Frank,


    We are trying to use "Migrate your Data" fiori application for loading data to cloud and facing multiple errors. Can you point us to the documentation which talks about configuration steps.





      Hi Raghav,

      Sorry to hear that. Below a list of documentation sources. Hope this helps – FRANK.


      Overview and step-by-step Migration Cockpit (Test Script BH5)

      1. Link
      2. Go to App group: DATA MANAGEMENT under SOLUTION SCOPE

      Migration Cockpit Tool documentation

      1. Link
      2. Choose the cloud edition and go to PRODUCT ASSISTANCE.
      3. Choose your language

      Object Documentation in the tool itself

      1. Click on Show when in the Object Overview
      2. Click on Show when working on a specific object
  • Hi Frank,

    I intend to Migrate SAP Procurement solution from several ECC 6.0 system to single S4 HANA system by using SAP LT Server. 


    1. I want to go step by step for this S4 HANA migration, so now i am only planning to migrate my Procurement solution to S4
    2. My existing other solutions will still remain in ECC systems like PM , SD, HCM
    3. So in a nut shell i want to use both the systems now , S4 as well as ECC

    My Questions are :

    1. To ensure i have right finance data in my S4 HANA system from my ECC systems to carry out procurement activities like PR , PO , contract creation, can i use SAP LT server for finance data replication ? like GL , Cost centre, profit center , wbs etc? Is there a list of objects which can be replicated from ECC to S4 via SAP LT server from finance perspective?
    2. Can SAP LT server also help me to replicate data from SAP S4 HANA to ECC system? for e.g. once a contract is created in S4 HANA system i want to replicate/Distribute the contract to ECC systems. can SAP LT server help me in replicating data to and fro between SAP S4 and ECC systems?
    3. If in case i use MDG system as a central master data system for vendor , material and service master data, can SAP LT server help me in replicating data from ECC systems to S4 HANA system?

    Can you please help me with your thoughts?



    Ashish Shah

    • Hi Ashish,

      Frank asked me to share a few thoughts on this. It is an interesting idea however this is not a standard scenario for SAP LT:

      1. As part of a Project you could use SAP LT Technologies in order to migrate the data from your ECC 6.0 systems to S/4HANA. This would be the first step in setting up a central S/4HANA System for your scenario with the respective data from the ECC6 system. However as this is not a preconfigured and released scenario, you would have to discuss with SAP's DM&LT Services team to review the feasibility and complextiy of such a project. More Details can be found on the SAP Support Portal
      2. With regards to an ongoing continous replication into an S/4HANA System during productive usage, SAP LT Server is currently only released with a preconfigured scenario for implementation of SAP S/4HANA as Central Finance System. Details on this use case can be found in SAP Note 2154420 . This is a one-directional replication of financial docuemnts from ERP Systems to SAP S/4HANA. I don't think that SAP LT Server is the right technology for your purpose and may want to review if traditional ALE / IDOC Scenarios could support the scenario
      3. If you already use a central MDG , I recommend you continue to use this as a leading system for all material / product & customer / supplier / business partner data and do not look in parallel at distributing these master data objects with SAP LT. Otherwise you might run into sequencing issues and may lose the benefit of having MDG as a leading system for these data objects

      Therefore as a conclusion, i suggest to only look at SAP LT technologies for the initial setup of your S/4HANA System in order to manage the complex data migration by utilizing SAP's DM&LT Services. Beyond this, i recommend to use other technologies to manage the integration in order to have a operate this scenario post GoLive.

      Best Regards, Stefan

  • Hi Frank Densborn,Stefan Goebel

    Thank you very much for writing this post and letting us know on different option available for Migration.

    I still have Few questions which is little different, hence let me explain my understanding and then i would ask my query.

    After reading multiple blogs about SAP LT2.0(Integrated part of Solution manager) which is your scenario-3 and SAP LT replication server(Integrated into SAP HANA), these are two different solution provided by SAP and has no interlink between each other.

    Can you please confirm if my understanding was right? if yes, request you to provide me solution for query:

    If I am using SAP LT2.0(Part of Solution Manager) , how can i use this to Merge multiple source system( SAP and NON-SAP, HANA and NON-HANA) to perform Data Migration to SAP HANA and\or S/4.

    I was going through documentation of SAP LT2.0(Part of Solution Manager) and saw that offering given was (  and

    1-Leverage, Sell, Buy, and Restructure

    2-Unify and Transform Data

    3-Consolidate and Reduce IT Cost

    Now when i go through details of each offering, i could not see them as Migration solution what i understood that its only playing with certain kind of data for example Vendor , material and so on but its not going to let me migrate all data from one (SAP, Non-SAP, HANA, Non-Hana) and not touching all the objects as this solution is limited to specific solution embed in each category.

    hence what i understood that this tool is not a complete solution for Migration and mostly used for high level of selling\purchasing\Carving out some part of business which can not be considered as Full Migration.

    Also what i understand that SAP LT is installed on top on Production system (SAP ECC or SAP HANA) that means there is no migration hence source and target are same here.

    Can you please help me with understanding that how can i promote this SAP LT2.0 as part of Migration solution ?


    Shiva Sahu



      Hi Siva,

      It is correct that those are two different products:

      • SAP Landscape Transformation 2.0
        • Purpose: Provision of predefined scenarios to realize IT and business driven changes in SAP Systems
        • Link to Product Roadmap
      • SAP Landscape Transformation Replication Server:

      At the same time however historically these products share common roots and for instance are both utilizing the DMIS Addon. Therfore you may for instance find many SAP notes that are applicable for both solutions.

      Within the area Consolidate and Reduce IT cost of SAP LT you can find scenarios to merge for instance multiple SAP Systems into one Single multi-client SAP System. Each scenario described has been designed as an End to End scenario covering all related data migration or conversion aspects and can be adjusted based on the individual system to include custom tables / objects. As described on Slide 25 of the product roadmap, there is also a solution for Object-Based Migration which can enable you to migrate for instance vendor, material or other objects from one SAP System to another SAP System including histirical data. this however is currently only provided as a project solution and requires the support of SAP's DM&LT. Also as part of a full syste merge into a single client, you will need to request the DM&LT team for further support. You can contact this group under for furhter information.

      When migrating data with SAP LT2.0, you will need to install the DMIS Addon on Source and target system (including production system prior to the go live / rehearsal) and provide a separate system for operating the SAP LT software. In most cases this will be SAP Solution Manager, However under certain considerations that could also be a separate instance similar to the SAP LT Replication Server.

      In addition there is a new solution provided for migrating data to SAP S/4HANA: The SAP S/4HANA Migration Cockpit. This is highlighed in this blog post Getting started with the S/4Hana Migration Cockpit (OnPremise) and enables you to migrate data based on a object level. It is included in SAP S/4HANA On Premise as per release 1610. If you are looking for a simplistic tool to migrate master data and open items (no historical data) to SAP S/4HANA, this is worth looking at.

      I hope that clarifies your question.

      Best Regards, Stefan


  • Dear  Frank DensbornStefan Goebel,

    Client is on legacy ERP (Solomon) system for procurement and accounting management with data extracted from different legacy systems consolidated into Hyperion for reporting needs. Looking for S/4 HANA transformation right now. Also looking at the option of integrating them with S4H or to replace them (legacy systems – sales, finance, hr, lease, AP etc). Presently S/4H on-premise Finance, Logistics, Analytics and cloud solutions (Ariba, SF) are considered. In terms of transition – please suggest the best approach with resp. to data migration procedure to be adopted, complexities involved, recommendations for transition path to S4H. As there are SAP DS and SLT tools in place, pls guide the approach to be adoped for the above.

    Kind Regards, Amar

    • Hi Amar,

      To get to the right approach you'll need to consider so many more things. The purpose of this blog post is to get an overview but you might want to use more resources to get to YOUR best approach as every customer is different. A good reference for the topic is the below:

      This book can be pre-ordered already and is meant to be a comprehensive guide serving as a reference including all resources that you need.

      Hope this helps,

  • HI all

    I have two queries about LTMC & LTMON,

    1. Is not an issue but yes ver annoying, If I create a project in LTMC in Spanish, in LTMON the project is not listed (and viceversa)
    2. I have an issue when I tried to modify and object using LTMON (I'm working with the best practice BH4), the activity windows has no activities and I need to modify the standard object to add International number, there is a note or a missing step that I should execute previous to change an object?

    Thanks in advance for your help




      Hi Diego,


      I tried to reproduce issue of 1) in our internal system, but here it works properly. Internal system is on 1610 FPS2. As I cannot reproduce it internally it's hard to tell if there is an language installation issue in your system or whether the issue is solved with current version

      According 2) looks like texts are not loaded properly. Have you tried to logon with language English to see if it's working properly. If we should help you here, I would ask you to open a ticket on component CA-LT-MC with logon data to your system, so that colleagues can investigate.



      • HI Johen,


        Yes I tried in EN and ES, but we are working right now on a Cloud Appliance Library (and had some customizing issues in other areas), I'll wait until our DEV environment will be ready and check again.

        Another question, there is a possibility to add new object, i.e. Profit Center Groups? or for this we must use a traditional approach like LSMW?

        Thanks in advance.





        • Hi Diego,

          Starting with 1610 FPS2 you can create any custom object with LTMOM as long as there is an API (function module).



  • Iam SAP SD functional and could not relate to databases and other techincal stuff. My manager has put me on a HANA project for a customer and iam suppose to read on my own on HANA and come out with changes to be done/tested for SAP SD module. Looking for advice on what to read and where and in what sequence ?

    Below is my knowledge level

    1) for me SAP has oracle database or DB2 where data is stored . Moving to HANA means replacing Oracle with HANA database. So SAP system will remain the same. DATA like sales orders, Purchase orders etc will remain in same SAP system. So where is the concept of DATA migration coming into picture ?For me, migration simply means moving it from legacy to SAP system where we are doing fresh SAP ECC 6.0 implementation

    2) In ECC 6.0 we have Dev/quality and production SAP boxes. Do we need to have separate boxes created and Install SAP S/4 Hana on it and then move data from Ecc 6 boxes to new SAP S/4 hana Boxes ?

    3) In our org we do not have enough knowledge on HANA. there is so much info available on SAP portals like, and it gets confusing

    4) request you to pls advice what articles to read and in what sequence and if you could provide the links including links for what an SAP SD consultant needs to check, test or configure after ECC6 is upgraded to HANA.

    5) why an SD consultant needs to test and do additonal configuration in new HANA system. Is there any article or book which explains things with examples

    • Hi Sachin,

      HANA is a big name and used for multiple but very different products at SAP. This blog is about a New Implementation of SAP's latest Business Suite called SAP S/4HANA. Although S/4HANA is running on HANA DB, your case is different and I cannot answer all your questions in detail as I'm not the expert on HANA DB topics.

      Let me give it a try:

      1) In your case this is simply ERP running on HANA DB (aka "Suite on HANA": SoH) and therefore NOT a legacy data migration but a DB migration. Basically, similar to Migrating from DB2 to Oracle DB or vice versa. Technically it's an homogenous OS/DB migration and tools being used are Software Update Manager (SUM) and Database Migration Option (DMO). It's "just" exchanging the DB. In SAP S/4HANA we call this a conversion.

      2) Now you talk about SAP S/4HANA, so I'm a little confused... In any case, SoH or S/4HANA have the same setup with DEV, QAS and PROD than ECC 6.0 or R/3.

      3) I agree. Best sources are SAP Blogs (former SCN), openSAP courses or SAP press books.
      Two links for Suite on HANA (please search for S/4HANA cookbook if you're indeed going to SAP S/4HANA):
      Suite on HANA Cookook
      SAP Business Suite powered by SAP HANA OpenSAP course

      4) For functional consultants there is no big change unless you implement any of the new features that are available with your higher version/EhP of ECC 6.0. However, along with the technical changes you'll check custom coding in your area for the below things:
      - Database specific coding (e.g. Oracle specific SQL won't run on HANA)
      - Database indexes and database hints (HANA is a column based DB)
      - Custom cluster tables (tables must be de-clustered)
      5) I don't think there is a specific book for what you're looking for. However, I would start with the SAP HANA cookbook and if you're really into migrating/converting to SAP S/4HANA, then the book below would be helpful:

      Best regards,


  • Frank -

    Where does SUM DMO stop and the Migration Cockpit begin? In other words, is there one instance where SUM DMO would be a better choice? (POC?) As a Basis guy, I have to ask. If I have a client that wants to do a POC on HEC and it's a full os/db migration of their old ECC system to S/4 on HEC....and I have an established network connection to the new S/4 HEC server, can't I just use SUM DMO to execute this in one fell swoop from their existing system (non-Hana) to HEC? It's understood that this idea leaves out any data cleansing. I'm just wondering what shape the new environment might be in for a POC. Thanks for your patience with my far reaching questions.



    Tony Price

    • Hi Tony,

      I like your question but unfortunately, it's too much to explain here in my reply. For example, we have an entire chapter for this "when to use what" question in the book below:

      In general, it depends. Do you want to start fresh or have a very old SAP system? Go with New Implementation (Migration Cockpit). If you need all the history and are close to SAP standard meaning you don't have many custom development, check out the Simplification List to see whether you can do a System Conversion (DMO).

      Hope this helps,

  • Hi Frank,

    Given Scenario 1: New Implementation with migration form SAP ERP => SAP S/4HANA using the rapid deployment pack based on SAP Data Services.

    Question: What is the best way to extract data from SAP ERP?

    All blogs and example videos start by loading data from excel files.

    In the case of SAP ERP I would expect extracting data id done by means of for example CDS Views or predefined SQL statements (using ODBC ?).

    Writing a ABAP programm to extract for example 500tousand material master records and providing those in a excel file with a tab for every detail screen seems not suitable for me. (What is the size limit for excel??)

    => Which way for extracting data from SAP ERP do You propose and (how) does SAP support this?

    Thank You for Your help!






    • Hi Reiner,

      When you do a New Implementation, you can use SAP Data Services with RDM to connect to the SAP ERP source DB via ODBC. This is a direct connection, you'll instantly get all the metadata and the mapping (which is pretty similar as most fields have the same names and structures similar name (table to API mapping)) will be done in the Data Services Designer. ODBC is best because it's quick.


  • Hallo Frank,

    Given Scenario 1: New Implementation of S4/HANA on premise with migration from SAP ECC using the rapid deployment pack

    => Is Customer-Vendor-Integration to be done in the existing SAP ECC before migration, i.e. must BP be set up in the old system


    is this done in RDM during migration.

    My understanding is that both is possible. The first approach should have the advantage that the integartion effort is already done before migration therefore reducing time and risk of the migration project.

    => What is the best approach?


    Thank You for Your help.







  • Hi Reiner,

    The RDM for 1610 is using the BP API, meaning that it would be easier to migrate from BP to BP as the amount of mapping that you have to do is limited. If you didn't do the conversion for CVI before, you have to manually map from the e.g. KNA1 customer fields to the BP general data. We're actually adding back the IDocs (for customer CREMAS) for the 1709 release of the RDM as an alternative option. So I think you should go with your first approach.

    However, if you're using the Migration Cockpit for customer and supplier, you can fill according the "old" structure and the tool will take care that the data gets into the correct BP tables. I hope this helps!



  • Hello Frank!

    first of all I want to thank you for this blog and all your answers. Its very helpful. However, I still have some questions:

    Scenario 1: New Implementation of S4/HANA on premise with migration from SAP ECC. As you mentioned above, SAP Data Services can be used to migrate SAP ECC master data and open items into S/4HANA. Here are my questions:

    1. What is the recommended solution to migrate historic data from SAP ECC to S/4HANA? Our client wants to use the embedded analytical capabilities of S/4HANA for some processes. These processes require to some extend that we have historic data in the S/4HANA system (e.g. the last 2 until 3 years).
    2. Can we use SAP Data Integrator (as you described above) to load data from a source table directly into S/4HANA database tables without using the S/4HANA APIs (RFCs, BAPIs, etc.)? The source table would be located in an SAP ECC or in non SAP databases.
    3. As you mentioned above, the SAP Data Integrator does support data mapping but no data quality capabilities. Can you please elobrate a bit on what you mean by data mapping, i.e. does the SAP Data Integrator support data transformations and structure transformations, e.g. like it is possible with XSLT?

    Best regards,


    • Hi Frank 🙂

      1. Typically, you want to close as much as possible before the go-live and just migrate open transactional data like FI documents. Historical data cannot be loaded via the same APIs as the documents would be posted (again) leading to inconsistency and audit issues. That is why we don't migrate historical transactional data. To answer your question, these data records should be loaded to some sort of a data warehouse that is then integrated with the SAP S/4HANA system.
      2. SAP Data Services as product can do direct table loads. However, the pre-built RDM data migration content does always use APIs for data consistencies. Especially in SAP S/4HANA with the new table structures, a new system could get messed up pretty easily when the load is not performed correctly. RDM always ensures that all the application checks are being performed and values are being mapped to the correct S/4HANA ones.
      3. There is just one product called SAP Data Services. However, with the Data Integrator license that is free with load to HANA, all the Data Quality (DQ, data cleansing) features are grayed out. The tool is the same. And DI is a full blown ETL tool, all but the DQ transformations are available. This restriction does not restrict the structures or input/output schemes.

      I hope this helps.


    • The restriction is that it does not include the DQ features of SAP Data Services. That means the DQ transforms are greyed out and not usable. Other than that there is no restriction regarding size or duration at all.

  • Hi Frank, I was wondering if you could help point me in the right direction. We are going through our first instance of data migration for a greenfield S/4 project and encountered the following. I am probably missing something simple here as it cannot be that we have to revise the length of the source structures based on the target for every object? Please let me know what you think?

    • The MOC has its own Best Practice upload templates that are to be supplied to clients (data team) to populate and upload to S/4 – the count on 1609 is 33 templates (most available for on premise use).  Note this issue still exists on the few fields I have checked on 1710.


    • These templates contain field length and field types and we have discovered that a number of the fields on these templates have listed a field length of 80.  In several cases, this field length is incorrect and will fail at point of upload.  The upload templates do not take their metadata directly from the S/4 table definition.


    • Examples of the issue include:
      • Bank Master – Bank Key (15) set to 80
      • Activity Types – Cost Center (10) and Activity Type (6) set to 80
      • Activity Prices – Controlling Area (4) and Company Code (4), Planned Price (4), Currency Key (20) set to 80
      • Materials – Material Number (40) set to 80

    Hi Ivan,

    This is correct, we set the data length 80 for some columns in the template because these fields are required the value mapping, you can give legacy company code like ‘my company abcd’ in the template and then you have to map it to target company code like ‘1010’ in the step ‘Convert Values’ of migration cockpit.

    If you enter the invalid value in the template for these fields, they will not pass the validation step of Migration Cockpit.

    Miller Li
    SAP S/4HANA Data Migration Content development
    SAP China

    • No, SAP SLT Replication Server is not used for migration but for ongoing replication of data in tables (e.g. for HANA). In data migration scenarios, we're not migrating tables but always complete business objects to avoid inconsistencies, especially when coming from non-SAP.

      • Hi Frank,

        Thanks for your reply ,

        Which is the bet approach to be used while migrating data ( Modules like FICO, SD, MM, IBP, PP, PM, QM, SM and GTS ) from Non SAP to S/4 HANA on-premise.

        Rapid data migration or Migration Cockpit ?

        • My persponal opinion is that as of today, Rapid Data Migration is the more complete approach. For a big project, I would use that as the leading tool. It will also help with the extraction from the non-SAP source. But we're getting there with the Migration Cockpit which could be used as an addition to even complement Data Services.

  • Hi Frank.

    Thank you for the blog.

    I have been testing migration cockpit in our development environment, but it seems like the vendor data I have migrated so far, is visible both in our development and actual environment. What could be the reason? Could it be because of wrong transfer ID? How can I limit my migration to certain environments?

  • Hi Frank,


    I have heard that in S/4 HANA there is a limited SAP Data Services functionality called DS/DI, which is SAP DS without the Data Quality functionalities.


    If this is right, I would like to use it for data migration using the RDS. I am already familiar with RDS that provides me prepared DS jobs for most objects.


    My customer has no SAP Data Services licences, but if there is this DS/DI then he does not have to adquire this and we could use it (instead of Data Migration Cockpit).


    Is this right?

    Thanks for your quick answer



  • Hi Frank,

    We have a customer that is implementing S/4 HANA on HEC. They don't want to use SAP DS / RDM as the migration tool. SAP is the implementation partner and are loading data via DM Cockpit, but the customer is responsible for the Extract and Transform and providing the data in the correct format.

    I know that the latest DM Cockpit has a feature to load from a staging area (which I assume is the HANA DB) from where it will read its data and load. My question is the following:

    Do you think it is a good idea to look into S/4 HANA SDI to use as the ET(L) tool to get data transformed and ready for DM Cockpit? If not - what is your recommendation?

    Thanks in advance


    • Hi Malan,

      It is correct that the staging tables are created on HANA but you'll need a separate schema. You certainly could use the HANA SDI to write into these tables. However, the tables always will be generated by the Migration Cockpit. Alternatively, you could use DS (without RDM) or ADP (as part of SAP Data Hub). The staging concept should be the right approach for you. Hope this helps.


  • Hi Frank,

    Since there is some time between this post and the present moment (2018/11), I’ve been searching for updates to this info and I haven’t found any mention to RDM to S4HANA in latest SAP roadmaps, just Migration Cockpit at simplification list. Is SAP still recomending the use of RDM to execute data migration at S4HANA projects?


    Another thing I haven’t found is a comparison between those two methods (RDM and MC+MOM) on execution performance. Do you have this comparison or know where can I find it?

    • Hi Mauricio,

      I think the two recent resources below would be a good starting point:

      My colleague Chuck, who is now the owner of the RDM solution will comment on the roadmap.

      In general, the performance depends on the API. Most of the called APIs between MC and RDM are the same (BAPIs) but for MC they're called locally in the system while for RDM they're called remotely (RFC) from SAP DS. On the other hand, RDM with DS also does the E and the T of the ETL process, something you have to consider with the MC as well. How would you fill the template files or the staging tables? For MC you can clearly say that using the staging over the template file approach is a clear performance advantage.

      Hope this helps,


      • Hi Mauricio,

        Thank you, Frank.

        Regarding the roadmap question, we plan to update our Rapid Data Migration solution with every major release, once a year. The latest one is based on S/4HANA On-Premise 1809. You can find the package in the link below.



  • Hi Frank,

    We need to migrate data using files from business fashion non-SAP legacy system, have something available on SAP S/ 4HANA Migration Cockpit – 1909?

    The example of the solution incorporated in the migration cockpit directly from the SAP AFS sap to SAP S/ 4HANA (1909) Fashion and Vertical Business system with grid objects, article (retail material). If not available? What is the recommendation? Create objects using LTMOM using Migration Cockpit?