Insights - Enterprise Transformation

Moving House: A Field Guide to Best-in-Class Data Migration for SAP S/4HANA

Every enterprise transformation eventually asks the same unglamorous question: what do we do with twenty years of data? Here is how the best migrations answer it, and why the audit committee should care as much as the CIO does.

There is a particular kind of dread that sets in a few weeks before a house move. Not the packing itself, that part is almost fun. It is the loft. It is the drawer nobody has opened since a promotion two roles ago. It is the box marked "important documents", which everybody has carried through three house moves without ever checking what is actually inside. Enterprise data migration is exactly this, except the loft is a legacy Enterprise Resource Planning (ERP) system, the drawer is a spreadsheet a departed employee built in 2016 that finance still quietly depends on, and the box marked "important documents" is the general ledger. Everybody knows it needs to move house. Almost nobody has looked inside it in years. And unlike a house move, if you get this one wrong, an auditor will eventually ask you to explain why.

Why the Loft Matters More Than the Living Room

Most SAP conversations focus on the parts everyone can see: the new user interface, the redesigned approval flow, the dashboard the Chief Executive Officer (CEO) will actually open. Data migration is the part nobody photographs for the project newsletter. It is also, by a wide margin, the part most likely to quietly sink the whole transformation.

Industry analysis on data migration projects, cited widely across the consulting sector, suggests that a majority of data migration efforts either fail outright or significantly exceed their planned budget and timeline. Separate research from Oracle and the Bloor Group puts average cost overruns on migration projects at around 30 percent, with schedule slippage averaging 41 percent, and traces a meaningful share of both directly to data problems discovered too late. Gartner estimates that poor data quality costs the average organisation on the order of thirteen million United States Dollars (USD) a year in distorted decisions, failed automation and reconciliation labour, damage that a migration does not create so much as expose all at once.

The most sobering illustration is not hypothetical. The 2010 payroll system implementation for Queensland Health in Australia, built on SAP and Workbrain technology, went live with incomplete data migration: roughly 20,000 unprocessed transactions failed to convert correctly, and historical pay and leave balances did not carry across cleanly. Within weeks, close to 78,000 staff were overpaid, underpaid or not paid at all. The eventual cost of remediation, running for years afterward, is estimated at over AUD 1.2 billion. Nobody set out to build a payroll disaster. They simply treated data migration as a technical afterthought to a project everyone thought was really about the software.

Phase One: Deciding What Actually Moves House

Before anyone touches a single record, the smartest migrations answer a deceptively simple question, one object at a time: for this piece of data, do we migrate it, cleanse it first, or leave it behind in an archive? Customers, vendors, materials, inventory, fixed assets, open purchase orders, open sales orders, bank data, each is its own decision, and treating them all the same way is how migrations get into trouble.

Some objects are non-negotiable and must move in full: active customer and vendor master records, current material masters, open financial and logistics documents the business needs to continue operating from day one. Others are candidates for aggressive cleansing before they travel: duplicate customer records accumulated across two acquisitions, material codes nobody has ordered against in five years, vendor records for suppliers who no longer exist. And a meaningful share of the data an organisation has accumulated over a decade or two does not belong in the operational system at all. It belongs in an archive, available when needed, invisible when not.

This decision, sometimes called an object-level data strategy, is where the discipline pays for itself. Get it right and the cleansing team knows exactly where to focus its limited time. Get it wrong, usually by defaulting to "migrate everything, sort it out later", and the new system inherits every inconsistency the old one quietly tolerated, except the new system, unlike the old one, will not tolerate it quietly.

Phase Two: Finding the Skeletons Before Go-Live Finds Them For You

Every legacy environment has skeletons. Not because anyone was careless, but because data accumulates the way sediment does: quietly, in layers, over years of mergers, system changes, staff turnover and well intentioned workarounds. Data profiling is the exercise of shining a torch into every corner of the legacy system before the move, rather than discovering the skeletons live, in front of users, after go-live.

