Messy S4 Migration

Editor Team

March 10, 2026

Insights

The ECC 6.0 to S/4HANA migration was supposed to be straightforward.

Three months in, it looked more like a disaster zone than a transformation.

Had a conversation with a CIO at a $3B manufacturing firm today.

He told me something that stuck with me.

Data migration issues everywhere. material masters, open purchase orders, uncleared FI documents that wouldn’t pass HANA’s stricter validation.

Custom code hidden in places no one documented.
Department heads fighting over their must-have features.

ABAP modifications buried in MRP, pricing exits in SD, years of Z-programs nobody wanted to own.

The original plan? Hire one big consultancy to manage everything.

Their response to every challenge? “That’ll require additional scope.”

Then something shifted.

Instead of one generalist team trying to handle it all, they brought in specialists:

→ A data migration expert who’d survived every migration nightmare – LSMW, BODS, failed IDocs and all
→ A process consultant who could translate between business and technical
→ An integration specialist who understood the legacy chaos – PI/PO, EDI , the WMS connections nobody had mapped
→ A change management pro who recognized this as the people challenge it actually was

The conversations changed overnight.

Problems got solved instead of kicked upstairs.
Timelines became achievable.
Teams started believing in the process again.

The difference wasn’t more budget or better technology.

It was pairing specific expertise with actual problems instead of hoping one team could cover everything.

The big consultancy model works fine when your challenge is straightforward.

But complex migrations aren’t straightforward.

They’re messy, political, and deeply technical all at the same time.

What’s your experience? Have you been on a project where specialists made the difference, or where keeping it simple with one vendor actually delivered?

The three messes hiding inside every “messy” migration

“Messy” is always some combination of three underlying messes. Name which ones you have, and the recovery gets clearer.

1. The data mess. Material masters with fifteen years of creative data entry. Open purchase orders nobody wants to close. Uncleared FI documents that sailed through ECC validation and slam into HANA’s stricter rules. The uncomfortable truth: conversion does not fix dirty data. It amplifies it. Every shortcut your data took in ECC becomes a failed validation or a reconciliation nightmare in S/4. The programs that recover fastest are the ones that stop converting and start cleaning, even when the timeline screams otherwise.

2. The custom code mess. ABAP modifications buried in MRP. Pricing exits in SD. Years of Z-programs whose authors retired or simply do not remember writing them. The simplification item check and custom code analysis will tell you the scale, and the number is always bigger than anyone guessed. The recovery question for every object is brutal: keep, fix, or retire. Most “must-have” customizations turn out to be workarounds for problems S/4 solves natively. The ones that survive should be tied to genuine competitive advantage, not habit.

3. The people mess. Department heads fighting over must-have features. An SI whose answer to every problem is additional scope. Business users who were never told their jobs would change. This is the mess that kills timelines, because it disguises itself as a technical problem. It is not. It is a decision problem: nobody with authority will say no to a feature, yes to a standard process, or “we are doing it the S/4 way.”

Why the one-vendor model breaks on complex migrations

To be fair to the big consultancies: the single-vendor model works fine when the challenge is straightforward. A clean greenfield rollout with standard processes and cooperative stakeholders is exactly what large SIs are built to deliver.

But complex migrations are not straightforward. They are messy, political, and deeply technical at the same time, which means they need different kinds of expertise at different moments. The generalist team gives you coverage. Specialists give you answers. When the problem is a data migration nightmare, you do not need a well-rounded team holding a workshop about it. You need the person who has survived LSMW, BODS, and failed IDocs and knows exactly which lever to pull.

The shift the CIO described was not really about vendors. It was about matching specific expertise to actual problems instead of hoping one team could cover everything. That is a staffing philosophy, and it applies whether you hire through an SI, a staffing partner, or directly.

The recovery playbook

If your migration looks like the disaster zone above, here is the sequence that works.

Step 1: Stop and triage. Freeze new scope. Inventory what is actually broken across data, custom code, process, and decisions. Most teams discover the problem is smaller and more specific than the panic suggests.

Step 2: Name an owner for each mess. Data migration gets a data lead. Custom code gets a technical lead with authority to retire objects. The political fights get an executive sponsor who can make decisions stick. Shared ownership of a mess means nobody owns it.

Step 3: Clean data before converting it. This is the step everyone wants to skip, and skipping it is why conversions fail twice. Run validation early, fix the masters, clear the open items. It feels like going backward. It is the fastest way forward.

Step 4: Get honest about custom code. Every enhancement needs a defender and a business reason. “We have always done it this way” is not a reason. Challenge the list, retire aggressively, and watch the timeline shrink.

Step 5: Bring in specialists for specific problems. Not a bigger team, a sharper one. A data migration expert for the data mess. A process consultant who translates between business and technical. An integration specialist who understands the legacy chaos. Targeted expertise, scoped to the problem, for as long as the problem lasts.

Step 6: Treat change management as a workstream. The people mess does not resolve itself when the technical mess does. Users need to understand what is changing, why, and what is expected of them, continuously, not in a single training session the week before go-live.

The CIO’s story ended the way these stories end when the playbook works: problems got solved instead of kicked upstairs, timelines became achievable, and the team started believing in the process again. The difference was never more budget or better technology. It was honesty about what was broken and the right expertise aimed at each piece.

So I will ask again: have you been on a project where specialists made the difference? Or are you living the messy version right now? The recovery starts with naming the mess.