SAP TM 9.5/9.6 → SAP S/4HANA Transportation Management (TM) Migration: Things to Take Care Of

Introduction

Moving from SAP TM 9.5 or 9.6 to SAP S/4HANA TM is not a copy exercise. SAP gives you a migration tool, and the tool works. But the tool moves what you tell it to move. It does not tell you what should move.

That decision is the project. This article covers what to confirm before you start, how to decide what to keep and what to leave behind, where these migrations usually go wrong, and what to test before you go live.

Why SAP TM 9.5/9.6 Migration Requires More Than a System Upgrade

The word “migration” makes this sound like an upgrade. It is not. TM on S/4HANA is a different code line from TM on NetWeaver or SCM, and a number of things behave differently once you get there.

Three of them matter more than the rest.

The business object model has changed. Your BOPF enhancements, determinations, validations and actions do not travel across untouched. Node structures, fields and associations are different. Some of your custom objects will need to be rebuilt and tested again, not just transported.

The optimizer is not the same. Planning profiles from 9.x cannot simply be carried over. Parameters, constraints and available features differ from 9.x VSR planning. Rebuilding planning profiles is a design activity, and it needs the same attention you would give a new build.

In an embedded deployment, half your master data problem disappears. If TM sits inside your S/4HANA system, customers and vendors are already business partners, plants and shipping points are already there, and products already exist. You do not need CIF, and you do not need transportation requirements — orders and deliveries create freight units directly. This changes the size of the project, and most teams work it out too late to benefit from it.

The teams that struggle are the ones that treat this as a data move. In the TM 9.x migrations we have run, that single assumption causes more rework than anything else.

Before You Start: What to Confirm

Get these closed before the project starts. Every one of them affects either cost or design, and every one of them is painful to change later.

• Deployment model: embedded TM, or decentralised (side-by-side) TM

• Licensing scope: Basic Shipping or Advanced TM

• Target S/4HANA release and feature pack

• Which TM functions are actually supported in that specific release

• SAP Business Network for Logistics readiness

• Middleware readiness, and whether middleware is being replaced at the same time

• Carrier onboarding plan

• Visibility strategy: Event Management or Global Track and Trace

• Availability of business and IT people, not just IT

• System and environment access

• Planned go-live date

• Who is responsible for what, between you and your partner

The first two are the ones teams leave until later, and they are the two that decide everything else.

On deployment, the rule is simple. Basic Shipping runs embedded only. If you want TM on its own system, side by side with one or more ERPs, that is Advanced TM and it carries a separate licence. Advanced TM can also run embedded, so embedded does not automatically mean basic scope. SAP Note 2714892 covers the deployment options, and SAP Note 3065464 covers the difference between Basic Shipping, basic TM and Advanced TM. Read both with your account team before anyone draws an architecture diagram.

On release, do not assume. A feature that exists in one S/4HANA release may not be in yours. Check against your target release and feature pack, not against a blog post or a demo you saw last year.

Keep, Retire, Redesign: The Decisions That Should Come Before Migration

Before you move anything, go through what you have and put each process into one of three buckets. This sounds obvious. It is skipped on most projects, because moving everything feels faster.

“We had it in TM 9.x” is not a reason to keep it.

Keep

The process is still relevant, and S/4HANA TM supports it. Keep it. But ask whether it is still relevant going forward, not whether people are used to it. Those are different questions.

Retire

If it is not adding anything, leave it behind. Anything you migrate has to be tested, documented and maintained afterwards, forever.

Be concrete about this. If a lane has had no shipment activity for three years or more, retire it. The same applies to transportation zones. Plenty of companies carry zone structures built up over ten or fifteen years into the new system without asking whether the business still works that way. Zones that granular can slow the optimizer down and hurt planning performance, and you will spend the first six months after go-live wondering why.

Redesign

Still relevant, but S/4HANA TM handles it differently. This is where most projects get stuck, because the instinct is to make the new system behave like the old one.

