Move your data.
Keep the context.

Define what the migration needs to preserve

A CRM migration moves information from one system into another while preserving the meaning needed for the team’s work. The source may be another CRM, a spreadsheet or several disconnected files. Copying rows is part of the job; preserving relationships, ownership, dates and operational context is what makes the result usable.

Start with an inventory. List each source, its owner, the record types it contains and the reason it is needed in the destination. Identify the authoritative version when several files overlap. Decide which historical information supports current work and which will remain in an agreed archive. Do not let the first available export define the entire migration scope.

Write the acceptance criteria before changing data. You might require every active opportunity to retain its company link, assigned owner and next action. You may also need documents or interaction history, depending on the source and destination capabilities. Confirm those capabilities explicitly: a basic CSV export does not necessarily contain everything visible inside an application.

This is a product-neutral planning guide. It includes illustrative examples, an original field-mapping worksheet and checks to discuss with the person responsible for your data. It does not promise a lossless one-click transfer, and it is not a direct-import file for any particular CRM.

01. Preserve the original and control the working copy

Create a dated export of the agreed source data and retain it in a location accessible to the responsible team. Record how and when it was produced, which filters were applied and what the export does not include. Work on a copy so a cleanup decision does not remove your ability to inspect the original.

Check identifiers and formatting before opening or resaving files in spreadsheet software. Values that look like numbers may be identifiers, telephone numbers or postal codes. Preserve leading zeros where they are meaningful. For date-like text, document the source format and the intended destination format rather than assuming every system will interpret it the same way.

Assign someone to approve changes to the migration copy. A second person cleaning a different version can produce conflicting transformations that are difficult to reconcile later. Use a shared change log for the important decisions: which records are excluded, which values are standardised and which ambiguous cases are held for review.

Keep secrets out of the worksheet. API keys and database passwords belong in the integration’s appropriate secret storage, not alongside contact data or transformation notes. Restrict the working files to the people who need them and follow your organisation’s requirements for handling customer information.

02. Map fields, owners and relationships

A field map should explain what happens to every source column in scope. Record the destination object, destination field, type, transformation, validation rule and responsible person. Mark fields that will be excluded and give the reason. A blank mapping should mean an unresolved decision, rather than silently becoming an ignored column.

Pay special attention to values that contain more than one meaning. A column called “Account lead” may be a person’s name, an email address or a team label. The destination may require a record ID. Define how that value will be resolved and what happens when there is no match. Use a visible exception queue instead of assigning uncertain records arbitrarily.

Relationships need their own mapping. If contacts link to companies by an old company ID, keep that ID until the corresponding destination IDs are known. The migration may need to create parent records before linking dependent records, or use a supported multi-object import. Choose the sequence according to the actual importer or API.

HubSpot’s import documentation describes unique identifiers and association requirements for its own import process [1]. The transferable lesson is to inspect the destination’s identity and relationship contract. Do not assume that a display name, repeated row or shared column will create the intended association in every CRM.

03. Decide how duplicates and conflicts will be handled

Separate duplicate detection from the decision to merge. Two rows may describe the same person, but they may also represent different people with a shared mailbox or similar name. Decide which fields establish identity, which suggest a possible match and which cases require manual review. Keep the rule visible in the migration plan.

Define the winning value when duplicate records disagree. You might prefer a verified address over an unverified one or keep the most recent confirmed company link. “Use the latest row” is only meaningful if the source timestamp represents the kind of update you care about. A recent export time does not prove the underlying detail is current.

Preserve useful context during a merge. Notes, open opportunities and ownership can be lost if the migration keeps one row and discards the others without examining their relationships. Record the source identifiers that contributed to the surviving record so a question after launch can be traced back to the decision.

Do not repeatedly import until the totals look right. Confirm whether the destination creates new records, updates existing ones or performs both actions, and what identifier controls that behaviour. A rerun should be designed and tested. Otherwise an attempted correction can create another set of duplicates.

04. Test a representative sample

Choose sample records that exercise the model. Include a company with several contacts, a contact without a company, an opportunity with a missing optional value, a repeated source identifier and a record containing punctuation or accented characters. Include examples that should fail validation so you can confirm they are reported clearly.

