The Business Data Migration Playbook: How to Move Without Breaking Everything

Every business eventually faces it: a new CRM or ERP is selected, a contract is signed, and then someone asks the question that derails the whole project. "What do we do with all our existing data?" What follows is usually one of two failure modes — a migration that drags on for months while the old system quietly stays active, or a rushed cutover that lands incomplete, inconsistent data in the new system and makes the whole platform look broken on day one.

Neither outcome is inevitable. Data migration is genuinely hard, but it is also one of the most predictable failure points in any software transition. The problems that surface at migration time are almost always the same ones, and the approaches that fix them are well understood. This guide covers what to actually do, in what order, and where most teams go wrong.

The Two Traps to Avoid Before You Start

The first trap is the clean-data-first mentality. Teams decide they need to clean up all their existing data before migrating, and that project immediately becomes an endless one. Edge cases multiply — what do you do with duplicate records where neither version is clearly authoritative? What about inactive customers from seven years ago? Who owns the decision about which of the three competing product catalogues is correct? These are contested organisational questions, not technical ones, and they stall migrations indefinitely. The cleaning project consumes the energy that should have gone into the actual move.

The second trap is parallel running — keeping the old system live while staff gradually transition to the new one. This feels safe but is operationally catastrophic. Within days of a parallel-running start, the two systems begin to diverge. A deal closes in the new CRM but the invoice goes into the old system. A customer's address is updated in one place but not the other. Staff lose confidence in both systems simultaneously. Neither becomes the authoritative record. By the time someone tries to reconcile the two, the data gap is large enough that the reconciliation itself becomes a project.

Decide What Actually Needs to Move

Before touching any export tools, define the scope of the migration precisely. The instinct is to move everything — the entire history of every customer, every order, every interaction going back years. Resist this. Historical data beyond two to three years rarely sees operational use. The sales rep who opens a customer record wants to see the current open deals, the last few invoices, and recent conversations. They do not need the full interaction history from 2019.

For a typical CRM migration, the day-one essentials are:

• Active customers and prospects with current contact details
• Open deals and their current pipeline stage
• Current product and pricing data
• Open invoices and recent payment history (typically 12–24 months)
• Active contracts and renewal dates
• Enough interaction history for ongoing customer conversations (typically 6–12 months)

Everything else can be archived in read-only form in the old system, which can be kept in a view-only state for historical lookups without being actively maintained. This is a much more honest use of the old platform than pretending it is still live.

Appoint a Business Owner — Not an IT Lead

The single most reliable predictor of a successful migration is not the tools used. It is whether a single named person with actual business authority owns the project from start to finish. Not a project manager, not an IT lead, not a consultant — someone who understands the organisation's workflows well enough to make decisions about what data matters, which duplicates take priority, and what "done" actually means.

This person's job is to answer the contested questions that technical teams cannot resolve on their own. When there are three versions of a customer record and no clear primary, they decide. When the sales team wants to preserve five years of call notes and it would add three months to the timeline, they make the call. Without this person, migration projects stall on exactly these decisions, and they stall for months.

Audit Before You Export

Before running a single export, do a quality pass on the source data. This is not the infinite clean-data project — it is a bounded, time-boxed audit with a specific output: a list of the data quality problems that would actually break the migration, versus the ones that can be cleaned up in the new system after go-live.

The categories to look for are predictable:

• Duplicates — multiple records for the same customer or contact, often with different information in each
• Empty required fields — records with no email address, no company, or no associated deal stage that will fail validation on import
• Format inconsistencies — phone numbers in four different formats, dates in mixed conventions, currency fields with text mixed in
• Orphaned records — contacts with no company, invoices with no customer, products with no category

Fix the blockers. Leave the cosmetic issues for post-migration cleanup. Two weeks of focused pre-migration data work is worth more than three months of post-go-live firefighting.

Use the Right Import Tools

The traditional migration approach — export to a spreadsheet, manually remap columns, import via CSV, discover errors, repeat — is how migrations turn into six-month projects. Modern AI-assisted import tools eliminate most of this manual work.

A good import wizard accepts arbitrary spreadsheet formats without requiring pre-formatted templates. It maps columns to destination fields automatically based on content recognition, not header matching — so a column labelled "Client Name" in the source maps correctly even if the destination field is called "Company." It flags data quality issues before writing any records, shows you exactly what will land where, and gives you a chance to correct mappings before committing.

The features that separate good import tools from adequate ones are:

• Pre-commit validation — shows you the result of the mapping before a single record is written
• Rollback window — allows you to undo the entire import within a time window (24 hours is the minimum you should accept) if something goes wrong
• Session history — logs every import with a clear record of what was brought in, when, and by whom
• Industry-specific field recognition — understands that "batch number" means something different in food manufacturing than in financial services

For migrations from major platforms — HubSpot, Salesforce, Pipedrive — direct API connectors are even better than import wizards. Rather than exporting to an intermediary format at all, they pull live data from the source via authenticated API connection, preserve relational data between records (contacts linked to companies linked to deals), and handle incremental syncs during the transition window. If the platform you are moving to offers these connectors, use them over any spreadsheet-based approach.

Set a Fixed Go-Live Date and Enforce It

Migration projects without a hard cutover date do not migrate — they drift. Pick a go-live date that gives you adequate preparation time, communicate it clearly as the date the old system stops being updated, and hold it. The fix for data quality problems discovered after cutover is to clean them in the new system, not to delay the cutover. Post-go-live cleanup is operationally manageable. Parallel-running is not.

On go-live day, the old system should immediately move to read-only. Staff should know in advance that the new system is the system of record from that point forward, and that entering data in the old system will mean it does not exist as far as the business is concerned. This sounds harsh. It is what prevents the data divergence that kills migrations quietly.

The Week-One Checklist

In the first week after go-live, run through these checks before declaring the migration complete:

• Verify record counts match between source export and imported destination (within an acceptable tolerance for filtered-out inactive records)
• Spot-check 20–30 customer records against the source for accuracy
• Confirm all open deals are present and correctly staged
• Verify product and pricing data is complete and correctly formatted
• Confirm all users can log in and access their expected records
• Check that any automated workflows triggered correctly on the imported data

Problems found in week one are recoverable. Problems found in month three, after staff have been entering data in the new system for twelve weeks, are not — because now you have to decide which version of reality is correct, and the answer is no longer obvious.

What Most Migrations Get Wrong

The migration failures that actually happen are almost never technical. The data did not corrupt. The import tool did not error out. The project failed because the organisation did not appoint a single decision-maker, allowed parallel running to continue past the point where it was useful, treated data cleaning as a prerequisite rather than an ongoing practice, or set a go-live date and then extended it twice when the cleaning project ran over.

The organisations that migrate successfully in weeks rather than months share one characteristic: they treat migration as a change management project with a defined owner, a fixed date, and a clear definition of done — not as a technical task that the IT team or the vendor's implementation consultant will sort out on their behalf.