CRM data migration: your practical guide for UK SMEs

CRM data migration is the staged transfer of your customer records, relationships, history, and automations from one system to another. Done well, it follows six steps: plan, cleanse, map, migrate, validate, hypercare. That sequence, recommended by HubSpot’s practical migration guide, is the spine of everything below.

Your immediate next action: pull a record-count report from your current CRM today. Count contacts, companies, deals, activities, and attachments. That single inventory is the foundation of every estimate, every risk conversation, and every stakeholder sign-off that follows.

Quick six-step plan:

Plan: define scope, stakeholders, success criteria, and a risk register
Cleanse: deduplicate, normalise, and archive records that should not migrate
Map: build a field-by-field mapping spreadsheet with transform rules
Migrate: run a test migration, then a full rehearsal, then the live cut
Validate: reconcile record counts, check referential integrity, run UAT
Hypercare: monitor daily for 2–6 weeks, handle exceptions, confirm UK GDPR compliance

Governing standards to keep close: UK GDPR (lawful basis for processing migrated data), Microsoft Dataverse migration guidance for Dynamics-based projects, and HubSpot’s own migration documentation for HubSpot-to-HubSpot or third-party-to-HubSpot moves.

Key takeaways

A successful CRM data migration depends on thorough pre-migration planning, rigorous data cleansing, documented field mapping, at least two full rehearsals, and a structured hypercare period covering UK GDPR compliance checks.

Point	Details
Start with a record inventory	Pull counts for every entity type before scoping anything else.
Cleanse before you migrate	Deduplication and field normalisation done upfront prevents compounding errors in the new system.
Map with business sign-off	Every field transform needs a documented rule and a named approver, not just an assumption.
Run two full rehearsals	At least two complete dress rehearsals before the live cut, with written results each time.
TTOY Digital can manage the whole process	From planning and mapping through to hypercare, TTOY Digital offers fixed-price and managed migration for UK SMEs.

How do you scope a CRM migration properly?
What should you keep, clean, and archive before migrating?
How do you build a field mapping that actually works?
Which migration method suits your project?
How do you design a migration test plan that gives you confidence?
What does a safe cutover actually look like?
What should you do in the first six weeks after go-live?
What does a CRM migration cost, and how long does it take?
Your CRM migration checklist and sample project plan
When should you bring in a specialist?
Ready to move your CRM data without the headaches?
Sources
FAQ

How do you scope a CRM migration properly?

Scope creep is the silent killer of CRM projects. The fix is a structured assessment before anyone touches a data file.

Running a fast object inventory

Pull a list of every entity type in your source system: contacts, accounts, leads, opportunities, cases, activities, notes, attachments, custom objects, and any junction tables that link them. For each entity, record the record count, the field count, and whether it has relationships to other objects. Also note which integrations write to or read from that entity, which workflows reference it, and which permission sets control access.

Hands plugging in storage device

That inventory becomes your scope document. Microsoft’s Dataverse migration guidance specifically recommends mapping object relationships and business rules before touching any data, and it is easy to see why: a contact record that looks simple often has child activities, linked opportunities, and marketing consent flags all depending on it.

Stakeholder matrix

Role	Responsibility	Decision authority
IT lead / technical lead	Object inventory, mapping, tooling	Architecture and method choices
Data owner	Deduplication rules, retention policy	What to keep, clean, or archive
Business sponsor	Success criteria, go/no-go	Budget and timeline approval
Compliance / legal	UK GDPR lawful basis, consent records	Data processing decisions
CRM vendor / agency	Platform constraints, migration tooling	Platform-specific guidance

Project Management Formula warns that data migration is the risk most likely to derail a CRM timeline, and that a named data owner is one of the most effective mitigations. Assign one person who can make binding decisions on deduplication and retention. Without that, every ambiguous record becomes a committee meeting.

Success criteria and acceptance gates

Write your success criteria before migration begins, not after. Useful examples:

Record parity within 0.5% of source count (accounting for intentional exclusions)
Zero orphaned child records after migration
All mandatory fields populated in 100% of migrated records
UAT sign-off from at least two business users per entity type
No critical workflow failures in the first 48 hours post-go-live

