How to Successfully Migrate from SAP EWM 9.5 to S/4HANA EWM

Many of our clients are currently considering how they'll run their decentralized SAP EWM system in the future. If your system is already running on SAP EWM on S/4HANA, this article is only partially relevant to you. However, you should still consider a move to RISE with SAP - the migration to the Private Cloud can come with advantages regarding the license costs you'll need to pay to run your system.

If your SAP EWM system is still running on SCM or stand-alone on SAP NetWeaver, you should soon think about the future system architecture of your SAP EWM installation. SAP EWM 9.5 is the last release for SCM-EWM. Future advance developments and corrections will only be provided for the newer architecture, SAP EWM on S/4HANA.

SAP EWM on S/4HANA means that EWM is running as the only actively used component on a dedicated, technically fully functional (but not fully customized) SAP S/4HANA system. The central SAP ERP or SAP S/4HANA which you run as your ERP instance remains untouched. Thus, the previous stand-alone SAP EWM is replaced by a new system on SAP S/4HANA architecture – a migration from the “old” SAP EWM to a “new” SAP EWM.

One remark before we start: If you are still running a version older than SAP EWM 9.5, you should consider a system upgrade before the migration, as many important corrections are only available with SAP EWM 9.5. The migration is still possible with older versions > 9.x, although such installations are rarely encountered nowadays.

The first step in your migration project should be to familiarize yourself with the new software stack of your future EWM system. As your future EWM will be based on SAP S/4HANA, it will share the coding line of S/4HANA and follow the release and upgrade cycles of SAP S/4HANA. You should expect changes especially in the basis components of EWM on S/4HANA. To make the familiarization phase easier for you, we'd like to list the most important changes below.

• CIF Interfaces Removed: Core Interface is no longer used for transferring master data between SAP ERP and EWM on S/4HANA. Instead, the standard IDoc types (MATMAS, BATMAS, CREMAS, DEBMAS) are used for master data transfer.
• Customer Vendor Integration (CVI): Due to the transfer of suppliers and customers via CREMAS and DEBMAS interfaces, you must implement the customizing for Customer Vendor Integration (CVI) in SAP EWM.
• Harmonized Material Master: When receiving material master data, EWM on S/4HANA now creates a material master record in SAP EWM, which you can display via the “classical” transaction MM03. The data model from the core (MARA, MARC) is now also used in SAP EWM.
• New Customizing for Decentralized EWM: During your basic EWM customizing, you'll have to explicitly configure your SAP EWM system to run as a decentralized SAP EWM. Running EWM in decentralized mode also means that you must activate the EWM advanced version in the customizing. Furthermore, you must map plants from SAP ERP in a new customizing node on the EWM side.
• Reorganized Customizing Nodes: Certain nodes, like the ERP version control, can now be found in new locations in the customizing tree. Customizing of HU types and packaging material types now also follows the new, harmonized master data model.
• New Settings for Serial Number Profiles: Customizing for warehouse-number dependent serial number profiles has been harmonized. The serial number profile analog to SAP ERP is now used.
• New Settings for QM Integration: As another harmonization, you now have the option to use QM integration via the QM view settings of the material master instead of using quality inspection groups and quality inspection rules.
• Several Technical Changes: Some signatures of standard function modules and methods have changed. In many cases, the party entitled to dispose has now become a mandatory field.

As you most likely noticed while reading the previous paragraph, many of the changes involved in migrating your legacy EWM to EWM on S/4HANA affect the interfaces to the ERP system. However, these are probably not the only interfaces your SAP EWM has to call and serve today. You should create an interface list documenting all interfaces that EWM provides to other systems or that EWM calls in other systems as early as possible. Please note that this also applies to file interfaces and printers.

The interface list will not only provide you with a good overview of the interfaces to be tested and potentially adjusted during the migration, it will also help you identify all the processes currently configured in your system. Furthermore, it provides you with an opportunity to retire obsolete or unused interfaces before the miration, so that you don't have to test them during the migration.

Now it's time for planning. By the end of this step, you should at least have a rough roadmap outlining the first go-live with the new EWM on S/4HANA as well as the overall project timeline. For the overall timeline, the number of warehouse numbers to be migrated is a good baseline. Don't worry - if you're migrating an SAP EWM installation with many locations (clients/warehouse numbers), you can take an iterative approach to planning throughout the project and finalize the exact sequence of warehouse numbers later.

