Written by Zhang — Paddy & Water Inc. / Data & Analytics

Data Migration Complete Guide

A Practical Approach to Reducing Risk and Ensuring Success

June 2026

Introduction: Data Migration — The "Minefield" of a Project

When asked what causes SAP S/4HANA implementation projects to fall victim to unexpected schedule delays and cost overruns, experienced project managers almost invariably answer: "data migration." Requirements have been defined, design is complete, development is finished — so why does the project still fall behind? The answer is simple: "Data quality turned out to be far worse than expected, and migration took three times longer than planned."

Data migration tends to be dismissed as a minor, unglamorous task. In reality, however, thirty years’ worth of operational data conceals countless quality problems that are "obviously wrong" to anyone who looks closely. Part number codes mix half-width and full-width characters. The same customer appears in the customer master under twenty different notations. Book inventory balances diverge from actual physical stock by 200 million yen. Discovering and correcting these problems is not something a system can do; it requires human judgment, and that is what takes time.

This guide explains the entire data migration process for an SAP S/4HANA implementation, using a practical approach designed to "reduce risk and lead to success." Positioning data migration not as mere "task work" but as a "core project strategy" is nothing less than the first step toward success.

Chapter 1 The Big Picture of Data Migration: Five Phases and Understanding What to Migrate

1-1 The Five Phases of Data Migration

Migration to SAP S/4HANA broadly consists of the following five phases. These phases should not be treated as strictly sequential steps but managed as ongoing activities that run in parallel with the project as a whole.

Phase	Key Tasks	Deliverables	Timing
① Data Inventory	Gain an overall understanding of data to be migrated and prioritize it	List of migration targets, volume estimates	Concept through requirements definition
② Data Cleansing	Identify and correct quality issues in legacy system data	List of cleansing rules, correction records	In parallel with design through development
③ Migration Program Development	Develop ETL (Extract, Transform, Load) tools	Migration programs, mapping definition documents	Development phase
④ Rehearsal (Mock)	Dry run simulating the production cutover	Rehearsal report, issue list	Test phase
⑤ Production Cutover	Final data migration to the production environment	Migration completion report	Immediately before cutover

1-2 Classifying Data to Be Migrated: Grasping "What to Move"

In an SAP S/4HANA migration, the data to be migrated is broadly classified into three categories: "master data," "transaction data," and "balance data." Because each category differs in difficulty, volume, and cleansing effort, classifying and quantifying them early on is essential.

Data Category	Representative Examples	Migration Difficulty	Special Notes
Master Data	Customer/supplier master, item master, BOM, chart of accounts	★★★ (High)	Many duplicates and notation inconsistencies; cleansing effort is substantial
Transactions (Open/Incomplete)	Open sales orders, open production orders, open purchase orders	★★★ (High)	Difficult to ensure consistency across multiple tables
Balance Data	Inventory balances, accounts receivable/payable balances, fixed asset balances, WIP	★★ (Medium)	Verifying monetary consistency (report reconciliation) is essential
Historical Data	Past sales order history, journal entry history	★ (Low)	Deciding whether or not to migrate this data at all must come first

Consultant’s Perspective

The scope of historical data migration requires a decision on "how many years’ worth to migrate." Attempting to migrate the entire history causes the timeline and cost to balloon. In most cases, a realistic approach is to migrate only the minimum legally required retention period (in Japan, generally seven years) and keep the legacy system running in parallel for a defined period for reference purposes.

Chapter 2 Data Cleansing: Clearing "Invisible Mines" in Advance

2-1 Why Is Data Quality So Poor? Thirty Years of "Accumulated Compromises"

Many clients are surprised at just how poor their data quality turns out to be. Yet on reflection, this is only natural. Many legacy systems were designed with a philosophy of "as long as something can be entered, that’s fine," resulting in lax input validation. Every time the person in charge changed, the input style changed with them; each department developed its own "unwritten rules," and these have accumulated over years, even decades. An ERP implementation is also an opportunity to sort out this accumulation of compromises.

2-2 Typical Data Quality Problems and How to Address Them

Problem Category	Specific Example	Approach to Resolution
Duplicate Data	The same customer, "ABC Corporation," "ABC Corp.," and "ABC Co., Ltd.," exists under separate codes	Define matching/deduplication rules and consolidate into a single code
Notation Inconsistencies	Item names such as "Stainless Steel Bolt M6," "SUS Bolt M-6," and "M6 SUS Bolt"	Establish a naming convention and batch-replace
Missing Values	"Procurement category" and "MRP type" fields left unset in the item master	Consult with the business department to determine default values
Referential Integrity Errors	Item codes referenced by sales order data do not exist in the item master	Process the sales order data at the business level before migration (or add the missing code)
Digit Overflow	Legacy system uses 20-digit item codes, while SAP allows a maximum of 18 digits	Redesign the code structure and create a conversion table
Differences in Numeric Precision	Legacy system manages unit prices as 4-digit integers, while SAP manages them to two decimal places	Confirm the conversion rule with the business (rounding vs. truncation)

