Data migration is the process of moving structured information from one system to another. In the context of business web applications, this usually means transferring records from a legacy platform, a collection of spreadsheets, or an off-the-shelf product into a new CRM, portal, or internal tool. The act of copying rows sounds straightforward, but the planning behind it determines whether the new system starts with reliable data or inherits problems that undermine the entire investment.
Migration sits at the intersection of three concerns that business owners often treat separately: data quality, system design, and operational risk. The structure of the target system dictates what fields exist and how they relate to each other. The quality of the source data determines how much transformation is needed before anything can be loaded. The operational context decides what happens if something goes wrong during the switch.
| Data decision | Operational consequence | Control or evidence |
|---|---|---|
| The core stages of a migration plan | A sound plan follows a predictable sequence, though the effort at each stage varies enormously depending on the data involved. | Source audit. Catalogue every data store that will feed the new system: databases, spreadsheets, exported CSV files, third-party APIs. |
| When migration becomes a project in its own right | If the source is a single spreadsheet with a few hundred rows and a flat structure, migration planning might take a couple of hours. | If the source is a fifteen-year-old CRM with dozens of linked tables, custom fields added over years, and no documentation, the migration plan can easily become the largest workstream in the entire build. |
| Migrating from spreadsheets to a web application | Spreadsheets are the most common starting point for businesses moving into their first proper web system. | The planning challenge here is usually not volume but structure. |
| Replacing an existing CRM or portal | When migrating from one application to another, the source data is already structured, which helps, but the relationship between tables adds complexity. | A customer record might link to invoices, support tickets, notes, and document attachments. |
The core stages of a migration plan
A sound plan follows a predictable sequence, though the effort at each stage varies enormously depending on the data involved.
- Source audit. Catalogue every data store that will feed the new system: databases, spreadsheets, exported CSV files, third-party APIs. Record the format, approximate volume, and the person responsible for each source.
- Field mapping. For each destination field in the new system, identify where the value will come from. Some map directly, others require splitting, combining, or calculating from multiple source fields.
- Transformation rules. Define how source values will be changed to fit the target. This covers date formats, currency normalisation, status-code translation, and any derived fields.
- Validation criteria. Agree the checks that will confirm the migration succeeded: record counts, checksums, spot checks on individual records, and reconciliation against known totals.
- Runbook and rollback. Document the exact sequence of steps, who executes each one, and what happens if the load fails partway through.
The plan itself is a written document, not a conversation. It should be specific enough that a technically competent person who was not involved in the discussions could execute it and verify the result.
When migration becomes a project in its own right
If the source is a single spreadsheet with a few hundred rows and a flat structure, migration planning might take a couple of hours. If the source is a fifteen-year-old CRM with dozens of linked tables, custom fields added over years, and no documentation, the migration plan can easily become the largest workstream in the entire build. Recognising which end of that spectrum you are on early prevents the mistake of treating migration as a minor task tacked onto the end of development.
Migrating from spreadsheets to a web application
Spreadsheets are the most common starting point for businesses moving into their first proper web system. The planning challenge here is usually not volume but structure. Spreadsheets allow free-form data entry: a column labelled "Address" might contain anything from a full postal address to a postcode alone, or it might be empty. The migration plan needs to specify how each of these variations will be handled, whether invalid rows will be flagged for manual review, and who will carry out that review.
Another frequent issue with spreadsheet sources is the absence of unique identifiers. In a database, every customer has an ID that other records reference. In a spreadsheet, a customer might be identified by name, and that name might be spelled differently across sheets. The plan must address how duplicates will be detected and merged before loading.
Replacing an existing CRM or portal
When migrating from one application to another, the source data is already structured, which helps, but the relationship between tables adds complexity. A customer record might link to invoices, support tickets, notes, and document attachments. If the target system models these relationships differently, the migration plan needs a clear mapping for every entity type, not just the primary records.
Historical data requires a specific decision. Do you migrate every closed ticket from the past seven years, or only open and recent items? The answer affects volume, transformation effort, and the usefulness of the new system from day one. There is no universally correct choice, but there should be a documented decision tied to a business rationale rather than an assumption.
Integrations and live data
If the new system will connect to other live services — an accounting package, a payment processor, a shipping API — the migration plan must account for the timing of the switch. Data flowing through those integrations during the migration window needs to be captured or queued so that nothing is lost. This often means a planned period of reduced activity or a clear cutover procedure agreed with the teams operating the connected systems.
Who does what
Migration planning requires input from people who understand the data's meaning and people who understand the technical mechanics. A sales manager knows that a "closed-lost" status in the old system maps to a specific stage in the new pipeline. A developer knows that the old system stored that status as a free-text field while the new one uses a foreign key to a reference table. Both perspectives are necessary, and the plan should capture the decisions that emerge from that collaboration rather than leaving them implicit.
Assuming the source data is clean
The single most common mistake is treating the source data as accurate simply because it has been used for years. Legacy systems accumulate workarounds: fields repurposed for unintended uses, records entered incompletely because the system did not enforce validation, and duplicate entries created when users could not find an existing record. A migration plan that does not include a data-quality audit will carry these problems into the new system, where they become harder to fix because the business has already moved on from the old tools.
Testing only with small samples
Running a test migration with a hundred records and declaring success is a frequent error. Edge cases — unusual characters in text fields, null values in required columns, records that violate the new system's validation rules — often appear only at volume. The plan should specify a full-volume test run against a staging environment before any cutover is attempted, and it should define what "full volume" means in practice.
No rollback procedure
If the migration fails or produces corrupted data, the business needs a way to return to a known-good state. This might mean restoring the target database from a pre-migration backup, reverting to the old system, or rolling back a specific batch. The plan should document this procedure before the migration begins, not improvised under pressure.
Key questions to put to a supplier
- Will you produce a written migration plan with field-level mapping before any code is written?
- How will you handle records that fail validation during the load?
- What does the test cycle look like, and will it use the full data set?
- Who is responsible for reviewing and approving the migrated data before go-live?
- What is the rollback procedure if the cutover fails?
- How will you verify that record relationships — customer to invoice, user to permission — are intact after migration?
Limitations of planning
A migration plan reduces risk but does not eliminate it. Unexpected data will emerge during execution regardless of how thorough the audit was. The value of the plan is that it creates a structured response to those surprises rather than an ad-hoc one. If a supplier claims that migration is straightforward and does not warrant a separate planning phase, that is a signal to ask more detailed questions rather than accept the reassurance.
Data migration also does not address how long the old data will remain accessible. That question sits alongside retention policy and exit planning, both of which require separate consideration. The migration plan should state where the source data will be stored after the move and who controls access to it, but the decision about how long to keep it involves regulatory and operational factors that go beyond the migration itself.