The key is to first establish the timeline for the first site(s); you can then estimate the total project duration by multiplying this by a rough duration estimate for migrating a single warehouse number including all project phases.

You can initially plan the EWM migration as a forward schedule. If you run into time constraints, you can later parallelize the migration of multiple locations if necessary and feasible, provided your resource planning allows it. You should however plan for sufficient IT personnel for the technical migration as well as site representatives for testing and go-live support.

Now we get into the system for the first time! At this early stage, it is not necessary to implement a full three-tier S/4HANA system landscape with development system, quality system and production system.

However, you should try to set up a sandbox environment for SAP S/4HANA EWM early on, so that you can gain experience and familiarize yourself with the new environment. A stand-alone system based on SAP S/4HANA is a great start. One option for faster deployment is to use the SAP Cloud Appliance Library for a quick and pre-configured deployment with a hyperscaler of your choice - or you can install a fresh S/4HANA instance in your local network or in the SAP S/4HANA Private Cloud.

After installing your sandbox, you should familiarize yourself with the new system. The key is to get to know the standard interfaces in S/4HANA EWM. EWM on S/4HANA receives master data via the following interfaces:

S/4HANA EWM receives all master data except for packing instructions via IDoc. The current versions of the respective IDoc types for the corresponding message types are used. You should choose the same version on both the ERP side and the EWM side.

The switch to IDoc means that all interface enhancements implemented in the previously used "APOCF…" BAdIs are no longer valid - the CIF coding is no longer called. You must adapt such developments to the new software stack.

Due to the use of DEBMAS and CREMAS IDocs, supplier and customer records will be transferred separately. This also applies if you are already using SAP S/4HANA with harmonized business partner numbers as your ERP system. You should therefore familiarize yourself with the configuration of Customer Vendor Integration (CVI) on the EWM side and perform the CVI customizing.

Ideally, you can connect your sandbox to an ERP system that was previously connected to SAP EWM on NetWeaver and test the data transfer. This allows you to validate data processing in S/4 EWM as early as possible.

After thoroughly familiarizing yourself with thew new software stack in your sandbox system, it's time to define your migration strategy. The following diagram provides a rough overview of the available migration routes for your workbench objects, customizing and data. In the subsequent sections, we'll cover the details of your EWM migration and share our best practices and project experience.

Few SAP EWM installations get by without custom developments - sometimes they are only custom print forms, but very often Business Add-Ins (BAdIs) in SAP EWM or custom Radio Frequency (RF) transactions are implemented. These developments must remain available after the switch to EWM on S/4HANA. Here's the good news: Aside from the previously mentioned restrictions regarding the master data interfaces (CIF BAdIs are no longer used), the BAdIs already available in EWM 9.5 can still be used in EWM on S/4HANA.

For the migration of your developments, you will need a workbench transport request which you export from the "old" EWM and import into the new EWM system. Ideally, you should proceed as follows:

1. Pull a list of all workbench transport requests imported into your production system.
2. Create an empty workbench transport request or transport of copies in your development system. If you allow this in your quality or production system, you can alternatively create the transport request there. This ensures that no incomplete developments from your development system are transferred. The transport target should be your new development system or your sandbox system for your new SAP EWM.
3. Add all objects to your newly created transport request by selecting the option "Append Objects".

As you can see, a transport route between the old and new systems is required for this migration. If this configuration is not possible, a workaround is to export the transport request with a dummy transport target and copy the transport files via the file system.

The import of some of your developments will likely encounter syntax errors. This may happen and simply means you have to adjust the objects to the new S/4HANA stack. Change the original system of the objects in your new system to the S/4HANA system and rework the developments there. This will be important in the following steps.

You can also migrate your customizing, so that you don't have to start from scratch in your new S/4HANA EWM. For this purpose, you have several options:

