Data Migration Strategy When Switching CRM or ERP Systems

Moving to a new CRM or ERP system is usually justified by better features, lower costs or a platform that can grow with the business. Yet the success of the switch depends heavily on something much less visible:

Whether the data arrives in the new system complete, accurate and usable. Customer histories, open deals, product catalogues, stock balances, supplier terms and financial records are the memory of the business. If they are lost, duplicated or scrambled during the move, the new system starts life untrusted, and people quietly go back to their spreadsheets.

A sound data migration strategy has a predictable shape. Decide what data to move and what to leave behind. Clean it before it moves, not after. Map every field from the old structure to the new one, with clear rules for anything that does not match. Choose a migration approach that fits your risk tolerance. Rehearse the migration several times, reconcile the results against the source and get business users to sign them off. Then plan the cutover in detail, with a tested way back if something goes badly wrong.

This guide explains each of those steps, with particular attention to the differences between CRM and ERP migrations, the reconciliation checks that catch problems before they reach customers or the accounts, and the mistakes that most often turn a planned weekend cutover into weeks of disruption.

Why data migrations go wrong

Data migration is often treated as a technical task that happens near the end of a system implementation: export from the old system, import into the new one, done. That view is the root of most problems.

The reality is that old systems accumulate years of inconsistencies. Duplicate customer records, fields used for purposes they were never designed for, free-text notes that hold critical information, products that were discontinued but never deactivated, and workarounds that only one long-serving employee understands. The new system has its own structure, rules and validations, and many of these quirks will not fit. Every mismatch needs a decision, and many of those decisions are business decisions, not technical ones.

The consequences of getting it wrong can be severe. A well-documented example is the UK bank TSB, which migrated its customers from a platform operated by its former parent to a new system in April 2018. The migration led to widespread problems that left many of its 5 million or so customers unable to access their accounts properly for days or weeks. In 2022, the Financial Conduct Authority and the Prudential Regulation Authority fined TSB a combined total of around £48.65 million, citing failures in managing operational resilience and the risks of the IT migration. A bank's core platform migration is far larger than most CRM or ERP moves, but the lessons apply at any scale: insufficient testing, overconfidence in readiness and inadequate planning for what happens if things go wrong.

At a more everyday level, the warning signs of a troubled migration are familiar. Go-live dates slip because test imports keep failing. Users find missing contact histories or wrong prices in the first week. Finance cannot reconcile opening balances. Sales teams discover duplicate accounts and stop trusting the new CRM. Each of these traces back to decisions that were rushed or never made.

The good news is that the causes are well understood and largely preventable with a structured approach, which the rest of this guide sets out.

Plan first: scope, ownership and deciding what to move

Start migration planning early

Data migration should begin as soon as a new system is chosen, not once it has been configured. The structure of your data affects how the new system should be set up, and decisions about configuration affect how data must be transformed. Running the two in parallel avoids discovering, weeks before go-live, that the new system cannot hold information the business depends on.

Assign business ownership

Every major data area needs a business owner who understands what the data means and can make decisions about it. Customer and contact data might be owned by the head of sales, products and pricing by operations or commercial teams, suppliers by purchasing, and financial data by the finance lead. Technical staff or partners carry out the migration, but they should not decide on their own whether two similar customer records are duplicates or which historical price list is correct.

Build a data inventory

List every source of data that matters: the old CRM or ERP itself, but also spreadsheets, email folders, document stores, add-on applications and integrations. For each, note what it contains, how many records, how current it is, who uses it and whether it should feed the new system. Spreadsheets maintained outside the old system often turn out to hold critical information that nobody mentioned in early workshops.

Decide what to migrate and what to leave behind

Moving everything is rarely the right answer. Migrating years of obsolete records adds cost, slows testing and clutters the new system. A useful approach is to sort data into three groups.

Migrate in full: active and recent records the business works with every day, such as current customers and contacts, open opportunities, active products, open orders, open invoices and current stock balances.

Migrate in summary: older history that is useful for context but does not need every detail in the new system. In an ERP migration, many businesses bring across opening balances and summarised historical totals rather than every past transaction. In a CRM, older activity history may be summarised or attached as a note.

Archive, do not migrate: inactive records, closed transactions beyond a cut-off date and data kept only for legal or audit reasons. These should remain accessible in a read-only archive or export, not deleted, and not loaded into the new system.

