The Data Problem That Surfaces at the End of the Project
In a system replacement project, data migration tends to slip behind screens and features. Real data gets loaded only as integration testing winds down, and the quality issues all show up together a few weeks before go-live.
A system that has run for close to 20 years typically holds data like this:
Such records either fail the new system's mandatory and format checks at load time, or load successfully and become the reason balances do not match on day one.
Start With Scope: What Moves and What Stays
Trying to move everything costs you both schedule and quality. It helps to sort the data into three groups.
Statutory retention periods matter when you leave history behind. Under Korean law, the Commercial Act requires commercial books and important business documents to be kept for 10 years (5 years for slips and vouchers), the Framework Act on National Taxes requires books and supporting documents for 5 years, and the Labor Standards Act requires key records such as the employee register for 3 years. Data you do not migrate must stay retrievable for that long, so decide at the same time whether to keep the old system read-only or move the history into a separate query database.
The Mapping Specification and Cleansing Rules
The mapping specification records which legacy table and column feeds which target field, and under what rule. Beyond field mapping, it should cover code mapping (for example, 17 legacy payment-term codes collapsing into 6), default values, and what happens to data that cannot be converted.
Many cleansing decisions are not the development team's to make.
Assign these decisions to the business, assign writing and running the conversion programs to the vendor, and record an owner and due date for each item in the specification.
Validation: Why Matching Record Counts Is Not Enough
Matching counts is only the starting point. If 12,000 partner records become 9,400 after merging 1,900 duplicates and dropping 700 obsolete ones, the counts are supposed to differ. The check is whether "source count = migrated count + excluded count by reason" holds.
Build validation in three layers.
Close validation with a sign-off by the heads of the business departments. A clear signatory reduces disputes over numbers after go-live.
Migration Rehearsals and the Cutover Plan
Run at least two or three rehearsals. The first reveals the error types, the second measures the fixes and the elapsed time, and the third follows the same sequence and staffing as the real cutover. This is how timings get fixed: a job that takes 14 hours in the first rehearsal might come down to 6 hours by the third after index tuning and parallel loading.
The cutover plan should include:
What the Client Should Confirm at Contract Stage
Most migration disputes start from a vague scope of work. The RFP and contract should state:
How POLYGLOTSOFT Supports Data Migration
POLYGLOTSOFT begins by profiling legacy data to quantify its quality, then carries the work through mapping specifications, conversion program development, automated reconciliation reports, and migration rehearsals. If data migration is a concern ahead of a system replacement or an ERP, MES, or WMS transition, contact POLYGLOTSOFT. We will start with an assessment of your current data.