• You create a new transport request or transport of copies with all the objects from the customizing transport requests imported into your production system (analogous to workbench objects)
• You use the standard customizing node "Copy Warehouse Number Customizing" and copy the customizing of your EWM warehouse number(s) to a temporary warehouse number. Export the transport request used for this and import it into your new EWM on S/4HANA. Once imported, use the same function to copy the customizing from your temporary warehouse number to your real warehouse number.
• You use alternative, project-specific tools to add your warehouse number customizing to a transport request and import the resulting transport request into your new EWM on S/4HANA. We have implemented tools like this in our migration projects, while also creating the ability to include custom, non-warehouse-number-dependent tables in the same transport. Get in touch to learn more!

The S/4HANA Migration Cockpit is the gold standard for the migrating of your EWM master data. After setting up your sandbox system, you should familiarize yourself with the tool and analyze the extentn to which your master data can be migrated using it.

You can add your own migration objects in addition to the available standard migration objects with minimal effort and integrate them into the Migration Cockpit.

An alternative is manual migration via file download and upload. For a complete list of migration objects, please refer to our previous article "10 Keys to Success for Your Migration to EWM".

For movement data and transactional data, there is no valid migration route. If you are considering creating a custom development in EWM to migrate your movement data from your EWM installation: We advise against it.

Since SAP EWM uses GUIDs to uniquely identify and link warehouse requests and other objects, these would be invalidated during the migration and would have to be re-created with significant effort. The effort outweights the benefit here. Instead, you should:

• Maintain open communication with the business regarding the planned changes
• Close open documents before the migration, i.e. confirm or cancel warehouse tasks and shorten warehouse requests or post goods receipt/goods issue for them
• Keep the "old" EWM on NetWeaver running in the months after the migration, so that old transactions can be looked up
• Prevent postings in the legacy system via authorizations after migration

An exception to this is stock data, of course. You can migrate this via the Migration Cockpit. Alternatively, you can use the stock upload via /SCWM/ISU with the option "Do not post to ERP".

Important note: The Migration Cockpit doesn't migrate stock with document references and does not issue warning or error messages regarding such stock. Therefore, you should remove document references before the migration and verify this right before the stock migration.

After familiarizing yourself with the new S/4HANA EWM and perhaps completing an initial test migration in your sandbox system, you now have your migration strategy in place.

You are now ready to install the new S/4HANA instances for EWM. Start with the development system and the quality system. You can provision the production system later. You must execute the following, previously described steps for each of the systems:

• Installation of the system and setup of transport routes
• Connection to the ERP system
• Migration of workbench objects, customizing and master data

You should execute a test migration for both the development and quality systems. The migration for the Q system also serves as the foundation for tests by the business.

Caution: As soon as you have set up the development and quality systems, you should ensure the import of transport requests from your legacy support landscape into your new systems as well. If the imported developments were already changed in your new system, the transport import will encounter an error (originals must not be overwritten). You must re-work these objects manually in your new system to keep the support landscape and new EWM landscape in sync.

Just like any major system change, extensive testing is necessary when migrating to SAP EWM on S/4HANA. From our experience, it's best to start with an IT-only test. You can conduct this in your sandbox or development system.

In the quality system, you should also conduct testing with the business. This is the only way to ensure the configured processes still work the way they currently do.

You have defined a migration strategy for all the migration objects, successfully tested the migration and your processes and finalized the setup of the new EWM production system. You are now ready to migrate your live EWM system to S/4HANA. You should pay attention to the following aspects:

• While you may of course import your developments and customizing into the production system early, you should migrate master data and stock data only at a fixed migration date of your choice.
• Verify stock quantities before and after the migration in both your old and new EWM systems.
• Again, open and clear communication around the migration is key.
• Lock the users in your legacy system, so that they cannot continue working in the old system after the migration.
• Plan for sufficient IT support resources for the hypercare phase - if necessary, deploy them to the shop floor.

Congratulations! You are now live with EWM on S/4HANA.

The migration itself is completed once you've successfully migrated to EWM on S/4HANA. The new software stack provides you with new possibilities and functionality, which you should explore.

Therefore, we recommend including an optimization phase in your planning after the migration project and scheduling it early on.

In this article, we have guided you through your migration project from EWM on NetWeaver to EWM on S/4HANA. Of course, one article cannot replace our consulting services. Every company and most of the SAP EWM installations have their own unique characteristics that must be considered during the migration.

We hope you found this article helpful and that it provides guidance as you undertake your EWM migration. If you have any questions about this or other topics, please feel free to reach out.

Get in touch