Agree the cut-off rules with the data owners and with finance, legal or compliance where relevant, and write them down. These decisions shape the size, cost and risk of the whole project.

Profiling and cleansing the data

A migration is the best opportunity you will have to fix long-standing data problems. Moving dirty data into a new system simply transfers the problems, and new systems often enforce stricter validation, so poor data may fail to load at all.

Profile before you plan the effort

Data profiling means analysing the source data to understand its real condition. How many customer records are there, and how many appear to be duplicates? What percentage of contacts have no email address? How many products have no cost price or an obviously wrong unit of measure? Are dates, phone numbers and country codes in consistent formats? Which fields are nearly always empty and which have been used for unexpected purposes?

Profiling can be done with database queries, spreadsheet analysis, data preparation tools or specialist data quality software. The results give you a realistic picture of how much cleansing is needed and help prioritise effort. They often surprise the business.

Common cleansing tasks

Deduplication is usually the largest job in CRM migrations. The same company or person may appear several times, with slightly different spellings, addresses or contact details. Agree matching rules, such as same email address or same company registration number, decide which record survives and how information from duplicates is merged, and have data owners review uncertain matches.

Standardisation brings consistency to formats and values: country names, phone number formats, address fields, units of measure, payment terms and industry categories. Mapping free-text values to defined picklists is often necessary because the new system will expect them.

Completion and correction fills important gaps and fixes known errors, for example missing VAT numbers on customer accounts, missing cost prices on products or incorrect tax codes.

Removal retires records that should not move, such as test data, long-inactive contacts or obsolete items, in line with your scoping rules.

Where to clean

Where possible, clean data in the source system before migration, so that it stays consistent during the transition and the old system remains a reliable fallback. Some transformations are better done during the migration process itself. Either way, document what was changed and why. Data protection law also matters here. Under the UK GDPR and EU GDPR, personal data should be accurate and not kept longer than necessary, so a migration is a natural moment to remove personal data you no longer have a reason to hold.

Mapping and transforming data for the new system

Data mapping defines exactly where each piece of data from the old system will go in the new one, and what needs to happen to it on the way. It is the blueprint for the migration, and gaps in it are the most common cause of failed test loads.

Build a field-level mapping document

For each data object, such as accounts, contacts, opportunities, products, customers, suppliers, open orders and invoices, list every source field, the target field it maps to, any transformation rule and the person who approved it. Transformation rules cover things like splitting a single "name" field into first and last names, converting old status codes to new picklist values, combining several old fields into one, applying default values where data is missing, or converting currencies and units.

Fields that have no obvious home need explicit decisions: create a custom field in the new system, store the information as a note, archive it or drop it. Undocumented decisions made by whoever happens to be running the import tend to cause problems later.

Preserve relationships

CRM and ERP data is relational. Contacts belong to accounts, opportunities to accounts and contacts, order lines to orders and products, invoices to customers. The migration must preserve these links, which usually means loading data in a specific order, parent records before child records, and keeping track of how old record IDs relate to new ones. A common technique is to store the legacy ID in a field on each new record, which makes reconciliation, troubleshooting and any later data loads far easier.

CRM-specific considerations

CRM migrations usually involve accounts, contacts, leads, opportunities, activities, notes, attachments, email history, campaigns and custom objects. Practical challenges include record ownership, since users in the old system must be matched to users in the new one, activity and email history, which can be very large and is often summarised or left in an archive, pipeline stages, which need mapping to the new sales process, and consent and marketing preferences, which must be carried across accurately to stay compliant with data protection and marketing rules.

ERP-specific considerations

ERP migrations add financial and operational complexity. Master data, such as the chart of accounts, customers, suppliers, items, bills of materials, price lists and tax codes, usually needs to be redesigned rather than copied, because the new system's structure is different. Transactional data is typically handled through opening balances: open sales and purchase orders, unpaid invoices and bills, stock quantities and values by location, fixed asset registers and general ledger balances at the cutover date. Historical transactions are often brought across as summarised monthly balances for reporting, with full detail retained in an archive. Finance must agree these approaches in advance, because they affect reporting, audit trails and tax compliance. (Internal link suggestion: an article on custom ERP for inventory control or ERP implementation.)

Choosing a migration approach