Custom development needs particular attention here. The business object model has changed, so enhancements, determinations and validations get rebuilt and revalidated rather than transported across. Every custom object deserves the same question: is the requirement still real, and does standard functionality now cover it?

Where SAP TM 9.5/9.6 Migration Projects Commonly Go Wrong

These are the specific things that hurt, in rough order of how often we see them.

Everything gets migrated because it exists. Mature 9.x landscapes carry hundreds of custom objects, built up over years by people who have since left. Moving all of it means paying to maintain code that standard S/4HANA TM functionality now covers. Every object needs a decision, and “it works today” is not the decision.

Transports go in the wrong order. Configuration-dependent Workbench transports go first, dependent developments after. Move utility and helper classes early. Get this sequence wrong and you will spend days on activation errors that have nothing to do with your actual design.

Event Management is treated as a copy-across. EM is available on S/4HANA, but it is a separately licensed add-on rather than something that arrives with TM, and moving from an older EM release is a conversion project rather than an upgrade. SAP positions Global Track and Trace for visibility that involves carriers and partners, and EM more for tracking inside your own organisation. Either way, TM developments that depend on EM need rework, and rewriting tracking scenarios is design work, not migration work. Confirm the licensing and release position for your target version before you design anything around it.

Middleware is replaced at the same time. If the integration platform is also changing, plan both together. Two moving platforms and one test cycle is how go-live dates slip.

An ERP upgrade lands mid-build. In an embedded deployment this can destabilise configuration underneath you. Agree a freeze window and a regression sprint at planning stage, while it is still a calendar conversation and not an argument.

Carrier onboarding is left until after go-live. Here is the reality check nobody puts in a proposal: in a landscape with seventy-plus carriers, only a small number are typically already on the network. Tier your carriers by volume, decide a channel for each tier, and exchange live messages during integration testing. Not after.

Master data replication is designed the old way. In a side-by-side setup, master data from ERP or S/4HANA is distributed through the Data Replication Framework, not CIF. If your 9.x integration design assumed CIF, that design does not carry forward.

Financial flow is never properly validated. Freight rates, costs, invoices and tax data have to reach finance correctly. This gets tested last and found broken first.

Cutover and Open Shipments: One of the Most Important Decisions

H3: Big Bang or Phased

Decide whether everything moves at once, or in waves. Phased lowers the risk but means running two systems side by side for a while, with all the reconciliation that brings.

Be precise about what a wave contains. Not “module A and module B” — that means nothing in a transportation context. One region, or one set of plants, or one transportation scope moves to S/4HANA TM while the rest of the business stays on the current process until the next wave.

H3: Open and In-Transit Shipments

You go live next week. Several hundred freight orders are already open. Some are waiting for pickup, some are on the water, some are delivered but not settled. What happens to them?

There are four answers, and you need to pick one before cutover week, not during it.

Complete in legacy. Let the old system run until every open shipment is delivered and settled. All new shipments go into S/4HANA TM from day one. This is the simplest option and the one most teams choose.

Recreate in the new system. Freeze the open shipments, close them in the old system, create them again in TM. Works when the open volume is small and the documents are simple.

Migrate the open documents. Move open freight orders across. Coming from TM 9.x this is technically possible, but it carries risk and needs careful validation of charges and status. Do not choose this because it sounds tidy.

Hybrid. Complete long-running ocean and rail shipments in the old system, recreate short-cycle road shipments in TM. Common in practice, because the two have very different lifespans.

Whichever one you pick, you still have to answer the same follow-up: where do shipment status, freight charges, tracking events, documents and settlement live for those shipments until they close? Answer that in writing.

H3: Data Freeze Window

Agree a fixed period where users stop making changes, so the team can take a clean and consistent set of data. Communicate it early and enforce it. A freeze that people quietly work around is worse than no freeze, because you will think your data is consistent when it is not.