Risk register items specific to CRM migration

Delta records during cutover: new records created in the source system after your final extract
Integration breakage: connected tools (email, ERP, marketing platform) that stop writing to the new CRM
Data leakage: sensitive fields (payment data, health information) exposed during transfer
Consent record loss: marketing opt-ins or opt-outs not migrated, creating UK GDPR exposure
Schema mismatch: custom fields in the source with no equivalent in the destination

For SMB projects, a realistic timeline estimate is: add up your record count, divide by your chosen migration method’s throughput, then double it. The doubling accounts for data quality remediation, which almost always takes longer than expected.

What should you keep, clean, and archive before migrating?

The worst thing you can do is migrate everything. Junk data in a new system is still junk data, and it costs you twice: once to move it, and again when it corrupts your reports and automations.

Decision rules

Keep: active customers with transactions in the past 24 months, all records with open opportunities or cases, any record with marketing consent on file, fiscal and contractual data within your retention period
Clean: duplicate contacts, malformed phone numbers, blank mandatory fields, inconsistent picklist values, contacts with no activity and no consent
Archive: records older than your retention policy, historical-only leads with no associated revenue, test records and sandbox data that crept into production

A practical deduplication approach for most SMBs runs in three passes. First, exact email match: two records sharing an email address are almost certainly the same person. Second, fuzzy name plus company: use a tool like OpenRefine or a spreadsheet formula to flag near-matches. Third, domain-level deduplication for company records: two accounts sharing the same web domain are likely duplicates unless you have a deliberate reason to keep them separate.

Field standardisation

Before migration, normalise these fields consistently:

Phone numbers: strip spaces, brackets, and hyphens; store in E.164 format (+447911123456)
Country codes: use ISO 3166-1 alpha-2 (GB, not United Kingdom or UK or Great Britain)
Picklists: map legacy values to the new system’s allowed values; any unmapped value will either error or default to blank
Names: split “FirstName LastName” concatenated fields into separate columns before import

For email history and attachments, the rule of thumb is: migrate the last 12 months of email activity if the destination supports it; archive older email history in an encrypted export rather than attempting a full transfer. Attachment migration is expensive in both time and storage. Audit attachment types and sizes first, then migrate only those referenced by active records.

Archiving records not migrated

Export excluded records to a structured format (CSV or JSON), encrypt the archive, and store it in line with your UK GDPR retention schedule. Document the lawful basis for retaining it, set a deletion date, and log who has access. The Information Commissioner’s Office expects you to be able to demonstrate that archived personal data is still being processed lawfully, even if it is no longer in your live system.

Pro Tip: Before you delete anything from the source system, take a full backup and store it separately from your migration working files. Restoration from a corrupted working copy is far harder than restoration from a clean backup.

How do you build a field mapping that actually works?

Field mapping is where migrations live or die. A mapping spreadsheet that is incomplete, unsigned, or built without business input will produce errors that take weeks to unpick after go-live.

Mapping spreadsheet structure

Column	Purpose
Source field name	Exact API or column name in the source system
Source data type	Text, number, date, picklist, lookup, boolean
Sample values	3–5 real examples from the source data
Destination field name	Exact API or column name in the target system
Transform required	None / format change / lookup / concatenate / split
Mandatory in destination	Yes / No
Owner sign-off	Name and date of business stakeholder approval

Microsoft’s Dataverse guidance recommends preserving business rules during mapping, which means the transform column is not optional. Every field that changes format, type, or value during migration needs a documented rule, not just an assumption.

Preserving relationships

Migrate parent objects before children, every time. Accounts before contacts, contacts before activities, opportunities before line items. If you migrate a child record before its parent exists in the destination, you get an orphaned record with a broken foreign key, and those are painful to fix at scale.

Owner IDs deserve special attention. User records in the source system map to user records in the destination, but the IDs are almost never the same. Build a user mapping table (source user ID to destination user ID) and apply it as a transform step before importing any record that has an owner field.

Common transformations with examples

