Moving Off SAP TM 9.x: What Changes, What Breaks, and What to Decide First

A planning guide for teams migrating SAP TM 9.5 / 9.6 to SAP S/4HANA Transportation Management.

The Starting Position

Ask a room of transport planners what they think about the move to S/4HANA TM and you usually get a shrug. They have run SAP TM for years. Same product name. New host system. How different can it be?

That shrug is the problem.

Coming from TM 9.x should be an advantage. You have working charge management. Your carriers are live. Your planners know the cockpit. Compare that to a company migrating off LE-TRA and you are miles ahead.

But the advantage only pays off if you use it deliberately. Left alone, familiarity does the opposite. It lowers the perceived risk, shrinks the test plan, and delays the questions that actually decide how this project goes.

Here is what is genuinely different underneath. TM 9.x runs on NetWeaver as its own product. S/4HANA TM does not. The functional surface looks similar, and much of it is. The architecture, the UI stack, and — depending on your deployment choice — the entire integration model are not.

There is also a deadline attached. SAP’s maintenance window for TM 9.x has an end date. Confirm yours with SAP before you plan anything else, because that single date will shape your timeline more than any decision in this guide.

What follows is organised the way the project actually runs. What you decide first. What changes underneath. Where things break. What you are left holding afterwards.

Part One: Decide These Before Anything Else

1. Embedded or Side-by-Side

Answer this first. Scope, cost, integration effort and timeline all hang off it, and every week you leave it open is a week of design work built on an assumption.

Embedded TM lives inside S/4HANA. One system. One client. One Business Partner. The ERP-to-TM integration layer stops existing. For the right landscape this removes a genuine ongoing cost and a genuine ongoing failure point.

Side-by-side TM stays as its own S/4HANA system, integrated with your ERP. You keep an integration layer and a second system to run. In exchange you keep independence.

Rough guidance:

Embedded tends to fit a single SAP ERP, moderate transportation volumes, and an organisation comfortable moving TM and ERP on one release cycle.

Side-by-side tends to fit multiple ERPs or a non-SAP ERP, high volumes, logistics service provider models, or a need to upgrade TM independently.

Two checks before you commit:

Functional fit against your target release. Embedded TM has closed most of the distance from standalone TM 9.6 over recent releases. Not everything arrived at once, and sub-contracting, LSP scenarios and parts of settlement have their own histories. Check against your scenarios and your release, not against a general claim in a slide deck.

The optimizer. Planning and optimisation runs on a separate component with its own version dependencies. Teams forget it exists until planning results come back wrong during testing.

Get business, IT and architecture to agree this together, and write down why. Someone senior will ask you to justify it in month six.

2. What Deserves to Move

You have probably been on TM 9.x for the better part of a decade. Systems accumulate. Before anyone builds a data load, walk the business through what is actually in there and sort it.

Three outcomes, and only three:

It still earns its place, and S/4HANA TM already does it. Take it across on standard. No cleverness required.

Nobody needs it. Leave it behind. This bucket is always larger than people expect, and it is where most of the savings are.

Still needed, but the new system handles it differently. Adapt the process. The instinct here is to make S/4HANA TM behave like TM 9.x. That instinct is how organisations pay for a new system and get their old one back.

Where to look, by category:

The first column catches people out. A good share of your master data may already sit in S/4HANA. Half a day checking this can remove weeks of duplicated work.

The middle column is the actual project. The third column is where the money is.

Rate tables deserve a specific mention. They pile up quietly and nobody deletes them. Bringing an expired rate table across is not free — you pay to migrate it, then you pay again every time someone tests it, documents it, or trips over it in support.

3. What Happens to Your Custom Code

There is always a list. Enhancements, reports, developments that people expect to see on the other side because they have always been there.

Assess every item individually against this order:

Standard S/4HANA TM → configuration → SAP-released extension point → SAP BTP → custom development.

Stop at the first one that works. Most items stop early. Several releases have shipped since your TM 9.x code was written and standard has absorbed a lot of what teams once had to build.