2-3 Organizing the Cleansing Effort: Engaging the Business Departments

Data cleansing cannot be completed by the IT department alone. Only the business department can judge whether a given piece of data is correct. However, since the business department already carries its regular workload, simply imposing cleansing work on them as "extra work" will generate resistance.

An effective approach is to establish a "data steward" system. One data quality owner (a data steward) is assigned to each business area (customer management, item management, supplier management, etc.), and that steward is given final authority over cleansing decisions. IT provides the tools and analysis, while the business makes the judgment calls — clarifying this division of roles is essential to driving the cleansing effort forward.

Practical Points for Driving Cleansing Forward

① Set the "cleansing rate" as a KPI and monitor it weekly (e.g., item master cleansing completion rate: currently 65% → target 100%)

② Perform corrections in Excel and load them into the system using automated tools (manual direct entry lowers quality)

③ Keep a record of "who corrected what, when, and under which rule" (essential for audit response and handover to later stages)

④ For "data that cannot be corrected," have management decide early whether to discard it or enter it manually

Chapter 3 Developing the Migration Program (ETL): Precisely Defining "Conversion Rules"

3-1 What Is ETL?

ETL (Extract / Transform / Load) refers to the sequence of processes that "extracts" data from the legacy system, "transforms" it into the SAP S/4HANA data format, and "loads" it into SAP. The essence of a data migration program lies in the design and development of this ETL process.

3-2 Migration Mapping Definition Document: The "Blueprint" for ETL Design

The starting point for ETL development is creating the "migration mapping definition document." This document defines which field in the legacy system corresponds to which field in SAP, and under what conversion rule, and it is created jointly by business consultants and IT.

Definition Item	Content	Example Entry
Source	Table name and field name in the legacy system	OLD_CUST.CUST_CODE (10-digit customer code)
Target	Table name and field name in SAP	KNA1-KUNNR (10-digit customer code)
Conversion Rule	Data conversion logic	Legacy code (numeric) → converted to "C" + [legacy code]
Required/Optional	Whether a blank value is permitted	Required (if blank, excluded as a migration error)
Default Value	Default used when the legacy system has no value	Country code: set to "JP" if not present in the legacy system
Notes	Business considerations / items still under confirmation	Handling of discontinued codes needs confirmation with the business department (pending)

3-3 Choosing a Migration Tool: LSMW vs BAPI vs LTMC vs Third-Party Tools

There are multiple ways to load data into SAP S/4HANA. The choice of tool should be based on data type, volume, complexity, and schedule.

Tool	Overview	Suitable Data	Points to Note
LTMC (Legacy Transfer Migration Cockpit)	SAP’s standard migration tool; loads data by populating Excel-based templates	Master data (items, customers, suppliers)	Performance has limits with very large data volumes
BAPI (Business API)	Loads data programmatically through SAP’s standard business logic	Transactions such as sales orders and production orders	Validation is strict because the data passes through business logic
LSMW	A legacy tool that converts data directly from the legacy system’s format into SAP	Master data (BOM, routings)	Scheduled to be phased out under SAP S/4HANA
Third-Party Tools (e.g., Winshuttle/Precisely)	Feature-rich migration tools well-suited to large data volumes and parallel processing	Large-volume master data, complex transactions	Additional licensing costs apply

Consultant’s Perspective

There have been cases where LTMC was used in a situation that called for BAPI, resulting in data being "loaded in an inconsistent state, having bypassed SAP’s standard validation." Tool selection should be judged not by "speed" but by whether the data correctly passes through the proper business logic.

Chapter 4 Migration Rehearsal (Mock Cutover): "Experiencing Production Before Production"

4-1 The Essential Purpose of Rehearsal

A migration rehearsal (mock cutover) is an activity in which the migration is "performed in advance," using the same procedures and the same data (or a recent copy of the legacy system data) as the actual production cutover, in an environment identical to production. This rehearsal is undervalued in many projects, but experienced project managers insist that "discovering problems for the first time during the actual production cutover is unacceptable."

The following points should be verified through the rehearsal.

Five Points to Verify in Rehearsal

① Whether the migration program completes within the allotted time using a "production-scale data volume" (performance verification)

② Whether the "handover timing" between steps and the time required for "manual tasks" match the estimates

③ Whether all post-migration consistency checks (balance reconciliation, record count reconciliation) pass

④ Whether the "error handling procedure" functions correctly when a migration error occurs

⑤ Whether execution can proceed exactly as written in the cutover procedure document (RunBook) — in other words, "verifying the quality of the procedure document itself"

4-2 Conduct the Rehearsal at Least Three Times

Do not assume that a single rehearsal is sufficient. The first rehearsal will inevitably surface unexpected problems. The second rehearsal confirms that those problems have been fixed, and the third (the final rehearsal immediately before cutover) carries out a dry run under "the same conditions, the same staff, and the same time window" as production. Proceeding to the actual cutover without this cycle is equivalent to going into production with no experience whatsoever.