Date formats: source stores “01/06/2024” (DD/MM/YYYY); destination expects “2024-06-01” (ISO 8601). Apply a formula or ETL rule to convert.
Currency: source stores “1500” with a separate currency field; destination expects “1500.00 GBP”. Concatenate and format.
Picklist normalisation: source has “United Kingdom”, “UK”, “GB”, and “England” all meaning the same thing. Map all four to “GB” in the destination.
Name splitting: source has a single “Full Name” field. Destination requires separate first and last name fields. Use a split-on-last-space rule, then manually review records with three or more name parts.

Pro Tip: When you encounter a custom object in the source that has no equivalent in the destination, resist the urge to create a workaround immediately. First, ask whether the business still needs that object. Half the time, the answer is no, and you save yourself a complex mapping exercise.

Which migration method suits your project?

There is no single right method. The right choice depends on your record volume, the complexity of your custom objects, and how much time your team has.

CSV and spreadsheet imports

Best for small datasets with standard objects and no complex relationships. Most CRM platforms accept CSV imports natively. The process is manual and error-prone at scale, but it is fast to set up and requires no specialist tooling. Expect to spend significant time on data preparation before the import itself.

Limitations: no automatic relationship handling, no delta migration capability, attachment migration is not possible via CSV, and large files often hit platform row limits.

Platform import wizards

Most major CRM platforms include a guided import tool. These wizards handle basic field mapping within the platform’s own schema and are appropriate for straightforward migrations between similar systems. They are the right starting point for any SMB moving from a spreadsheet or a simple legacy CRM to a modern platform.

The catch is that wizards rarely handle custom objects, complex relationships, or transformations. If your source data does not fit neatly into the destination’s standard schema, you will hit walls quickly.

API-based migrations and ETL tools

For mid-market projects with custom objects, multiple integrations, or large volumes, an API-based approach gives you full control. You write or configure scripts that read from the source API and write to the destination API, applying transforms in between. Tools like Talend, Fivetran, or custom Python scripts are common choices.

Microsoft’s migration assets and SDK tooling support API-based approaches for Dynamics and Dataverse projects specifically. Check API rate limits before you start: most CRM platforms throttle bulk API calls, and a migration that looks like it will take four hours can take 40 if you hit rate limits without a retry strategy.

iPaaS and middleware

Platforms like Make (formerly Integromat) or Zapier handle lighter migration scenarios and are particularly useful when you need to keep two systems in sync during a parallel-run period. They are not designed for bulk historical migration but work well for delta sync during cutover.

Managed services and agency support

When your project involves complex custom objects, multiple integrations, attachments, or a hard deadline, engaging an agency or vendor professional services team is often the most cost-effective choice. Expect deliverables to include a migration plan, mapping documentation, test results, and a hypercare support window. Oracle’s implementation guidance recommends using certified consultants for complex deployments specifically to avoid cost overruns from rework.

For SMBs weighing the right CRM fit before committing to a migration method, the complexity of your current data is often a better guide than the size of your business.

How do you design a migration test plan that gives you confidence?

Testing is where most SMB migrations cut corners, and it is the single most reliable predictor of a painful go-live. Project Management Formula recommends at least two full migration rehearsals before the live cut. That is not overcautious; it is the minimum.

Test plan structure

Unit tests: validate individual field transforms. Does a date field convert correctly? Does a picklist value map as expected? Run these on a sample of 50–100 records per entity type.
Integration tests: confirm that connected systems (email, ERP, marketing automation) still read and write correctly after migration. Check that marketing automation workflows that depend on CRM field values fire as expected.
Full-dataset rehearsal: migrate the complete dataset into a sandbox or staging environment. This is your dress rehearsal. Time it. Document every error.
User acceptance testing (UAT): two or more business users per entity type work through real scenarios in the staging environment and sign off. They are not testing the migration script; they are testing whether the data makes sense to them.

Reconciliation metrics

Record count parity: destination count matches source count minus intentional exclusions, within your agreed tolerance (typically 0.5%)
Referential integrity: every child record has a valid parent; no orphaned foreign keys
Mandatory field coverage: 100% of mandatory fields populated in migrated records
Sample spot checks: manually verify 20–30 records per entity type, chosen randomly
Workflow trigger audit: confirm that key automations fire correctly on test records post-migration