Two areas need specific attention when you are coming from TM 9.x:

BOPF enhancements. Custom determinations, validations and actions written against the TM business object layer do not all transfer cleanly. Each needs its own assessment. A blanket “these will be fine” is not an assessment.

Custom Floorplan Manager screens. Where standard has moved to Fiori, FPM work may not carry across at all. This one arrives late in projects and costs more than expected. Inventory it during assessment, not during build.

When custom development is genuinely justified, build it so it survives the next upgrade. BTP, released APIs, approved extension points, core left alone. Then document it and get architecture sign-off.

Worth noticing: undocumented, ungoverned custom code is a large part of why organisations get stranded on old releases. If that description fits your TM 9.x system, you are living the consequence right now. Try not to build the same problem twice.

Part Two: What Changes Underneath

4. Integration Is Harder Coming From TM 9.x, Not Easier

A company migrating from LE-TRA builds transportation integration for the first time. You are doing something harder. You are taking apart something that works today, while it keeps working, and putting it back together differently.

ERP to TM. Go embedded and the whole layer between ERP and TM disappears. That is a real simplification, and it also means flows your team has supported for years now behave in a way nobody on your team has supported before. Stay side-by-side and the integration gets rebuilt on new technology. Either way, “re-point the interfaces” is not the job.

Middleware. Plenty of customers are moving off PI/PO at the same time. Two migrations running in parallel need one plan with one owner, not two plans that occasionally meet.

Business Partner and master data. Business Partner is mandatory in S/4HANA. Your ERP customer and vendor records and your TM business partner records have almost certainly drifted apart over the years. Reconciling that is assessment-phase work. It is not something you discover on cutover weekend.

Freight settlement into finance. The settlement flow changes shape, and it changes more under embedded than side-by-side. Freight cost has to reach finance correctly on day one, so test this with the finance team, not around them.

Visibility. Your SAP Event Management setup needs an actual decision. Confirm SAP’s current direction and licensing for visibility and track-and-trace before you design around any of it.

Tax. Transportation and freight processes lean on tax determination more than people remember. Include it in end-to-end testing.

Take each one, assess it during planning, test it end to end, and write down what you will do if it fails.

5. Version Dependencies Nobody Wants to Talk About

A short list, and each item can move your timeline:

• Your current TM release, support package and confirmed end-of-maintenance date

• Target S/4HANA release and feature pack

• Which S/4HANA TM functionality is available and supported in that release

• Optimizer version and compatibility

• Middleware readiness

• Visibility strategy

• SAP Business Network for Logistics readiness

• Carrier reconnection plan

• Environment and system access

• Availability of your own business and IT people

• Target go-live date

• Written split of what the client owns and what the partner owns

One rule matters more than the rest. Design against what is available and supported today. Not roadmap. Not a note that might land in time. Roadmap-based design is a bet you place with someone else’s go-live date.

And be aware that a change in feature pack, support package or optimizer version can quietly expand your regression testing and configuration effort after you have already committed to a plan.

Part Three: Where These Projects Break

6. Carriers: Reconnection, Not Onboarding

Your carriers are already integrated, which sounds like less work than it is.

Every connection has to be stood up against the new system, remapped, retested, and cut over without interrupting daily operations. And you control roughly half of that work. The other half sits with organisations who have their own priorities and their own IT queue.

• Segment by volume and business criticality. Not every carrier needs the same treatment.

• Confirm the channel for each — EDI, API, portal — and whether it is changing

• Rebuild the integration mapping properly. Assume nothing transfers untouched.

• Agree who owns the carrier conversation: you or the partner

• Test end to end, carrier by carrier, before go-live

The timing rule: connections should be ready for integration testing, not delivered during it. Late carrier readiness is one of the most reliable causes of a slipped TM go-live.

7. Cutover and the Documents Nobody Planned For

This gets raised late and then eats a weekend. Settle it early:

• Big bang, or phased by region, plant or lane

• What happens to freight orders open or in transit at the switch