Run the sample through the same transformation and import process planned for the full migration. A manually prepared demonstration can hide problems in the real workflow. Record accepted, updated, rejected and intentionally skipped entries, then inspect the destination through the interface the team will use.

Check relationships directly. Open an opportunity and verify its company, primary contact where supported, owner and next action. Search by both the display name and identifier if the product allows it. Confirm how dates, amounts and controlled choices are displayed and exported. Round-trip checks can expose a value that looks acceptable on screen but has been transformed incorrectly.

Ask a regular user to complete a short business scenario using the imported records. Can they continue the conversation without returning to the old system for essential context? If the answer is no, decide whether the missing information needs migration, an archive link or a documented operating process.

05. Reconcile counts and meaning

A reconciliation accounts for each source record in scope. For a simple create-only batch, the input count should equal created records plus rejected records plus intentionally skipped records, provided those categories are mutually exclusive. For a mixed create-and-update batch, include updates separately. Count source records according to the object being migrated, because one input row can represent several destination objects.

For example, a fictional batch of 120 company records might produce 112 new records, five rejected records and three intentional exclusions. The arithmetic reconciles, but the migration is not finished until the rejected records are resolved or explicitly accepted as exceptions. The example demonstrates the method; it is not a benchmark or a recommended error rate.

Validate the content as well as the count. Compare selected field values and relationship counts, check records with blank owners and examine entries at the edges of any date range. Where amounts are relevant, compare like-for-like totals using the same currency and inclusion rules. A matching grand total can still hide offsetting errors.

Keep a reconciliation record that identifies the source export, transformation version, import run and person who accepted the result. Document outstanding exceptions individually. That evidence makes post-launch investigation far easier than a message saying the import “looked fine”.

06. Plan the cutover and the changes in between

Agree when the old system stops being the place for new work. If users keep making changes while a migration is running, you need a way to capture and reconcile those changes. Options depend on the systems involved: an agreed editing pause, a supported incremental transfer or a controlled change log may be appropriate.

Name the person who runs the final migration and the person who verifies it. State which checks must pass before users switch, where issues will be reported and who can make the launch decision. Keep the plan accessible to the people involved so the process does not depend on one person being available in a private chat.

Do not delete the old records as part of an untested cleanup. Decide how long the source needs to remain available under your organisation’s retention requirements and which users should retain access. A read-only archive can preserve context while making it clear that operational changes belong in the new system.

If forms or integrations write records, include them in the cutover. Confirm the destination of new submissions, test a real end-to-end scenario with controlled data and make failures visible. A successful historical import does not prove that tomorrow’s enquiry will arrive in the right place.

07. Make recovery a usable plan

A backup is an input to recovery; it does not specify the recovery process. Decide which failures would trigger a rollback, who has authority to call it and what the team should do while the issue is investigated. Work through the sequence before launch so the plan reflects the actual systems and access available.

Account for new work created after the cutover. Restoring yesterday’s export can discard today’s contacts, notes and opportunities unless they are captured and reconciled. Your recovery plan should identify how those changes will be preserved, which source becomes authoritative during recovery and how integrations are paused or redirected if necessary.

Rehearse the parts of recovery that can be tested safely. Confirm that source exports can be read, access is available and the team knows the communication channel for an incident. Avoid claiming the plan works simply because a document exists. Record what was tested and what remains dependent on the provider or implementation team.

08. Review the result in normal work

After launch, monitor the issues the migration could plausibly create: missing owners, broken associations, unexpected duplicates, incorrect stages and failed incoming submissions. Have a named person review those issues and a consistent way for users to report them. Fix the underlying rule when a problem repeats rather than correcting the same kind of record indefinitely.

Use an ordinary pipeline or account review as an acceptance check. Can the team answer its normal questions with the migrated information? Can it find the context needed for the next conversation? Compare the result with the acceptance criteria agreed at the start, and record the decisions made about outstanding exceptions.

Download the field-mapping worksheet below to organise your own migration. It contains illustrative examples and a blank row for additional fields. Replace those examples with your source and destination definitions, and treat the file as planning documentation rather than something to upload directly to your CRM.

Common questions.