Should you migrate the entire history from legacy software?
Not necessarily. Ten years of data can represent a large volume even when much of it is rarely consulted. Current operational data, information needed for traceability or retention obligations, and data that can remain in an archive should be distinguished.
A common strategy is to migrate complete reference data and the latest useful years of activity, while keeping older history in a read-only archive. The choice must fit the business context, since accounting, quality, healthcare, and industry may have different retention requirements.
Making this decision before development can significantly reduce the transformations, checks, and tests required during migration.
How do you match data between legacy and new software?
Data mapping defines the correspondence between source fields and target fields. For example: `client_name → company_name`, `status = 3 → status = "approved"`, or `customer_id → relationship with the new customer record`.
Some mappings are direct, while others require transformation. A legacy application may store a full name in one field while the new one separates first and last name, use old business codes, or represent several states with one value.
These rules must be documented before loading. They make it possible to build reproducible scripts instead of manually correcting the same data after every migration test.
How should data be cleansed and deduplicated before migration?
Migration is often the best time to stop carrying historical problems forward. Cleansing can address duplicates, missing values, invalid characters, inconsistent formats, old references, incorrect email addresses, or obsolete relationships.
Deduplication must remain cautious. Two companies with nearly the same name are not necessarily the same customer. Rules can combine criteria such as tax identifier, email, historical ID, and address, while ambiguous cases go through human validation.
The goal is not to make every record artificially perfect before migration, but to determine the level of quality required for the new system to operate without inheriting the most costly errors.
How do you migrate data from spreadsheets, ERP, CRM, or legacy business software?
Excel and CSV files are usually easy to extract but may contain implicit logic through colors, formulas, tabs, or columns used differently by each team. Their usage must be understood before treating every column as clean data.
An ERP or CRM migration usually involves more relationships: customers, orders, invoices, order lines, products, users, and history must remain connected. Depending on the product, extraction can use an API, native export, or database access.
For custom legacy business software, its data model may need to be analyzed directly. The goal remains the same: extract cleanly → transform using known rules → load into the target → check the result.
How should data takeover be tested before final migration?
We favor several dry-run migrations, meaning imports performed before final cutover with a representative copy of the data. They reveal incorrect transformations, rejected data, and processing times.
After each load, reconciliation compares source and target: customer counts, amounts, documents, relationships, statuses, and other business indicators. The check must not only confirm that 50,000 rows were imported, but that the right 50,000 rows were imported correctly.
Business acceptance then completes automated checks: users test known real-world records before approving final migration. This avoids discovering after go-live that essential history was not transferred.
How do you migrate data without interrupting operations?
Cutover is the point at which the legacy system stops being the active source and the new system takes over. It must be planned around data volume, import duration, and the amount of new information likely to be created during migration.
Depending on the context, the legacy system may temporarily become read-only, a final differential extraction may capture only recent changes, and the new software then becomes the source of truth once checks are complete.
A rollback plan defines what happens when final migration fails: how long the legacy system can be restored, which data must be recovered, and which operations must be replayed. A critical migration should not rely on one attempt without a fallback scenario.
How do you check that no data was lost during migration?
Validation combines quantitative, relational, and business checks. Comparing only total row counts is not enough: amounts, object relationships, attachments, statuses, dates, and user-defined critical data must also be checked.
Scripts can automatically produce discrepancy reports covering source and target record counts, rejected items, orphan relationships, checksums, or differences in sensitive fields.
Migration is complete only after criteria defined in advance have been approved. This acceptance and control logic is used in real information-system change projects: extraction, pilot migration, quantitative and qualitative checks, corrections, then final migration.
How do you secure data during a takeover?
Production data must not circulate freely between computers, email, or test environments. The project must define who may access exports, how they are stored and encrypted, how long they are retained, and how they are deleted after migration.
When data includes personal information, the GDPR still applies during migration. Changing software does not authorize unlimited copies or indefinite retention of intermediate exports.
Sensitive data may also create additional sector-specific constraints. Migration architecture should match the required confidentiality level instead of automatically duplicating the production database into an uncontrolled environment.
How much does data takeover or migration cost?
Cost depends less on the raw number of rows than on their heterogeneity and the number of rules required to interpret them. One million perfectly structured rows can be easier to migrate than 20 spreadsheets containing different business rules.
Main factors include the number of sources, data quality, relationships to preserve, associated documents, history to migrate, required transformations, security constraints, and the number of dry runs.
At Koragence, a simple takeover from a few structured files can be included in a software project. A standalone project involving several systems, cleansing, transformation scripts, testing, and cutover should be scoped separately after reviewing the available data.
How does Koragence carry out a data takeover?
We begin by inventorying sources and defining the data actually required in the new system. Mapping is then validated with business experts so transformations and cleansing rules are documented before scripts are developed.
We then run one or more dry-run migrations, produce integrity checks, and correct discrepancies. Users can carry out acceptance testing on real data before final cutover.
The process follows a verifiable chain: inventory → mapping → cleansing → transformation → test migration → reconciliation → acceptance → cutover → final check → legacy system archiving.
Good is Merch
Onctuo