Why a Data Migration Is Never Just Moving Data

Someone usually says it in a meeting: "we'll just export the data and import it into the new system." It sounds like an afternoon's work. In practice, it's often the part of a project that takes the longest and causes the most last-minute panic, because the data rarely lines up as neatly as everyone assumed.

I've done enough of these, moving customer records between CRMs, pulling years of bookings out of a system being retired, merging two databases after a business acquisition, to know the export and import are the easy bits. Everything in between is where the real work sits.

What "just move the data" skips over

The old system and the new one almost never store things the same way. A field called "status" in one system might be a single dropdown value. In the other, it's split into two fields: a stage and a sub-stage. Dates might be stored differently, customer names might be one field in the old system and first name plus last name in the new one, and addresses are a classic mess, one text box in the old system versus structured fields in the new.

Then there's the data itself. Years of manual entry mean duplicate customers under slightly different spellings, phone numbers with and without the area code, records with missing fields that the old system never enforced, and the odd row that's clearly a test entry someone forgot to delete in 2019. None of that shows up until you actually try to load it somewhere stricter.

Relationships are the other trap. An order links to a customer, which links to an address, which links to a sales rep who might no longer exist in the new system. If you move the orders before the customers, or don't preserve the IDs that tie them together, you end up with orders that technically imported but point at nothing. This is the kind of problem that looks fine in a demo and only surfaces three weeks later when someone searches for a customer's order history and finds a gap.

The questions that actually shape the plan

Before I write a single line of migration script, I want answers to a few things:

• How much downtime is acceptable? A clean cutover at midnight on a Friday is very different from a system that has to keep running while data moves across gradually.
• Do you need full history, or just the current state? Carrying ten years of archived records across is a different job to migrating active customers and this quarter's bookings.
• What happens to records that don't fit? Every real dataset has exceptions. Deciding upfront whether they get fixed, flagged, or left behind matters more than it sounds.
• Who signs off that the migration worked? Not "it ran without an error message", but someone on your side checking that the numbers and the records actually match what they expect to see.

These questions matter because they change the approach entirely. A one-off cutover with a maintenance window is a very different piece of work to a live migration that has to run alongside the old system for weeks while both stay in sync.

Testing it before it's real

I always run a migration against a copy of the live data first, not a handful of sample records someone picked because they looked tidy. Real data has the duplicates, the blank fields and the weird edge cases baked in, and that's exactly what needs testing against.

After a trial run, I check record counts match, spot-check a sample of records by hand against the source system, and specifically look for the things that are easy to get wrong silently: totals that should add up, relationships that should still link, dates that haven't shifted by a timezone. A migration that "completes" without errors isn't the same as one that's actually correct. Software can run perfectly and still move the wrong data in the right shape.

The cutover and the way back

However careful the planning, I want a way to undo it. That might mean keeping the old system accessible and read-only for a period after cutover, or taking a full backup of both systems immediately before the switch. If something's wrong on day one and you can't see what the data looked like beforehand, you're stuck trying to reconstruct it from memory, which never ends well.

This is also where I lean on experience rather than a checklist. Having done this kind of work before means I've already seen the ways it breaks, and I'd rather catch them in a test run on a Tuesday than in a support call the following Monday. If you're weighing up whether to migrate data yourself, hand it to whoever's building your new system, or bring someone in specifically for the move, it's worth reading more about how systems integration work actually gets scoped, since migration is usually part of a bigger integration job rather than a standalone task.

If this is happening alongside a wider decision about whether to replace an old system entirely or keep parts of it running, that's a slightly different conversation, and one I've written about separately when it comes to deciding what to do with ageing software rather than just moving its data somewhere newer.

None of this is meant to make a migration sound frightening. It's a well-understood piece of work with a well-understood set of risks. But "export and import" undersells it badly, and a quote or timeline based on that assumption is one worth questioning before you commit to a cutover date.