• What happens to freight settlement documents raised but not yet settled. This is regularly missed, and it lands on finance rather than logistics.

• Length of the data freeze and who it affects

• Go/no-go criteria, agreed in advance, and a fallback plan

8. Testing, Defects and Gaps

Things will break. What separates good projects from bad ones is having a routine ready before they do.

For a product defect: reproduce it reliably, search SAP Notes, raise a Support ticket where warranted, put a workaround in place so testing continues, and track it to closure.

For a functional gap: evaluate it, check whether standard already covers it, look at redesigning the process, and only then consider an enhancement.

Agree an escalation route for critical issues at the start. Without one, real problems sit in a tracker for three weeks and then reappear as a go-live risk.

Part Four: What You Are Left With

9. Hypercare, and Knowing When It Ends

Plan a real hypercare period:

• Named S/4HANA TM specialists, available

• P1 to P4 prioritisation with agreed response and resolution targets

• Regular issue review calls

• Active monitoring of integrations, EDI flows and background planning jobs

• A defined escalation path

Then agree the exit criteria before hypercare starts, not while you are in it. Normal support begins when critical issues are closed, core processes run stably, integrations and EDI are reliable, planning jobs behave, knowledge transfer is complete, and the business has signed off in writing.

10. Your Team, Not Just Your System

Your planners know TM already. Train them anyway. They are not learning transportation management from scratch. They are learning a new interface and giving up workarounds they have refined over years. That is a shorter training curve, not an absent one. Skipping it because “they already know TM” is a specific and common mistake. Fiori on day one feels unfamiliar even to a fifteen-year TM user.

Ask for the right experience. Not TM experience generally. This move specifically — TM 9.x to S/4HANA TM, ideally with the deployment model you have chosen.

Insist on named people and named backups. Every workstream. With a handover process that exists on paper. Consultants change roles mid-project and delivery should not wobble when they do.

Your side has to show up too. Business, IT, master data, integration, architecture and testing. Agree those commitments in writing at kickoff, because they are the ones that quietly slip when day jobs get busy.

What should exist when the partner leaves: configuration documentation, a Fit-to-Standard decision log, a customisation and RICEF register, integration specifications, operational runbooks, test evidence and knowledge transfer material.

A useful test of whether the project is really finished: can your own people run and change this system next quarter without calling anyone? If not, something is still owed to you.

Part Five: Working With SCM CHAMPS

11. What We Bring to This Specific Move

We have taken customers through this exact migration — from a mature, working TM 9.x system into S/4HANA TM — across North America and Western Europe, focused primarily on industrial manufacturing, consumer products, and chemical distribution.

That covers more than forty migrations, spanning both embedded and side-by-side deployments.

What that changes for you:

The right questions get asked in week one. Deployment model. Optimizer version. Business Partner alignment. BOPF and FPM inventory. We are not discovering these in month four. They are the opening conversations, because we already know they set the shape of everything after.

We know what a ten-year-old TM system looks like inside. Rate tables layered on rate tables. Enhancements built by someone who left in 2019. Profiles with no owner. Having opened these systems before, we can tell you fairly quickly what is live and what is just occupying space.

We know where standard has caught up. A meaningful portion of what was custom on TM 9.x is standard now. Checking that before anyone writes code usually removes real scope, and it is the cheapest saving available on this kind of project.

We plan for how these go-lives actually behave. Carrier reconnection timing. Open freight orders. Unsettled freight cost. The first fortnight of planner support. These are scheduled from the start rather than handled as surprises.

What This Has Looked Like in Practice

Industrial chemicals manufacturer, Midwestern United States. Running TM 9.5 with 22 carriers integrated and roughly 9,000 freight orders a month. We assessed the landscape and found over 60% of rate tables unused and 18 custom objects already covered by standard. Moved to embedded TM. Go-live on plan, with 11 custom objects retired before migration and planning output validated against legacy for two full weeks before cutover.