What to Test Before SAP S/4HANA TM Go-Live

In a migration, most of what testing finds is not new-build defects. It is migrated data and migrated settings behaving differently in the new system. Test accordingly.

Freight agreements and rate tables. Take the same shipment, run it in both systems, and compare the charge line by line. Pay particular attention to rates that combine weight breaks, distance bands and lane conditions. This is a common source of disputes after go-live, and it is much cheaper to find now.

Transportation zones and locations. Are migrated zones resolving the way you expect? Are stale locations producing routes that make no sense?

Planning profiles. Run the same planning scenario in both systems and compare the results. If they differ, understand exactly why before you accept it.

Freight order lifecycle. Create, plan, tender, execute and settle one order end to end, for every transportation mode in scope. Not just road.

Carrier connectivity. Send and receive real messages with live carriers. Internal test data proves nothing about a carrier’s mapping.

Settlement and finance posting. Confirm freight costs reach finance with the correct tax treatment.

Open shipments. Test whichever cutover option you chose, before cutover week.

When testing turns something up, be clear about what it is, because the path is different for each. A defect gets reproduced, checked against SAP Notes, raised, worked around and tracked to closure. A functional gap needs a check on whether the release supports it at all, then a look at configuration, before anyone assumes custom development. A critical issue needs an escalation path, an owner, severity levels and response targets already agreed — not decided while go-live is at risk.

On hypercare, agree exit criteria in writing before you start, and set the numbers against your own operation. There is no standard SAP definition of “stable”. A practical starting point: no P1 issues open for fourteen days running, nightly planning jobs completing within SLA over the same period, EDI success above 99 percent, knowledge transfer finished, and formal sign-off from the business.

What SAP TM Migration Experience Has Taught SCM Champs

Everything in this section comes from running SAP TM 9.x to S/4HANA migrations, not from reading about them. These are the points that cost our clients time and money before we learned to catch them early.

The Migrations Behind This

TM 9.x to S/4HANA TM migrations delivered		14
Deployment models		Both embedded and decentralised (side-by-side)
Industries		Automotive, chemicals, consumer goods, industrial manufacturing, retail, life sciences
Transportation modes		Road, ocean, rail, parcel, intermodal
Geographies		North America and Europe
Largest landscape assessed		340+ custom development objects
Carriers onboarded		85+ across 9 programmes

What these projects had in common: a mature 9.x system, years of custom development, and a business that had stopped questioning why things worked the way they did. What varied: deployment model, transportation mix, and how much of the master data already sat in S/4HANA.

What We Delivered on These Migrations

• Ran the fit-to-standard assessment that decided, object by object, what moved and what was retired, and produced the decision log that recorded why

• Confirmed the deployment model against transportation volume, how many ERP systems feed the process, and whether TM needed its own upgrade cycle

• Migrated TM-specific master data and settings — locations, transportation lanes, freight agreements, rate tables, calculation sheets, schedules, zones — and built the key mappings needed before any of it could move

• Rebuilt planning profiles for the S/4HANA optimizer instead of carrying 9.x parameters across

• Assessed custom development object by object, sequenced the transports, and moved utility and helper classes ahead of the objects that depended on them

• Redesigned tracking scenarios where developments depended on Event Management

• Tiered carriers by volume, agreed a channel per tier, and exchanged live messages during integration testing

• Built and rehearsed the cutover runbook, with master data in production ahead of the go-live weekend

• Ran hypercare against written exit criteria, then handed over runbooks the client’s own team could operate

What We Have Seen Across These Migrations

Embedded changes the size of the project, and people find out late. When TM sits inside S/4HANA, business partners, plants, shipping points and products are already there. What actually needs migrating is the TM-specific material: transportation lanes, freight agreements, rate tables, calculation sheets, schedules, and locations that only exist for transportation such as ports, rail yards, cross-docks and transshipment points. Teams that understand this in week two run a much smaller project than teams that understand it in month four.