Reconciliation is not a one-time check. Run it after every rehearsal and again immediately after the live migration. Discrepancies that appear only after go-live are almost always discrepancies that existed after the rehearsal but were not caught.

Acceptance gate checklist

Record parity within agreed tolerance: signed off by IT lead
Zero critical workflow failures in staging: signed off by business sponsor
UAT sign-off from business users for each entity type
Integration health confirmed by connected system owners
Rollback procedure tested and documented

Automated scripts handle count checks and referential integrity well. Human review is non-negotiable for spot checks and UAT: a script cannot tell you whether a contact’s history makes business sense.

What does a safe cutover actually look like?

Cutover is the highest-risk window of any migration. The goal is to make it as short and reversible as possible.

Cutover checklist

Freeze the source system: set it to read-only or disable write access for all users
Extract the final delta: capture any records created or updated since your last rehearsal
Immobilise integrations: pause or disconnect any system writing to the source CRM
Run final validation checks on the delta extract before importing
Import the delta into the destination
Switch credentials and DNS entries if the CRM URL is changing
Enable user access to the destination system
Confirm integration reconnection and test each one

Community practitioner guidance consistently shows that a read-only freeze on the source system during the final delta migration reduces cutover errors substantially. The freeze window for most SMB projects should be under four hours. If your delta is large enough to require longer, consider a phased cutover by entity type.

Communication timeline

48 hours before freeze: notify all users of the maintenance window, expected downtime, and who to contact with questions
2 hours before freeze: final reminder with exact freeze time and go/no-go decision point
During freeze: brief status updates every 30–60 minutes to the business sponsor
Go/no-go decision: IT lead and business sponsor jointly confirm before enabling user access
Immediately post-go-live: all-user notification confirming the new system is live, with a link to training resources

Rollback criteria and procedure

Define your rollback triggers before cutover begins. Typical triggers:

Record parity below your agreed tolerance after the live migration
A critical integration failure that cannot be resolved within two hours
Data corruption affecting more than a defined number of records
A mandatory field found blank across more than a small percentage of records

If a trigger fires, the rollback procedure is: re-enable write access to the source system, notify all users to return to it, and log the failure with timestamps. Do not attempt to fix the destination system while users are working; that creates a data split that is very difficult to reconcile.

Pro Tip: Keep a named “rollback decision maker” in the room (or on the call) for the entire cutover window. Rollback decisions made by committee under time pressure go badly. One person, clear authority, pre-agreed triggers.

Handling in-flight transactions

Open opportunities, ongoing support cases, and pending payments need special handling. Before the freeze, export a list of all in-flight records and assign a named owner to verify each one post-migration. For payments, coordinate with your finance team to confirm that any payment gateway integration is reconnected and tested before the freeze window ends.

What should you do in the first six weeks after go-live?

The hypercare period is where migrations either bed in or unravel. Most problems surface in the first two weeks, so front-load your monitoring effort there.

Post-go-live reconciliation checklist

Run daily record-count reports for the first two weeks, comparing destination counts to your migration log
Review exception reports: any record that failed to import should be logged, triaged, and either re-imported or documented as an intentional exclusion
Collect user sign-offs by entity type: ask each business user to confirm their data looks correct within the first five working days
Check that all scheduled automations have fired correctly on their first post-migration run

Monitoring playbook

Error dashboards: configure your CRM’s built-in error logging to alert on failed workflow triggers, failed integration writes, and API errors
Integration health: check each connected system daily for the first two weeks; look for missing records, duplicate writes, or authentication failures
Background jobs: confirm that scheduled imports, data syncs, and report refreshes are running on schedule

HubSpot’s deployment guidance stresses that data quality problems surface late unless profiled early. The same principle applies post-migration: the monitoring you skip in week one becomes the incident you manage in week four.

Optimisation tasks

Once the data is stable, tidy the system:

Archive or hide picklist values that existed in the source but are no longer used
Remove fields that were migrated but have no business owner or use case
Reconfigure workflow triggers based on how users are actually working in the new system, not how they worked in the old one
Build the key dashboards your business sponsor asked for before go-live, if they are not already in place

