Learn how to master the change easily
You have decided to migrate from your SAP TM 9.5 system to SAP S/4HANA Transportation Management? But what happens next? What needs to be migrated in the first place? What tools and S/4HANA utilities are there and what do they cover? And what S/4HANA best practices exist?
The first question is how the new system should be structured: Which SAP S/4HANA architecture seems to make sense for your company? Should it be a side-by-side setup again, as in the past, where an SAP S/4HANA Transportation Management System was operated alongside other SAP systems (variant 3 in the figure)? Or should it rather be an embedded system? Are the basic functions in the S/4HANA TM Basic Shipping license form sufficient, or should it be S/4HANA TM Advanced, which has the functional depth of SAP TM 9.5? In addition to the omitted interfaces, additional functionalities, the system load and the system owner in the case of a subsidiary organization, release and maintenance cycles are also important considerations here.
In addition, there is the question of how the system should be hosted. Three variants are available:
- On-Premise
- Private Cloud
- Publiccloud (the SAP product differs indetails here).
We recommend a selective migration to S/4HANA
In most cases, we talk about digital core and the greenfield or brownfield approach regarding conversion or data migration from classic SAP systems to new SAP S/4HANA systems. If you manage your shipments in SAP ERP with the LE-TRA component, a migration of data to SAP S/4HANA Transportation Management is unfortunately not possible. In this case, a green field approach must be chosen. However, this offers the opportunity to rethink existing business processes and implement an optimized transportation management solution. You can find more details on this topic in our article on LE-TRA vs. SAP S/4HANA TM Basic Shipping. However, in the case of a migration from SAP TM 9.5 to a S/4HANA TM, there is also the option of a selective migration strategy, often called blue field or s.m.a.r.t approach.
This approach means that part of the data is migrated from the previous system, which corresponds to a consolidation. In addition to master data, transaction data, customizing and developments are now available for selection. Depending on the migration type, it may make sense to transfer only a portion of the data. Thanks to the continuous development by SAP or interim conversions in your company, it is possible to map processes closer to the standard and/or better with S/4HANA Transportation Management than was still possible with SAP TM 9.5.
If you use our software leogistics d.s.c on your SAP TM system instance, you can find more information in our guide to successful upgrade implementation.
Four areas you should consider in your migration project
There are various areas that can be migrated. These are divided into master data, customizing, developments and transaction data, which we will go through individually below and for which we will show migration paths.
Customizing
First of all, customizing of the individual components is mandatory so that the previous systemic process flows are still maintained. Here, of course, it should be noted that there have been some functionality adjustments.
- No more interface to Transportation (Shipment) in ERP (LE-TRA)
- The SAP TM Collaboration Portal has been replaced by SAP Logistics Business Network, but the use of the Collaboration Portal is still possible in certain cases
- No more integration to SAP CRM and SAP EAM elements
For the transfer of customizing the SAP TM Migration Cockpit can be used. You can use a SAP Note to implent the Migration Cockpit (transaction /SCMTMS/2S4H). All migration objects for customizing start with a “CUST_” as prefix.
While the migration object CUST_SCMB SCM contains basic settings such as Geocoding Level, Product Freight Groups, Process Controller Settings, the Package Building profile or PPF configurations, CUST_BF contains the Event Reasons, Handling Codes, Text Types and Attachment Types. CUST_PLN, on the other hand, includes the Contingent Types, Page Layouts for the Transportation Cockpit or Freight Order Types.
So it is possible to migrate numerous customizing settings with this tool. As soon as options are missing here, the SAP TM Migration Tool can be extended
Master data
For master data that comes from an SAP ERP or S/4HANA system in a side-by-side setup, we recommend that you continue to distribute it centrally. Instead of the Core Interface Framework (CIF), the Data Replication Framework (DRF) and transaction BD10 are available for this purpose. More details can be found here.
It becomes more complex with master data that was created in SAP TM. Here it is advisable to make a checklist of which data is relevant and which of it should be migrated manually or automatically. For example, for a few conditions it may be easier to use the integrated upload and download function than to perform an automatic migration. Enclosed for this purpose is our checklist for master data migration, which you are welcome to add to on your own:
- Vehicle Resources
- Handling resources
- Calendar Resources
- Drivers
- Freight unit building rules
- Conditions
- Planning profiles
- Selection profiles
- Capacity profiles
- Incompatibilities
- Forwarding agreements
- Internal agreements
- Freight agreements
- Tariff price tables
Business partners, locations and products are normally master data that are replicated. However, there are also data records that need to be migrated here, such as transshipment locations, dummy business partners or dummy products. These must be created in SAP S/4HANA TM. For the migration, SAP has provided the SAP TM Migration Cockpit as of SAP TM Version 9.5.
The migration objects for master data start with the prefix “MD_” or “US_”, the only exception are the organizational units, these are located in the migration object ORG_HIERARCHY.
It should also be noted that with SAP S/4HANA TM, the condition-based calculation of loading and unloading times, as well as condition-based filtering in selection profiles, is no longer supported and must therefore be mapped in other ways.
Developments
In the case of developments, the question arises as to whether the technological change should also be followed here in some places. While classic ABAP reports were often still developed in customer systems, SAP TM relied heavily on Webdynpros. Instead of Webdynpros, S/4HANA Transportation Management now uses Fiori applications. The S/4HANA Embedded Analytics is an example of this and a good way to substitute operational reporting solutions.
The main task is therefore first to identify the development objects to be transferred. In addition to the Modification Browser (SE95) and the Simulation Customer Enhancement (SE94), the Code Scanner or the ABAP Call Monitor are also suitable for identifying these.
In addition to these, our parent company cbs corporate business solutions offers a solution for identifying and bundling in-house developments, which makes the work much easier.
In some places, code migration will be possible without any problems, especially in strategies and BAdIs. For the majority, however, the developer will have to make manual changes after the migration.
Transaction data
Transaction data is the most difficult object to migrate. We normally recommend that transaction data should not be migrated. This guarantees “closure” of the legacy system. However, if instead of archiving a migration should be the preferred way, the cbs Enterprise Transformer could be a way to transfer the data.
Now, there are also situations in which it is not possible to completely replace a system with a new one in one fell swoop. One reason for this can be found in the project organization: An SAP TM system, which is productively set at 20 locations, which also send each other stock transfer orders, can possibly only with difficulty be changed over and supported at all 20 locations from one day to the next. Another challenge arises when automation is extremely high. In this case, the system must not be down for a minute. Here we are in a situation where documents between systems do not really need to be migrated, but mirrored at runtime.
We are there for you
It is worth taking a closer look at the migration options. Identify the potential for optimization in your move from SAP TM 9.5 to SAP S/4HANA TM. We support you in the decision-making process of your transformation concept and accompany you with concentrated expert knowledge.
For questions about this or other topics in the blog, contact blog@leogistics.com.
Christian Sachse
Senior Consultant SAP Logistics