Freight agreements are the hardest thing to move. Key mappings have to be built first, and technical success means very little on its own. What matters is whether the charge comes out the same. We validate these functionally, not just technically, and we have never regretted the time it took.

Planning profiles are a rebuild. Every time. Optimizer behaviour in S/4HANA TM is not 9.x VSR behaviour, and copying parameters across gives you a system that plans differently and nobody can explain why.

Data quality problems do not stay hidden. Whatever is wrong in 9.x will be wrong in S/4HANA, except now it is wrong in a system nobody knows yet. Cleanse before, not after.

The Mistakes That Cost the Most

• Migrating something because it exists, rather than because it is needed

• Carrying a decade of zone granularity forward, then wondering why planning is slow

• Migrating lanes with no activity for years, and paying to maintain them afterwards

• Assuming BOPF enhancements will transport cleanly

• Finding out during hypercare that carriers are not ready

• Letting an ERP upgrade land mid-build with no configuration freeze

• Treating Event Management as something that copies across

How SCM Champs Helps Companies Avoid SAP TM Migration Mistakes

Most migrations run into trouble for the same reason. The team starts moving data before anyone has decided what should move. We work the other way round.

H3: What Usually Goes Wrong, and Where We Step In

What usually goes wrong		How we prevent it
Everything gets migrated because it exists		Every process passes a fit-to-standard check before it moves — keep, retire, redesign or replace, signed off by the business, with the reason recorded
Bad data arrives in the new system and gets cleaned afterwards		Lanes, locations and zones are assessed and cleansed before migration. Inactive lanes and stale locations do not make the trip
Freight charges do not match after go-live		Migrated agreements are validated functionally, not just technically. Same shipment, both systems, compared charge by charge, including weight-break, distance-band and lane combinations
Planning is slower than it was in 9.x		Zone structures are redesigned against how the business runs now, and planning profiles are rebuilt for the S/4HANA optimizer rather than copied
Custom code fails on activation		Development objects are assessed individually, utility and helper classes move first, and transports are sequenced so configuration-dependent objects go ahead of what depends on them
Carrier problems surface during hypercare		Carriers are tiered by volume, a channel is agreed for each tier, and live messages are exchanged during integration testing
Cutover weekend gets improvised		A task-level runbook, rehearsed end to end before the real thing, with master data in production ahead of go-live
An ERP upgrade destabilises the build		Freeze window and regression sprint agreed at planning stage, not negotiated mid-project
Hypercare never ends		Exit criteria agreed in writing up front, with the numbers set against your operation

Day to day, this looks like fewer surprises and more written decisions. You will be asked to sign off things that other projects would have decided quietly on your behalf.

The Strengths Behind That

• Consultants who have configured freight agreements and charge management in both TM 9.x and S/4HANA TM, and know where the two behave differently

• Cutover leads who have run dress rehearsals on live transportation operations, not just planned them

• Integration people who have worked across older SAP middleware and current platforms, so a middleware change running alongside a migration is a known situation rather than a new one

• A fit-to-standard method with written gates, so “we had it in 9.x” never survives as a reason on its own

• Delivery across North America and Europe, so time zones and regional carrier differences are handled inside the team

What You Are Left With

Not just a running system:

• A decision log recording why each process was kept, retired or rebuilt

• A configuration workbook covering every setting and the reason behind it

• Integration specifications for each interface

• Runbooks your own team can operate without calling us

SCM Champs works across North America and Europe on SAP TM and wider SAP supply chain programmes, and stays with the project through hypercare into normal operations.

Final CTA

Planning an SAP TM 9.5/9.6 to S/4HANA TM migration?

Talk to SCM Champs. We will assess your current system, help you decide what should move and what should not, and build a migration plan you can actually run.

View source version on businesswire.com: https://www.businesswire.com/news/home/20260827101686/en/