Confirm that every category of personal data migrated has a documented lawful basis for processing in the new system
Update your privacy notice if the data flows have changed (for example, if the new CRM shares data with a third-party integration that the old one did not)
Verify that your secure archive of excluded records has an access log and a documented deletion date
Check that data subject access request (DSAR) processes still work correctly in the new system

What does a CRM migration cost, and how long does it take?

Realistic expectations save projects. Here are typical ranges for UK SMB migrations, broken down by project size.

Phase duration by project size

Phase	Small (under 10k records, standard objects)	Mid-market (10k–100k records, some custom objects)	Complex (100k+ records, multiple integrations)
Discovery and scoping	1–2 days	3–5 days	1–2 weeks
Data cleanse	2–5 days	1–2 weeks	2–4 weeks
Field mapping	1–2 days	3–5 days	1–2 weeks
Testing and rehearsals	2–3 days	1–2 weeks	2–4 weeks
Cutover	2–4 hours	4–8 hours	8–24 hours
Hypercare	2 weeks	4 weeks	6 weeks

Total elapsed time ranges from roughly two weeks for a small, clean dataset to 16 weeks for a complex project with significant data quality issues and multiple integrations.

Primary cost drivers

Data quality remediation: the single largest variable. Poor source data quality can double or triple the cleanse phase.
Custom objects: each custom object requires its own mapping, transform logic, and test cycle.
Integrations: each connected system needs disconnection, reconfiguration, and reconnection testing.
Attachments: large attachment volumes are slow to migrate and expensive in storage.
Agency or vendor engagement: external resource adds cost but reduces internal time and risk.
Compliance and legal work: UK GDPR review, consent record audit, and privacy notice updates add time if not planned for.

Internal vs external resource

For small projects with standard objects and clean data, internal resource is usually sufficient. For mid-market and complex projects, a fixed-price engagement with an agency gives you a defined deliverable, a clear timeline, and someone accountable for the outcome. Fixed-price is realistic when the scope is well-defined; time-and-materials is more appropriate when the data quality is unknown at the start.

Budget checklist to convert scope into line items:

Record count and entity types (drives cleanse and mapping effort)
Number of custom objects (drives mapping and testing effort)
Number of integrations (drives integration testing effort)
Attachment volume in GB (drives storage and transfer cost)
Internal bandwidth available (drives whether agency support is needed)
Compliance review required (drives legal and DPO time)

Your CRM migration checklist and sample project plan

A checklist is only useful if it has owners. Copy this into your project plan and assign a name to every task.

Phase-by-phase checklist

Assess
- Pull record counts for all entity types (IT lead)
- Document all integrations and their data flows (IT lead)
- Identify custom objects and their relationships (IT lead)
- Confirm data owner and business sponsor (business sponsor)
- Define success criteria and acceptance gates (IT lead + business sponsor)
Cleanse
- Run deduplication pass on contacts and accounts (data owner)
- Normalise phone, country, and picklist fields (IT lead)
- Archive records outside retention policy (data owner + compliance)
- Export and encrypt archived records (IT lead)
Map
- Build field mapping spreadsheet for each entity type (IT lead)
- Document all transform rules (IT lead)
- Get business owner sign-off on each mapping (data owner)
- Build user mapping table (IT lead)
Test
- Run unit tests on field transforms (IT lead)
- Perform first full-dataset rehearsal in staging (IT lead)
- Run integration tests with connected systems (IT lead + integration owners)
- Conduct UAT with business users (data owner + business users)
- Document and resolve all errors from rehearsal (IT lead)
Migrate
- Perform second full rehearsal and time it (IT lead)
- Confirm rollback triggers and decision maker (business sponsor)
- Execute cutover checklist (IT lead)
- Import delta records (IT lead)
- Reconnect integrations (IT lead + integration owners)
Validate
- Run record count reconciliation (IT lead)
- Check referential integrity (IT lead)
- Conduct post-go-live spot checks (data owner)
- Collect user sign-offs (data owner)
Hypercare
- Run daily reconciliation reports for two weeks (IT lead)
- Monitor integration health daily (IT lead)
- Tidy picklists and archive unused fields (IT lead)
- Complete UK GDPR checks (compliance)
- Build key dashboards (IT lead + business sponsor)