There are three broad ways to move from an old system to a new one. Each has different trade-offs between speed, cost and risk, and the right choice depends on the size of the business, how complex the data is and how much disruption you can tolerate.

Big bang

In a big bang migration, all data and users move to the new system at a single point, usually over a weekend or a quiet period, and the old system is switched off or made read-only. It is the simplest approach to manage, avoids running two systems and is common for small and mid-sized businesses. The risk is concentrated: if something goes wrong, it affects everyone at once. Big bang migrations depend on thorough rehearsal and a clear rollback plan.

Phased

A phased migration moves data and users in stages, for example by region, business unit, department or module. One division might move to the new ERP while others stay on the old one for a few months, or a CRM might go live for sales before customer service. This spreads risk and lets the team learn from each phase. The downside is a longer period of running two systems, often with temporary integrations to keep data consistent between them, which adds cost and complexity.

Parallel running

In a parallel run, both systems operate side by side for a period, with transactions entered in both and results compared. This gives a high level of assurance, and is sometimes used for critical finance or payroll processes, but it doubles the workload for users and can be hard to sustain for long. Many businesses use a limited parallel run, for example reconciling the first month-end close in both systems, rather than running everything twice.

Incremental or trickle migration

A related technique is to move historical data in advance, then migrate only the changes made since, known as a delta load, during the final cutover. This shortens the cutover window, which is helpful when large data volumes would otherwise take too long to load over a single weekend.

For many small and mid-sized businesses, a well-rehearsed big bang migration with a short limited parallel check for finance is a sensible balance. Larger organisations with several business units often favour a phased approach. Whatever the choice, the decision should be explicit and agreed by the business, not defaulted to.

Testing and reconciliation

The single most effective way to reduce migration risk is to rehearse it. A migration that has been run successfully several times in a test environment, with results checked by the business, is far less likely to fail on the night.

Run multiple trial migrations

Plan for at least two or three full trial migrations before go-live, using a recent copy of production data. The first trial usually exposes mapping gaps, load errors and data that fails validation. Later trials should run cleanly from start to finish, using the same scripts, tools and sequence planned for the real cutover. Time each trial, because the duration determines whether the cutover will fit within the planned window.

Reconcile at several levels

Reconciliation compares the migrated data with the source to confirm nothing was lost, duplicated or corrupted. It should happen at several levels.

Record counts check that the number of records of each type in the new system matches the expected number from the source, after accounting for deliberate exclusions and merged duplicates.

Financial totals are essential for ERP migrations. Total receivables, payables, stock value, open order values and general ledger balances in the new system must match the old system at the cutover date, to the penny. Finance should sign these off.

Field-level sampling compares a sample of individual records field by field, checking that names, addresses, prices, dates, statuses and relationships came across correctly. Include tricky cases, such as records with special characters, very long notes, multiple addresses or unusual currencies.

Relationship checks confirm that contacts are linked to the right accounts, order lines to the right orders and products, and invoices to the right customers.

Test business processes, not just data

Data that looks correct can still break processes. Business users should run realistic scenarios in the test environment using migrated data: create a quote for an existing customer, process an open order through to invoice, run a stock count, raise a credit note, produce the month-end reports. These user acceptance tests often reveal problems that technical checks miss, such as missing default values or a tax code mapped incorrectly.

Get formal sign-off

Before go-live, data owners should formally confirm that their data has been migrated correctly in the final trial. Sign-off focuses attention, creates accountability and gives the project a clear go or no-go decision point.

Cutover planning and rollback

The cutover is the period when the business stops using the old system, migrates the final data and starts using the new one. A detailed plan turns what could be a chaotic weekend into a controlled sequence of steps.

Write a step-by-step cutover plan

The plan should list every task in order, with an owner, an expected start and finish time and a clear check that confirms it is complete. Typical steps include announcing a freeze on changes in the old system, taking a final backup, running the final extract and any delta loads, loading data into the new system in the correct sequence, running reconciliation checks, completing business verification, switching integrations and user access to the new system, and making the old system read-only.

Timing matters. Choose a cutover window that avoids peak trading periods, month-end or year-end closes and major sales campaigns, and make sure key people are available throughout. For ERP migrations, aligning cutover with the start of a financial period, often a month-end, simplifies opening balances and reporting.

Define go and no-go criteria

