Setting Your SAP Data Migration Up for Success
Setting Your SAP Data Migration Up for Success and how to avoid a car crash and the cowboys.
I’ve been doing SAP turnarounds longer than I care to admit, and there’s one thing that never changes.
Data migration destroys programmes.
Not because it’s especially difficult. Data migration is hard work and often unpleasant, but if you get the basics right it is perfectly achievable on time and on budget.
It fails because the way it’s sold, staffed, governed and stitched together is broken.
Despite five decades of collective enterprise delivery experience, most System Integrators still treat data as a sideshow. Then they act genuinely surprised when the programme ends up wrapped around a lamppost, followed by a change request blaming the customer.
I’ve been wanting to write this for a long time, because there is one overriding fact
Data Migration is a Critical Path Shredder and its a Collective Responsibility which starts with the intelligent customer.
Here are my tips as a SAP Turnaround expert.
You Own the Data, They Get the Blame
Clients own the data, and have to buy in to a collective responsibility model, you can not outsource Data Migration ownership to a third party, it simply will not work.
System Integrators own the methods, means, tools, logic, controls and delivery approach, or at least they say they do.
In reality, the data migration approach and capability shown on bid slides and LinkedIn posts is often very thin. A few templates, some spreadsheets, and a lot of confidence.
So when things go wrong, and they always do, accountability collapses.
The business says the programme broke the data.
The programme says the SI migrated what it was given.
The SI says it was out of scope.
Meanwhile UAT is burning, cutover is fiction, and the SRO fires the Programme Director.
Who’s to blame ? Its a collective failure.
If you the customer are embarking upon such a complex and impactful undertaking, you must own data. Ensure you the customer, have you’re own in-house Data Migration Expert, from Phase Zero through to exit from Hyper-care, a key member of the programme leadership team, a veteran and some one the SI’s cant hoodwink.
Migration Is Always Underbid
Every single time.
Data migration is routinely underestimated in bids, under-resourced in delivery, and then rediscovered as a change request once the clock is ticking. At that point it stops being a delivery discipline and becomes a margin recovery exercise, an absolute car crash.
If your data workstream feels like it’s constantly begging for time, people and attention, that’s not accidental. It was priced that way.
If data migration wasn’t properly defined in Phase Zero then , the CIO should and procurement should be asking serious questions as to the governance model and RFP process. If the SI failed to raise the risks and dependencies, they should absorb the cost. This is their profession.
Governance matters.
Make sure the Data RFP is based upon detailed phase zero outputs, if you decide to split the delivery by hiring a specialist data migration partner then make sure the delivery dependencies and handshakes are called out in the respective RFP’s.
Make sure the RFP has a clear set of deliverables and RACI, with a clear expectation on vendor tooling.
Ask the vendor to be clear about their customer dependencies and risk, how how the will mitigate the points I raise in this blog.
Ask the vendor to confirm the business resource dependency, model the level of effort into a resourcing heat map which will stress test the plan and enable the critical path.
Methodologies That Belong in the Bin
Most SI data approaches are still driven by slides and spreadsheets, and belong in the bin.
I walk into turnarounds and I’m genuinely shocked at how often there’s no real data strategy at all and the migration workstream was never modelled !
The common signs of failure to avoid:
No Phase Zero Data Strategy
No delivery modelling linked to the data architecture with a plan that’s made up on the fly
No clear view on what needs cleansing.
No proper archiving decisions.
No extraction and transformation logic tied to business validation.
No clarity or communication as to the role of the business
No linkage to analytics and the SAP data fabric
No clear dependencies, No clear resourcing, poor or non- existent data governance
Under funded and poorly led, that’s the norm.
Then everyone acts amazed when analytics break because the BW data warehouse was hard coded to legacy ECC and needs a half-million-pound S/4 restitch that no one planned for.
SAP Activate as ASAP did before it lays out a very credible data migration approach, these methodologies are a framework, every SAP programme is different and so is the data migration deliverable.
The data migration workstream must be modelled and the programme critical path must have a clear data migration line including Analytics and Data Fabric, Archiving and MDG. MDG should not be separated out, if needs be run data as a portfolio with a dedicated data PM on top.
SAP tooling such as Signavio and LeanIX help develop the agnostic phase zero to-be data model and data strategies, first class and my next newsletter will include LeanIX.
And SAPs migration tooling is best of breed without looking at the SIs own tooling.
So SAP isn’t the problem, the methodology is sound and so is the tooling, who could be to blame ?
Collective Responsibility again is the order of the day.
Master Data, Always Treated as an Afterthought
Master data nearly always runs as a side project.
Which makes no sense, given S/4HANA’s dependency on clean master data and the central role of MDG.
Avoid
No holistic MDG strategy as SAP is seldom the sole authoring system
No Phase Zero to-be MDG process design including external application sync
No MDG ownership and buy-in
No governance model
MDG cannot be bolted on later. If it isn’t designed and funded early, then the programme bleeds.
The SI Factory Model and Data Don’t Mix
Data migration is messy, iterative and cross-functional. That is the opposite of the SI factory model.
It’s never just ECC. It’s BW, analytics, MDG, archiving, APIs and third-party platforms.
Treating migration as a single stream instead of an enterprise-wide data reset is how programmes lose control early.
The offshore-heavy model fails here. Effective data migration needs proximity to business SMEs and fast decisions. Overuse of offshore teams without an onshore mirror is one of the most common failure points I see. To be clear its not the resource its the ability to synchronise resource effectively.
Make sure if your SI is proposing a delivery factory model which I do favour, ensure the offshore model for data is tested including command and control.
Where Are the Grown-Up Data Architects?
Instead of senior, cross-process data architects, SIs deploy object-level analysts working in silos.
Customers. Vendors. Materials.
What’s missing is end-to-end ownership.
Mandatory Phase Zero outcomes should include a future data strategy, a data health assessment, a data object registry and named data owners. If you don’t know what data you have, its condition and who owns it, you are already in trouble.
In a cognitive world, customers should also have data scientists sitting above migration with a dotted line into the programme, not bolted on after go-live.
Tools Don’t Save You From A Blood Bath
Migration vendors roll out their standard blue, brown and greenfield tooling, but without people who actually understand it, the whole thing collapses.
The same names appear repeatedly with under-resourced, inexperienced teams.
SAP’s Migration Cockpit is genuinely strong. In the right hands, it works. But S/4HANA migration is still brutal, especially Bluefield scenarios.
This is not a tooling problem. It’s a capability problem.
Back in the day, BODS was a thing of beauty. Dan Barlow and his teams at JLR were absolute masters with it. SAP’s Migration Cockpit is genuinely first class and builds on that legacy.
AI, Dirty Data and the Real Future
Here’s the twist. AI loves dirty data. It doesn’t panic, it learns.
We’re already seeing agents inside SAP cleaning up master data and spotting issues caused by inbound APIs. And SAP isn’t always the master with data changes happing outside of SAP and never getting pushed back properly.
By 2027, AI will take a lot of the pain out of S/4 data migration, but only if SAP invests in the tooling. The SIs won’t do it for them.
Design First, Data Last, Cue the UAT Car Crash
SAP Activate isn’t the problem. The problem is that data planning doesn’t happen early enough.
Blueprint kicks off at speed, the data workstream isn’t ready, and the first delay is baked in. Migration falls behind, data quality drops, SIT starts limping along, and everyone knows what’s coming next.
UAT delay.
Seventy percent of SAP programmes delay UAT, and data is usually the culprit. It’s not ready, it’s rubbish, and the business has no idea how to reconcile it.
I’ve even seen data migration testing happening in UAT. Cowboys.
Data Governance That Turns Up Too Late
Master data ownership, data governance and data cleansing are always declared “out of scope”, when they are very clearly in scope. Again, Phase Zero is where this should be nailed down.
When schedules slip, data cycles are the first thing cut. Test integrity collapses, confidence disappears, and go-live becomes a leap of faith.
Time and time again data is simply rammed in.
PMO Paralysis
Data migration is a metric driven exercise, but all to often PMOs are generic and don’t understand the complexity and dependencies arising from data migration.
The critical path is normally driven by data and integration and the plan needs to be driven by the metrics, math doesn't lie, wordy status reports do……
Make sure your PMO is real time sitting on top of the data stream
The Core Pattern I See in Every Turnaround
Data migration doesn’t fail because of SAP. It fails because accountability, realism and ownership are missing.
Data treated as a technical task, not a business asset.
Bad data hidden until it’s too late.
Too much data migrated “just in case”.
Indecision on strategy.
Tools mistaken for solutions that the SI can’t get to work properly
Business Reconciliation treated as an afterthought.
Lack of data design
Lack of data resource (busienss, programme, SI)
Lack of data leadership
Analytics and Reporting are some one else’s problem
Keep ECC running to archive the data !
By the time cutover arrives, the programme is running on hope and caffeine.
And hope is eternal
but its not a strategy
Dragon ERP Call to Arms
If your SAP data migration feels like a car crash in slow motion, don’t wait for the airbags to deploy.
Speak to me and my team at Dragon ERP. We specialise in SAP programme turnarounds, data rescue jobs and getting control back where it’s been lost.
If your data’s a mess, your UAT’s wobbling, or your SI’s telling you it’s all “business owned”, give us a shout. We’ve seen it all, and we know how to fix it.
No cowboys. No fairy tales. Just hard truths and proper delivery.
About the Author
Alisdair Bach is a recognised SAP Programme Director and turnaround specialist — often called a “turnaround king” by clients for his ability to stabilise and recover the most complex and failing SAP programmes. With decades of experience across global private equity and public sector portfolios, Alisdair has led high-stakes SAP S/4HANA transformations, finance and supply chain turnarounds, and complex delivery rescues.
Alisdair is also a SAP analyst working to define for investors where next with SAP, he is a author and lecturer, he defined the SAP upcycling concept as the alternate narrative to rip it out and start again clean core that is counter intuitive to AI adoption and SAPs 5X growth strategy.
Through Dragon ERP, he brings board-level assurance, forensic diagnostics, and hands-on leadership to programmes that others have written off — combining empathy with no-nonsense execution to deliver results where failure once seemed inevitable.
