Ask any SAP project manager what derailed their last migration, and you will rarely hear “infrastructure failure” or “licensing complexity.” The real answers are vendor master records with duplicates nobody caught, cost centers that existed in ECC but not in the new chart of accounts, and historical data that migrated in full because nobody ever made a decision to archive it.
Across industries, this is the norm. Industry research shows that up to 83% of migration projects fail or exceed their budget, and the root cause is rarely infrastructure, licensing, or even custom code complexity. It is data. Specifically, the underestimation of what it actually takes to move data correctly at enterprise scale, and the absence of the execution discipline that prevents that underestimation from becoming a go-live failure.
This guide provides the technical execution checklist your team needs, from source extraction through cutover, alongside the governance principles that determine whether the data in your new system is a competitive asset or a day-one liability.
Note: If your team is still working through migration strategy selection, deployment model decisions, or the Clean Core imperative, those decisions are covered in depth in Everforth Quinnox’s SAP S/4HANA Migration: The Complete Enterprise Guide. This guide picks up where strategy ends, and execution begins.
Why Data Execution Determines Migration Outcomes
The SAP S/4HANA migration guide makes the strategic case clear: the 2027 maintenance cliff is real, the talent shortage is accelerating, and the cost of waiting compounds. But even organizations that start on time, with the right partner and the right approach, can lose months and millions at the data layer.
Data migration preparation is structurally under resourced, representing less than 10% of total project effort on most plans, despite being responsible for the majority of migration roadblocks. The consequence is predictable: teams discover data quality problems during mock migrations or, worse, during cutover itself, when the cost of remediation is at its highest.
The checklist below is designed to front-load that discovery. Every phase is sequenced to surface problems early, when fixing them is cheap, rather than late, when fixing them stops the go-live clock.
The Execution Checklist: From Source Extraction to Cutover
Step 1: Strategic Extraction and the Data Triage Framework
Before a single record is moved, your team must resolve a question that most project plans skip entirely: what actually needs to migrate?
The answer is almost never “everything.” And treating it as such is the fastest path to an oversized HANA database, inflated licensing costs, and a productive environment slowed down by decades of data nobody uses.
Apply a three-category triage framework at the source:
Migrate (Day 1 Required): Active master data (material masters, customer and vendor records, open purchase orders and sales orders) that is needed for business continuity from the moment users log in. This is the non-negotiable core.
Archive (Compliance-Retained): Historical records spanning 3–8 years that must be retained for SOX, GDPR, GxP, or other regulatory obligations. These records are required for audit, not for operations, and they do not belong in your live HANA environment.
Retire (No Migration): Records with no activity in the past 24 months, discontinued SKUs, and closed vendor accounts. These should be decommissioned, not carried forward.
The TCO Implication of Getting This Wrong
HANA is an in-memory database, and in-memory computation is expensive. Every historical record that lands in the live system without a business reason inflates the database footprint, drives up licensing costs, and degrades query performance over time.
QArchive addresses this directly by routing cold historical data to compliant, cost-effective long-term storage: accessible for audit, invisible to daily operations. Organizations that apply proper data triage with QArchive consistently reduce the ToC (Total Cost of Ownership) by 30–50% compared to full migration approaches. That reduction compounds with every quarterly upgrade.
Want to quantify the financial impact for your organization?
The SAP S/4HANA ROI Calculator models IT run cost savings, inventory reduction, finance productivity gains, and risk avoidance value across a five-year horizon — so you can take a defensible business case to your board before committing to a migration timeline.
Checklist Items:
- Document and map all source systems including legacy CRMs, PLMs, and third-party WMS environments
- Apply the Migrate / Archive / Retire framework to all data domains
- Define the archiving boundary: what years constitute “cold” data for your regulatory context?
- Assign named Business Data Owners in Finance, Supply Chain, and Sales to sign off on triage decisions before extraction begins
Step 2: Technical Data Cleansing and Governance
Once the scope is defined, the cleansing work begins. Budget 30–50% of your total migration timeline for this phase. If that number feels high, it reflects the true complexity, not a conservative estimate.
The 7 Quality Pillars
Every data domain should be audited against seven quality dimensions before any transformation logic is applied:
| Dimension | What It Tests |
|---|---|
| Accuracy | Does the value reflect the real-world entity it represents? |
| Completeness | Are all required fields populated? |
| Conformance | Does the data match the format S/4HANA expects? |
| Consistency | Do related records agree across source systems? |
| Timeliness | Is the record current enough to be operationally relevant? |
| Uniqueness | Does this entity exist exactly once in the source? |
| Validity | Does the value fall within the expected domain or range? |
Deficiencies against any of these dimensions become migration defects if they are not resolved before load, and production incidents if they reach the go-live environment unchecked.
The Business Partner Conversion Challenge
One of the most technically demanding cleansing tasks in any ECC-to-S/4HANA migration is the Business Partner (BP) conversion. ECC maintains customers and vendors as separate entities, whereas S/4HANA requires them to be unified into a single BP model.
In practice, this means reconciling records that were created independently, resolving conflicting identity fields, deduplicating semantic duplicates where the same real-world entity appears as separate customer and vendor records, and ensuring that the merged BP record correctly inherits all relevant transaction history.
This is not a technical mapping problem but a data governance problem that requires domain knowledge and business sign-off. Automating it without that sign-off creates new problems faster than it solves old ones.
Standardizing Global Transformation Rules
Units of measure, currency codes, and tax identifiers must be normalized to global formats before load. Inconsistencies here are invisible until they create incorrect financial postings or break cross-border supply chain visibility post-go-live.
Checklist Items:
- Benchmark all source data against the 7 Quality Pillars and document deficiency rates by domain
- Initiate Business Partner conversion analysis: identify all semantic duplicates and conflicting identity fields
- Document and version-control all transformation rules; these become audit evidence for SOX 404 compliance
- Standardize UoM, currency, and tax identifier formats globally before any load begins
The Governance Firewall
Cleansing data once is not enough if the governance model allows it to degrade again after go-live. QMDG (Everforth Quinnox Master Data Governance) acts as a continuous governance firewall: automating validation rules, enforcing deduplication at the point of creation, and distributing clean master data consistently across the enterprise. The system that goes live with clean data stays clean because the governance layer prevents the “dirty data cycle” from restarting on Day 2.
Step 3: Dependency-Aware Load Sequencing
Load order is not an implementation detail but the structural integrity of your migration. Breaking the sequence results in orphaned records, broken foreign keys, and financial postings that cannot be reconciled, any of which can halt reporting workflows on Day 1.
The Golden Sequence
Execute technical loads in this precise order:
1. Stable Reference Objects: Chart of Accounts and Material Masters. These are the anchor structures that every downstream record references.
2. Entity Master Data: Business Partners (Customers and Vendors). These must exist before any transactional data can be referenced.
3. Transactional Data: Open Purchase Orders and Sales Orders. These references both master data and account structures.
4. Financial Balances: Opening General Ledger balances. These must reconcile the penny against legacy closing balances before the go-live clock starts.
Each layer creates the referential foundation the next layer depends on. Loading out of sequence means child records arrive before parent records exist, a condition that breaks referential integrity at the database level and produces errors that are expensive to unwind.
Referential Integrity Verification
Before the productive load begins, every child record (line item) must have a verified parent record (header). This check should be automated, not manual, and it should run in the mock migration environment before it runs in production.
Checklist Items:
- Map the complete referential dependency chain for all migration objects
- Execute loads in the Golden Sequence without exception
- Run automated referential integrity checks after each load layer in mock environments
- Reconcile opening GL balances to legacy closing balances before go-live sign-off
Step 4: Iterative Mock Migrations: The Rehearsal Principle
One rehearsal catches more issues than three extra weeks of planning. Two rehearsals catch issues that one would not, because the first mock reveals the problems you knew you had, and the second reveals the ones you did not.
The goal of mock migration is not to demonstrate that the process works but to discover how and where it fails under production conditions before production is the only environment available.
Mock Migration Requirements
Run at least two full mock migrations using a production-mirror environment loaded with 100% of the production data set. Test environments with representative samples miss volume-dependent performance issues, the kind that surface only when you are loading 50 million line items instead of 500,000.
What to Measure in Each Mock
Elapsed Time: Measure the exact duration of each load phase. The entire cutover window is technically constrained to 48 hours. If your mock migrations are running at 36 hours, you have no margin for incident response, and you are heading toward a missed cutover.
Sub-Ledger to GL Reconciliation: After each mock, prove that the sum of AR + AP + Inventory equals the GL trial balance in the target system. This reconciliation must balance before go-live proceeds. Discovering a reconciliation gap during an actual cutover window is one of the most expensive outcomes in migration work.
Performance Benchmarking: Identify load bottlenecks at production data volumes. Hardware configurations that perform adequately in test frequently show degradation patterns at scale that require remediation before go-live.
Checklist Items:
- Conduct minimum two full mock migrations with 100% production data set
- Validate elapsed load time against 48-hour cutover window with adequate buffer
- Reconcile sub-ledger totals (AR + AP + Inventory) to GL trial balance after each mock
- Document all issues found in each mock and confirm resolution before the next rehearsal
Step 5: The Cutover Runbook and Rollback Strategy
A cutover plan without measurable rollback triggers is a hope strategy. The organizations that execute clean cutovers are the ones that defined their “No-Go” conditions as precisely as their “Go” conditions, and then honored them.
The Minute-by-Minute Runbook
Every hour of the cutover window must be accounted for before cutover begins. The runbook should assign named owners to every task, document task durations and dependencies, and include escalation paths for every category of blocking issue.
“We’ll figure it out if something goes wrong” is not a cutover plan. By the time something goes wrong during a live cutover, the pressure is high enough that improvised decisions become costly ones.
Near-Zero Downtime (NZDT) Approach
For organizations where extended system downtime would cause severe business disruption, Near-Zero Downtime migration uses database triggers to capture all data changes made during the “uptime” migration phase. When the final cutover window opens, only the delta changes (the records created or modified since the main load completed) need to be migrated. This compresses the actual downtime window from hours to minutes.
Implementing NZDT correctly requires careful technical preparation during the mock phase, and it is not a switch to flip on cutover day.
Explicit Rollback Triggers
Rollback criteria must be defined in writing before cutover begins. Clear triggers include:
- Hitting a hard stop time without completing critical load phases
- Record count variance exceeding 0.5% between source and target
- Sub-ledger to GL reconciliation failure that cannot be resolved within the window
- Critical integration failure with external systems (Salesforce, Ariba, 3PL platforms)
When a trigger condition is met, the decision to roll back must be automatic, not a matter of debate under pressure.
Checklist Items:
- Build a minute-by-minute cutover runbook with named owners and task dependencies
- Evaluate NZDT feasibility based on business downtime tolerance
- Define explicit, written rollback triggers with Go/No-Go checkpoints
- Repoint and test all external integrations (Salesforce, Ariba, third-party WMS) in the cutover sequence
Compliance and Audit Readiness: The Evidence Package
For publicly traded organizations, an ECC-to-S/4HANA migration is a SOX 404 control change. Auditors will ask for evidence. If the evidence is not produced systematically during the migration, reconstructing it afterward is both time-consuming and incomplete.
The minimum evidence package includes:
Extraction Logs: Documentation of source system IDs, record counts by domain, and extraction timestamps. These establish the chain of custody for every record in the new system.
Transformation Specifications: The rules applied to source data during cleansing and mapping, version-controlled and approved by named Business Data Owners. Auditors need to see that transformation logic was deliberate and signed off, not improvised during load.
Reconciliation Reports: Mathematical proof that opening balances in S/4HANA match legacy closing balances to the cent, with attestation from Finance. This is the document that closes the audit inquiry on financial data integrity.
The discipline of producing this evidence package systematically also enforces the governance behaviors that keep the migration on track. Teams that produce evidence as they go make better decisions than teams that produce it retrospectively.
Post-Go-Live: The First 90 Days Define Long-Term Data Quality
The go-live event is not the finish line for data quality but the beginning of the most vulnerable period.
In the first 90 days, edge cases surface that mock migrations and UAT did not anticipate. Users encounter scenarios where manual workarounds feel faster than the designed process. New records are created by people who were not involved in the cleansing exercise and who may not know the governance rules.
Data quality degrades in the first three months on almost every S/4HANA implementation. The only variable is the rate of degradation, and that rate is controlled by governance.
Continuous Monitoring
Deploy automated quality checks from Day 1 that detect new duplicates before they accumulate transaction history, flag records that fail validation rules at the point of creation, and surface anomalies in master data before they propagate into downstream financial postings.
The Permanent Governance Council
The migration team that built the cleansing rules and transformation logic is the most valuable data governance resource in the organization at go-live. Transitioning that team into a permanent governance council, rather than disbanding it, is the decision that determines whether the Clean Core stays clean.
QMDG provides the ongoing platform for that council: automating the validation and distribution of workflows that keep master data quality high as the business scales, new entities are onboarded, and SAP quarterly updates are absorbed. This is also the infrastructure that makes SAP Joule AI agents effective. They require standardized, governed data models to operate, and a degraded data environment degrades AI outcomes proportionally.
The Data Migration Capability That Changes the Equation
Executing this checklist correctly requires more than a good plan — it requires tooling that automates the repeatable components and expertise that navigates the judgment calls.
Everforth Quinnox’s data migration capability is built on three components that work in concert:
QMDG automates validation, deduplication, and distribution of master data, ensuring governance is enforced from Day 1 rather than retrofitted after the first post-go-live audit finding.
QArchive routes historical cold data to compliant long-term storage, keeping the live HANA environment lean and reducing the database footprint that drives TCO.
SAP testing services provide the automation-first framework that validates data integrity at scale across the migration lifecycle, including the sub-ledger to GL reconciliation and referential integrity checks that manual testing cannot reliably execute at production data volumes.
Together, these capabilities address the three failure modes that most commonly derail data-layer execution: poor governance before go-live, oversized live environments that inflate cost, and insufficient validation coverage that allows defects to reach production.
For organizations that need a broader perspective on data migration strategy, including how to align business priorities, risk tolerance, and sequencing decisions before technical execution begins, Everforth Quinnox’s data migration strategy guide provides the strategic framework this execution checklist operates within.
The Decision That Determines Go-Live Success
Every SAP data migration has a moment of maximum risk: the cutover window, when the system is down, the data is in motion, and any unresolved issue becomes a business-stopping incident.
The teams that navigate that window cleanly are the ones that resolved their data quality problems in Step 2, not Step 5. They ran two full mock migrations, not one. They built a runbook with explicit rollback triggers, not a general plan with good intentions.
The checklist above is a translation of that discipline into executable steps. The question is how much of it your team has the capacity to run with the rigor it requires, and where the right partnership accelerates that execution without replacing the judgment calls that only your organization can make.
If your migration timeline is in view and you want to assess where your data readiness stands today, Everforth Quinnox’s SAP S/4HANA migration and implementation practice is the right starting point. The lowest-risk next step is a structured landscape and data quality assessment, the kind of evidence-based picture that tells you exactly what you are dealing with before the project clock starts.
Not yet at the execution stage? If your leadership is still weighing the urgency of moving off ECC, our whitepaper The Clock Is Ticking: Why Delaying Your SAP S/4HANA Migration Is No Longer an Option makes the case in full, covering the cost of inaction, the narrowing talent window, and the compounding risk that builds with every quarter of delay.
FAQs Related to SAP Data Migration
Because most enterprise data environments carry years of accumulated inconsistencies: duplicate records, missing fields, outdated formats, and referential integrity gaps that were never resolved in ECC because ECC’s architecture tolerated them. S/4HANA’s stricter data models do not. Surface those problems before load, or they become go-live blockers.
ECC maintains customers and vendors as separate master data objects. S/4HANA requires a unified Business Partner model. The conversion requires reconciling records created independently across systems, deduplicating semantic duplicates, and ensuring transaction history is preserved correctly. It is a governance and data quality exercise, not simply a technical mapping.
It is a hard stop. Opening balances in S/4HANA must match legacy closing balances to the cent before financial operations can begin. A reconciliation failure during cutover that cannot be resolved within the window triggers rollback. This is why reconciliation should be proven in mock migrations, not discovered live.
HANA is an in-memory database, and historical data that lives in the live system inflates the memory footprint that drives licensing and infrastructure costs. QArchive moves cold historical data, typically records older than 3–7 years, to compliant, cost-effective long-term storage. The data remains accessible for audit; it simply no longer occupies expensive in-memory compute.
The first mock surfaces the problems you knew existed. The second surfaces the problems the first mock created: sequencing issues resolved in remediation that introduced new dependencies, edge cases in the data that only appeared once volume reached production levels, and elapsed time measurements that only become reliable when the team has run the process at least once. One mock gives you a rehearsal. Two give you a validated plan.
QMDG enforces governance at the point of data creation: validating records against business rules before they enter the system, running duplicate checks automatically, and distributing master data consistently across the enterprise. The governance council that built the migration rules transitions into the team that maintains them, using QMDG as the platform for ongoing enforcement rather than periodic manual audits.
Everforth Quinnox’s SAP practice spans S/4HANA migration and implementation, master data governance, data archiving, SAP testing, and post-migration application management. Explore our SAP services or contact us to discuss your migration readiness.