Consumer goods distributor, Germany. Running TM 9.6 with 40+ carriers and 15,000 freight orders a month across multiple ERPs. We assessed and confirmed side-by-side was the right fit. Found a heavy BOPF enhancement layer that needed individual review—most of it replaced by standard functionality in the target release. Go-live phased by region, starting with DACH. Settlement flows tested with finance from the first integration cycle, not the last.

Industrial machinery manufacturer, Canada. Running TM 9.5 with 14 carriers and 4,500 freight orders a month. This was a smaller landscape but a complex one—custom FPM screens, aging optimizer configuration, and a PI/PO middleware layer being retired in parallel. We moved to embedded TM, replaced the custom screens with standard Fiori apps, and re-validated the optimizer against three months of live planning history. Go-live on plan, with hypercare closing after four weeks.

12. Mistakes We Help You Avoid

Every item below has cost a real project real time. This is the part of the job where an experienced partner earns the fee — not by working harder, but by keeping you out of these.

Scoping it as an upgrade. Testing gets planned as a regression pass. Then the team discovers the architecture underneath moved and the plan was never sufficient. We scope it as a migration from day one, with end-to-end testing across the full transportation lifecycle.

Letting the deployment model drift. Embedded versus side-by-side gets decided on cost alone, or not decided at all, then reopened mid-build. Everything downstream moves with it. We force a documented decision early, assessed against your scenarios and your target release.

Migrating rate tables and agreements wholesale. Years of expired and duplicated pricing comes across, and now all of it needs testing, validating and supporting. We establish what is actually in use before anything moves. Usually the single largest reduction in scope.

Ignoring the optimizer until testing. Planning results differ from the current system and nobody can explain why. User confidence drops quickly and is slow to recover. We confirm optimizer version and settings during assessment and validate planning output against your live system deliberately.

Assuming custom code transfers. BOPF enhancements and custom FPM screens turn out not to fit, discovered too late to redesign calmly. We build a complete custom object inventory during assessment and test every item against standard before agreeing to rebuild it.

Starting carrier work late. Integration testing opens without live carrier connections. The test cycle slips and go-live follows it. We begin carrier planning in the first weeks so connections are ready when testing needs them.

No agreed treatment for open documents. Cutover weekend arrives with no answer for in-transit freight orders or unsettled freight cost. Finance finds out afterwards. We agree this in writing, early, with logistics and finance both in the room.

Thin knowledge transfer. The partner leaves and your team cannot confidently support what they inherited. Every minor change becomes a new engagement. We define handover material and exit criteria at project start, and hypercare does not close until your team confirms they can run it.

13. How We Run It

Assess the existing TM 9.x landscape, configuration and custom objects. Decide the deployment model against your real scenarios and target release. Challenge the processes, data and customisations that have gone unquestioned. Fit-to-Standard every requirement before anyone discusses customisation. Clean out what has stopped earning its place. Redesign the processes that need to work differently. Migrate only what the business genuinely needs. Integrate ERP, carriers, visibility and the surrounding platforms. Test the full transportation lifecycle end to end. Stabilise through hypercare into normal operations.

What We Commit To

North America and Europe. SAP TM and supply chain delivery across both regions.

Named experts, with named backups. Every workstream. Continuity planned rather than hoped for.

Hypercare until the agreed exit criteria are met. Not until a date passes.

Where This Leaves You

Three things reliably separate the migrations that land well from the ones that limp:

Fit-to-Standard decisions made honestly, so legacy complexity stops here instead of being rebuilt.

Integration and data planning started early, so systems, carriers and clean data are ready before testing needs them, not during.

Post-go-live support that is real, with hypercare, stabilisation and knowledge transfer that actually transfers knowledge.

You have run TM 9.x long enough to know exactly what works in it and what your team quietly works around. Very few organisations get a clean opportunity to act on that second list. This is yours.

Planning your move from SAP TM 9.5 / 9.6 to S/4HANA TM? Talk to SCM CHAMPS about assessing your landscape, choosing between embedded and side-by-side, and building a migration roadmap you can actually run.