Rehearsal Round	Purpose	Data	Pass Criteria
1st Mock	Confirm that the migration program works and surface major issues	Data as of the end of the design phase (low quality)	Being able to identify and classify errors
2nd Mock	Re-verify the corrected program and confirm the timeline	Data as of the end of the test phase (medium quality)	Completion within the timeline; error rate of 5% or less
3rd Round (Dress Rehearsal)	Final confirmation equivalent to production	Most recent legacy system data (high quality)	All consistency checks pass; timeline met

4-3 Refining the Cutover RunBook (Procedure Document)

The procedures for the production cutover are documented as a "RunBook." A RunBook is an execution procedure document that specifies, down to the minute, who does what, when, and by what procedure. It serves as the shared "script" used by all stakeholders on the day of cutover.

Mandatory Items for the RunBook

① Overall cutover schedule (timeline from start to completion)

② Owner, duration, and dependencies for each task

③ Timing of legacy system shutdown and the announcement text for users

④ Execution order of migration programs, execution commands, and how to confirm completion

⑤ List of consistency check items and their pass criteria (numerical values)

⑥ Criteria and responsible decision-makers for the Go/No-Go decision

⑦ Rollback procedure (steps for restarting the legacy system in case of emergency)

Chapter 5 Production Cutover: Preparing to Win the "One-Shot" Event

5-1 Designing the Cutover Weekend

Many SAP S/4HANA implementation projects schedule the production cutover for a weekend (Friday night through Monday morning). This is intended to minimize the impact of the business shutdown, but it also means facing the pressure of having to complete the entire migration within the 48 to 72 hours of a weekend. Under this pressure, the performance of a "prepared" team and an "unprepared" team differs fundamentally.

5-2 Go and No-Go Signals: Agreeing on Withdrawal Criteria in Advance

Before undertaking the production cutover, the criteria for deciding whether to "proceed (Go)" or "turn back (No-Go)" must be agreed with management in advance. Neglecting this means that, if a problem arises during cutover, the decision on whether to continue or stop devolves into an emotional argument.

Decision Criterion	Go Criteria	No-Go Criteria
Migration Progress	All migration tasks complete within the allotted time plus buffer	A critical task is delayed by two hours or more with no prospect of recovery
Data Consistency	All consistency checks pass (within the allowed error count)	Unresolved discrepancies exist in key balance data
System Operation	All critical business transactions confirmed to operate normally	A business-critical function shows no prospect of recovery within 24 hours of cutover
Support Structure	Vendor support and SI on-call structure are in place	Key technical staff are unavailable, making support uncertain

5-3 The "Initial Stabilization Phase" After Cutover

The first two to four weeks after go-live should be defined as the "initial stabilization phase," and it is essential to establish a dedicated support structure separate from normal operations during this period. Users must carry out their daily work on an unfamiliar system while raising numerous inquiries, encountering errors, and having operational questions. Without robust support during this period, frontline frustration can, before anyone realizes it, turn into the label "SAP doesn’t work."

Recommended Structure for the Initial Stabilization Phase

① Assign a super user in each department to respond immediately to on-the-ground inquiries

② Set up a hotline to the SI’s and SAP’s support desks (share the phone number with all users)

③ Monitor daily and weekly incident counts, and declare stabilization once a "downward trend" is confirmed

④ Have a dedicated team address remaining data migration issues (post-migration issues)

⑤ Hold a lessons-learned review meeting within 30 days of go-live

Chapter 6 Data Migration Risk Management: Getting Ahead of "What Could Happen"

6-1 The Overall Picture of Data Migration Risk

Risk Category	Specific Risk	Impact	Likelihood	Countermeasure
Data Quality	Cleansing completion is delayed and data never reaches a migratable state	High	High	Manage cleansing KPIs weekly; set escalation criteria to management
Performance	The migration program does not complete within the cutover window	High	Medium	Measure the timeline during the first rehearsal; speed up via parallelization
Consistency Errors	Post-migration balances/record counts do not match the legacy system	High	Medium	Develop consistency-check programs in advance; define acceptance criteria
Inability to Roll Back	Cannot revert to the legacy system if a problem occurs	High	Low	Document the rollback procedure and validate it during rehearsal
Master Data Dependency Errors	Referenced data does not exist due to an incorrect migration sequence	Medium	Medium	Clearly define the migration sequence (dependencies) at the design stage
Organizational Resistance	The business department does not cooperate with cleansing work	Medium	High	Secure a top-down commitment statement from the executive sponsor

6-2 Reporting to Management: Making Risk "Visible"

Reporting data migration risk to management only after it has materialized is too late. It is recommended that a "data migration status dashboard" be created from the start of the project and reported to management weekly. The dashboard should present objective indicators such as the "cleansing completion rate," the "number of unresolved issues," and the "rehearsal pass rate," so that management can grasp at a glance exactly where the data migration effort currently stands.

Building a relationship with management in which problems can be discussed before they occur — rather than only after the fact — is nothing less than the single most important non-technical factor in ultimately leading a data migration project to success.

End