Profiling asks unglamorous but essential questions of every data object: how many records actually exist, versus how many the business thinks exist? How many are duplicates under a different spelling or a different tax identifier? How many mandatory fields for the new system are blank, inconsistent, or hold a default value nobody meant to keep? How many customer or vendor records have not seen a transaction in years and are, functionally, dead weight? The answers are almost always more alarming than anyone expects, and that is precisely the point of doing it early. A surprise found in profiling, six months before go-live, is a work item. The same surprise found during cutover weekend is a crisis.

Phase Three: Cleansing, Governance and Proving You Did It

Profiling tells you what is wrong. Cleansing is the work of putting it right, and it is where good intentions most often collide with real project pressure. Deduplicating customer and vendor masters, standardising formats, correcting misclassified materials, retiring records that no longer serve a purpose, none of this is difficult in principle. What makes it hard is doing it at scale, on a deadline, without losing track of who changed what, why, and on whose authority.

This is where compliance leaders and internal audit should have a standing seat at the table, not a review meeting near the end. Every cleansing rule applied to financial or master data should be documented, approved by a named business owner, and traceable: which records were touched, what changed, who approved the rule, and when it ran. A cleansing exercise that cannot answer those questions after the fact has created a new governance problem to replace the data problem it solved.

Execution then needs monitoring with the same rigour a finance team would expect of a general ledger close: a dashboard, not a spreadsheet passed around by email, tracking cleansing progress by object, exceptions requiring manual judgement, and a clear owner for every outstanding item. Nothing kills a migration timeline quite like a data issue nobody owns.

Phase Four: Reconciling the Transactions Everyone Would Rather Not Look At

Master data gets most of the attention because it is visible and relatively easy to profile. Transactional data reconciliation is where migrations quietly get harder, and where the auditor's interest sharpens considerably. Every open item carried from the legacy source system into the new one needs to reconcile, balance for balance, before and after the move: customer receivables, vendor payables, inventory quantities and values, open purchase orders, Goods Receipt and Invoice Receipt (GR/IR) clearing accounts, fixed asset registers against the physical estate.

This is unglamorous work, and it is also where years of accumulated small inconsistencies tend to surface all at once: an aged purchase order nobody closed, a GR/IR balance that has not moved in three years, an inventory count that has quietly diverged from the system of record. A migration forces a decision on every one of these, because unlike the legacy system, the new one will not simply carry a mismatch forward indefinitely. Best-in-class programmes treat this reconciliation as its own workstream, with sign-off from the finance and internal audit functions that will ultimately certify the numbers, not as a line item buried inside the technical cutover plan.

Phase Five: Rehearsing the Move, More Than Once

Nobody moves house by trying it once and hoping. Serious migrations run mock cycles, full rehearsals of the data conversion using the real mapping and transformation rules, well before the actual weekend it matters. Consistent with SAP Activate and established data migration practice, that typically means at least two full mock cycles, often three, followed by a dress rehearsal that mirrors cutover as closely as the team can make it, timing included.

Each mock cycle exists to answer the same question with increasing confidence: if we did this for real right now, what would break? The first mock nearly always surfaces a long list, mapping errors, sequencing problems, objects that take far longer to load than anyone estimated. That is a feature, not a failure; it is precisely why the mock exists. What should worry a steering committee is a mock cycle that finds nothing wrong, or a defect list from mock one that is still open going into mock two. Research on migration programmes consistently finds that projects investing 30 to 40 percent of their timeline in testing succeed at markedly higher rates than those that treat testing as a formality squeezed in before go-live.

The Golden Thread: Compliance and Auditability, Start to Finish

Everything above has compliance woven through it, deliberately, rather than as a final gate before go-live. For an audit committee or a regulator, the questions that matter are consistent throughout the programme: who decided what data would move, cleanse or archive, and on what basis? What evidence exists that cleansing rules were approved, applied consistently, and did not alter figures without authorisation? Was segregation of duties maintained inside the migration tooling itself, so the person cleansing vendor bank details is not the same person approving the reconciliation? Can every migrated balance be traced back to its source, with a clear explanation for any adjustment made along the way?