Sample project plan: milestones

A CRM implementation checklist resource recommends pre-migration cleaning and test imports specifically to reduce rework after go-live. Build those into your milestone plan:

Week 1: scope confirmed, stakeholders assigned, record inventory complete
Week 2–3: data cleanse complete, mapping spreadsheet signed off
Week 4: first rehearsal complete, errors documented
Week 5: errors resolved, second rehearsal complete
Week 6: UAT sign-off, cutover executed, hypercare begins
Week 8: hypercare complete, system handed over to business

For a small project, compress weeks 2–5 into a single week. For a complex project, extend each phase as the duration table above suggests.

When should you bring in a specialist?

There is a version of CRM migration that an experienced IT lead can handle internally, and there is a version that will consume your team for months and still go wrong. Knowing which one you are facing is the most valuable judgement call in the whole project.

The signals that point to external help are fairly consistent. Complex custom objects with no clear equivalent in the destination system, three or more integrations that all need simultaneous reconnection, a hard go-live deadline with no room for a second rehearsal, or a team with limited bandwidth alongside their day job: any one of these is a reason to consider a specialist. All four together, and the case for going it alone is difficult to make.

What good external engagement looks like is worth spelling out, because the market is uneven. You should expect a documented migration plan before any data moves, a mapping spreadsheet with business sign-off, at least two rehearsals with written results, a defined hypercare window, and clear rollback documentation. If a proposed engagement does not include all of those, the scope is incomplete.

TTOY Digital works with UK SMEs on CRM migrations across advisory, fixed-price, and managed migration models. The advisory model suits teams that want to run the migration themselves but need a structured plan and a second pair of eyes on the mapping. Fixed-price suits well-scoped projects where the data quality is known. Managed migration, which includes planning, execution, integration testing, and a hypercare window, suits teams with limited internal bandwidth or a complex source system.

The outcomes that matter most to clients are usually a reduced duplicate rate in the new system, faster time to first meaningful report, and integrations that work correctly from day one rather than after a week of firefighting.

When should you bring in a specialist? — overview diagram

Ready to move your CRM data without the headaches?

CRM migrations for UK SMEs do not have to be a months-long ordeal. TTOY Digital delivers end-to-end CRM migration services covering planning, data cleanse, field mapping, integration testing, and a structured hypercare window so your team is not left troubleshooting alone after go-live.

For small businesses that want to reduce integration risk from the start, SmartFlowCRM consolidates WhatsApp, email, and lead management into a single platform, which means fewer connected systems to migrate and fewer points of failure during cutover. It is a practical option for any SMB that finds its current CRM surrounded by a tangle of integrations it barely uses.

If you are at the scoping stage and want a clear picture of what your migration will involve, book a discovery call with the TTOY Digital team. We will review your current system, give you an honest assessment of complexity, and help you build a project plan you can actually deliver.

Sources

FAQ

What is CRM data migration?

CRM data migration is the process of moving customer records, relationships, history, and automations from one CRM system to another. It covers contacts, accounts, deals, activities, attachments, and any custom objects, along with the workflows and integrations that depend on them.

What are the four types of data migration?

The four common types are storage migration (moving data between storage systems), database migration (moving between database engines), application migration (moving data between applications, which is what CRM migration is), and cloud migration (moving on-premises data to a cloud platform). CRM software migration typically combines application and cloud migration elements.

Will CRM be replaced by AI?

AI is being built into CRM platforms rather than replacing them. Tools like predictive lead scoring, automated data enrichment, and AI-generated activity summaries are now standard features in major CRM platforms, but the underlying record structure, relationships, and data that make those features useful still require careful migration and governance.

What does CRM data stand for?

CRM stands for Customer Relationship Management. CRM data refers to all the records stored within a CRM system: contacts, companies, deals, activities, notes, and any custom data your business has added to track customer interactions and history.

How long does a CRM migration take for a small business?

A small business migration with standard objects typically takes two to six weeks from scoping to hypercare completion. Larger or more complex projects with custom objects and multiple integrations can take 12–16 weeks.