Agree in advance what conditions must be met to proceed at each checkpoint, such as reconciliation totals matching, no critical defects open and key processes tested successfully. Decide who makes the final go-live decision. Setting these criteria before the cutover removes the pressure to proceed regardless of problems.

Plan the way back

Every cutover plan needs a rollback plan: what will happen if the migration fails badly, how far through the cutover you can still return to the old system and how long rollback would take. In most cases, this means keeping the old system intact and available, not changing data in it after the freeze and having a documented process to reopen it. A rollback plan that has never been discussed is unlikely to work under pressure.

Support the first weeks

The first days after go-live are when users discover problems. Plan for extra support, sometimes called hypercare: experts available on the floor or online, a clear process for reporting issues, daily review of problems and fast fixes for data errors. Keep the migration team in place until the new system is stable.

After go-live: archiving, decommissioning and compliance

Go-live is not the end of the migration. Several tasks remain, and skipping them can create legal, financial and operational problems later.

Keep historical data accessible

Data that was not migrated still needs to be available for reference, audits, disputes and legal obligations. Tax authorities typically require businesses to keep financial records for several years; in the UK, for example, HMRC generally expects VAT records to be kept for at least six years, and in the US the Internal Revenue Service sets retention periods that vary depending on the circumstances. Other regulations may require longer retention for particular records. Check the rules that apply to you with your accountant or legal adviser.

Options for keeping history accessible include keeping the old system running in read-only mode for a period, exporting data to a structured archive or database that authorised staff can search, or storing standard reports and documents in a secure document repository. Choose an approach that remains usable when the people who knew the old system have moved on.

Decommission the old system carefully

Once the archive is confirmed and the new system is stable, plan the shutdown of the old system. Cancel licences and hosting, but only after confirming that all required data has been archived and verified. Remove user access, disconnect integrations and securely delete data that is no longer needed, in line with your retention policy and data protection obligations.

Review data protection obligations

A new system often means new processors, new data locations and new uses of data. Update your records of processing activities and privacy notices where needed, make sure data processing agreements are in place with the new vendor and any migration partners, and confirm that personal data was not copied into insecure places, such as spreadsheets on laptops, during the migration. Delete temporary migration files and test environments containing real personal data once they are no longer needed.

Protect data quality going forward

The clean data you migrated will degrade unless you prevent it. Use the new system's validation rules, required fields, picklists and duplicate detection, assign ongoing data owners and run regular data quality checks. Many of the problems you fixed during migration began with weak controls in the old system.

Measure success

A few weeks after go-live, review how the migration went. Track data-related support tickets, reconciliation results at the first month-end close, user adoption and any data errors found. Capture lessons for future migrations, because system changes will happen again.

Common data migration mistakes

Treating migration as a late technical task. Leaving data migration until the new system is configured leads to rushed decisions and unpleasant surprises. Start planning as soon as the new system is selected.

Migrating everything. Copying every historical record adds cost, slows testing and clutters the new system. Agree clear rules for what to migrate in full, in summary or not at all.

Cleaning data after go-live. Promises to tidy up later rarely happen, and by then users have already lost trust in the new system. Cleanse before or during migration.

Letting technical teams make business decisions. Mapping and deduplication choices affect sales, finance and operations. Business owners must make and sign off these decisions.

Too few test runs. A single test load is not a rehearsal. Plan for several full trial migrations using real data, timed and reconciled.

Reconciling counts but not values. Matching record counts can hide wrong prices, balances or relationships. Reconcile financial totals and sample individual records in detail.

No rollback plan. Assuming the cutover will succeed is not a plan. Define go and no-go criteria and how you will return to the old system if needed.

Forgetting integrations and automation. Other systems connected to the old CRM or ERP, such as websites, e-commerce platforms, payroll, marketing tools and reporting, must be repointed and tested. Automated workflows in the new system can also trigger unexpectedly on migrated data, for example sending welcome emails to thousands of existing customers, so switch them off during loading.

Decommissioning too soon. Shutting down the old system before confirming that all necessary data is archived and accessible can create legal and operational problems that are hard to fix.

Data migration is often the riskiest part of a CRM or ERP project, and it is also the part where experience pays off most. An experienced SaaS, CRM and ERP development partner can help profile your data, design the mapping and transformation rules, automate repeatable migration scripts, and plan testing and cutover so that the new system starts with data the business can trust.