Well run programmes answer these questions by building the audit trail as a by-product of the work, not a separate exercise. Migration tools that log every transformation rule and its approver. A reconciliation pack, retained as a formal record, that shows opening balance, migrated balance and any adjustment, object by object. A sign-off structure that mirrors the organisation's existing delegation of authority rather than inventing a parallel one for the project. Done this way, the migration leaves behind something an external auditor can actually rely on for the first post-go-live audit, rather than a folder of emails and a shrug.

This discipline should not stop at go-live. The same rigour needs to extend into how the business operates afterward: who can touch master data in the new system, what changes require approval, and how exceptions are reviewed. A migration executed with compliance in mind and followed by loose data governance in year one has simply postponed the same risk by twelve months.

The Question Everyone Asks Eventually: What About the History?

Sooner or later, someone in the room, usually finance, sometimes supply chain, asks the question this entire exercise has been building toward: we cannot possibly need ten years of transactional history sitting inside our live operational system, so what happens to it? The honest answer is that it should not sit there. A new S/4HANA environment loaded with every invoice, delivery and stock movement since the company's founding is not thorough, it is slow, expensive to run, and harder to keep clean. But the history cannot simply be deleted either. Tax authorities, regulators and internal audit all have legitimate, sometimes lengthy, retention requirements, and the business itself often has real analytical use for that history.

The answer is a deliberate archival strategy, not a filing cabinet in the basement. SAP's Information Lifecycle Management capability, and equivalent third-party archiving tools, allow an organisation to move aged data out of the live database into a structured, compliant archive, while retaining the ability to retrieve and display it on demand, whether that demand comes from an auditor, a tax inspector, or a planning analyst. Retention periods can be set object by object, aligned to the statutory and internal policy requirements that actually apply, rather than a single blanket rule applied out of caution.

Archiving well also means the history stays useful, not just retrievable. A demand planner forecasting next year's requirement for a slow-moving spare part benefits enormously from five years of consumption history, even if that history technically lives in an archive rather than the live transaction tables. The best archival designs build a deliberate path for that data back into planning, analytics and reporting tools, so "archived" means efficiently stored and readily usable, not effectively lost.

The Moving-House Checklist

How Newen Helps

Newen treats data migration as a core discipline of SAP-driven transformation, not a technical workstream bolted onto the end of design. We build the object-level data strategy alongside your business process owners so the migrate, cleanse or archive decision for every object is deliberate rather than default. We run profiling and cleansing with the audit trail built in from day one: documented rules, named approvers, and a governance model your internal audit function can rely on, not just review. We design and execute transactional reconciliation as a finance-led workstream, and we plan mock cycles that are genuinely rehearsals, not checkbox exercises squeezed in before cutover. And we design archival strategies that keep your organisation compliant and your history usable, so the data that made the move stays trustworthy long after the boxes are unpacked.

We have applied this discipline on greenfield S/4HANA implementations for Nigerian manufacturing and consumer goods groups, reconciling years of open purchase orders, aged GR/IR balances and legacy inventory positions well before cutover, and building the enablement and governance structures that keep the data clean long after go-live.

Sources: Dajon Data Management, "Is Poor Data Quality the Real Reason Migration Projects Fail?" (2026), citing Gartner and Oracle / Bloor Group research on migration cost and schedule overruns; IBM Institute for Business Value, "The True Cost of Poor Data Quality" (2026), citing Forrester research on annual losses from poor data quality; Wikipedia and Henrico Dolfing case study archive, "2010 Queensland Health Payroll System Implementation", on data migration failure and remediation cost; SAP, "Information Lifecycle Management" product documentation, on data archiving, retention and retrieval; SAP Activate methodology and SAP Community guidance on data migration mock cycles; Newen delivery experience across anonymised client engagements in Nigerian manufacturing and consumer goods (2020-2026).