Español

Post-Migration Data Audit: What to Verify and When

A RevOps team signed off on their migration on a Friday afternoon. The import completed without errors. Row counts looked roughly right. The team went home.

Six weeks later, a marketing campaign launched and sent 14,000 emails. Bounce rate: 11%. The reason: 11% of contacts had blank email fields in the new CRM. The import had silently failed for records where the source data had email addresses in a slightly different column format. The error log had flagged them, but nobody had read it.

Six weeks of reps logging calls, updating deals, and building pipeline on top of 11% bad contact records. The cleanup took two weeks, required de-duplicating manually corrected records, and created enough confusion that three reps' pipeline forecasts had to be rebuilt from scratch.

A 30-minute audit on the day of migration would have caught it.

This guide gives you the three-tier audit process that prevents this scenario — structured by timeline, with specific checks at each interval. It builds directly on cutover day: the checklist that prevents disasters — the checks you run during migration are what this audit measures against in the hours that follow.

When to Run the Audit

Hour 1. Run this before the sales team has access. You're checking for critical failures — missing records, blank required fields, broken relationships. These are the problems that make the CRM unusable or misleading from minute one.

Hour 24. After the system has been live for a day, deeper integrity checks become possible. Relationships have had time to resolve. Duplicate detection has run. Automation rules have fired. Now you can check whether the data behaves correctly, not just whether it exists.

Hour 72. Three days post-go-live, business logic problems surface. Pipeline reports don't match pre-migration snapshots. Lead routing isn't working right. Automation is misfiring on imported records. These issues only become visible after the system is actually in use.

Why waiting until "week 2" is too late:

Every day the sales team uses the CRM, they layer new activity onto the existing data. Gartner's research on data quality estimates that the cost of fixing a data quality issue grows by 10x for every stage it progresses unchecked — catching problems in the first hour is orders of magnitude cheaper than finding them in week two. A contact with a blank email field that a rep emails on day two now has an activity record, a note, and a follow-up task attached. Cleaning that contact means either losing those records or manually migrating them to the corrected record. The earlier you catch problems, the cheaper they are to fix.

Tier 1: Critical Checks (Hour 1)

These checks happen before anyone except the migration team has access.

1. Row counts per object

Pull the record count for every migrated object from the new CRM and compare to your pre-migration source snapshot.

Object Source count Imported count Acceptable variance
Contacts [from source] [from CRM] ± 1% (error log explains remainder)
Accounts/Companies [from source] [from CRM] ± 1%
Deals/Opportunities [from source] [from CRM] ± 0.5%
Activities [from source] [from CRM] ± 2% (higher variance acceptable)

If you're more than 2% off on Contacts or Deals, don't open the system. Read the error log first. Significant discrepancies that can't be explained by the error log may meet your rollback trigger conditions — decide before you open access to the sales team.

2. Primary key completeness

Email is the primary key for Contacts. Phone is secondary. Check that these fields are populated at the rate you expect.

Run a quick filter: Contacts where Email is empty. If the result is more than 2-3% of your total contact count, you have an import failure or a source data problem. Either way, fix it before the team starts sending emails or making calls.

3. Open opportunities present with correct stages

Open deals need to be in the CRM with correct stage values. Filter for all open Opportunities. Check:

  • Total count matches source
  • Stage distribution roughly matches what you had in the source system
  • No deals defaulted to a generic stage because of a stage name mismatch

4. Error log review

Every CRM import tool generates an error log. Read it. Every row in that log represents a record that didn't import — either failed entirely or imported with a field value skipped.

Common error log entries:

  • "Record already exists" — duplicate detection stopped the import; decide whether to merge or skip
  • "Invalid email format" — the source data has malformed emails
  • "Required field empty" — the import skipped a required field; the record imported but is incomplete
  • "Value not in picklist" — a stage or status value in your source data doesn't match the CRM's options

Create a triage list: how many records, what error type, can it be batch-fixed or does it need manual review?

Tier 2: Data Integrity Checks (Hour 24)

After 24 hours, run a deeper layer of checks on relationships and field completeness.

1. Relationship integrity

Contacts without Accounts. Deals without Contacts. Deals without Accounts. These orphaned records are usable — but incomplete, and they'll accumulate confusion as reps try to use them.

For each orphan type, decide:

  • Was this intentional (the source data had no Account for these Contacts)?
  • Or is it an import error (the Account import failed, so the Contact has nothing to link to)?

If it's an error, fix it. If it's intentional, document it.

2. Custom field completeness on key objects

Pick your 5-10 most important custom fields (the ones sales uses for reporting or filtering). For each:

  • What % of relevant records have this field populated?
  • Does the population rate match the source system?

A custom field that was 80% populated in the source system should be roughly 80% populated in the destination. If it drops to 30%, the field didn't map correctly during import.

3. Duplicate detection scan results

Most CRMs run automatic duplicate detection on import or have a built-in scan you can trigger manually. Run it within the first 24 hours, before reps start adding data. If you skipped shadow import testing before go-live, duplicates are more likely — the shadow import is specifically designed to surface these before they hit production.

Review the duplicate report with this approach:

  • Exact email duplicates: merge immediately
  • Same name, similar company: flag for sales manager review before merging
  • Possible duplicates (similar name, different email): flag for manual review, don't auto-merge

4. Activity records linked to the right records

Take 20 random activity records (notes, call logs) from the import. For each:

  • Is it linked to a Contact?
  • Is it linked to the right Contact (not a duplicate or wrong person)?
  • Does the content display correctly (no encoding issues, no truncation)?
  • Is the date field populated and correct?

Tier 3: Business Logic Checks (Hour 72)

These checks require the system to have been in use. They catch problems in how the CRM behaves, not just what data it contains.

1. Pipeline reports match pre-migration snapshots

Before migration, export a snapshot of your pipeline: total open deal count, total pipeline value, deal count by stage, average deal size. Compare it to the same report in the new CRM at the 72-hour mark.

If the numbers are meaningfully different — more than 5% variance on total pipeline value — you have a data problem. Either deals didn't migrate, or deal values came in incorrectly, or stage mapping shifted deal distribution.

2. Lead routing rules firing correctly

If your CRM uses automated lead routing (new leads route to specific reps or territories based on rules), test it with a new record. Create a test lead that matches a routing rule and verify it routes correctly.

Imported records often trigger routing rules incorrectly if the routing is date-based or based on record creation date. A record created in 2023 that was imported on your migration date might have its creation date set to the import date — which fires routing rules that shouldn't apply to historical records. Check this within 72 hours before it creates a backlog of mismapped records.

3. Automation triggers not misfiring on imported records

This is one of the most common and damaging post-migration problems. If your CRM has automations that trigger on record creation — welcome emails, onboarding sequences, internal notifications — imported records may trigger all of them simultaneously. The Wikipedia article on workflow automation provides useful context on how trigger-based systems behave when large volumes of new records are inserted — and why suppressing automations during bulk imports is standard practice.

Most CRMs have an option to suppress automations during import. If you didn't use it, check whether any automations fired for the full import volume. If they did, you may have sent automated emails to every contact you migrated.

Check your automation activity log within 72 hours. If misfires happened, you'll need to either suppress future triggers on imported records or send a correction communication.

4. User assignment logic correct

Open 20 random Deals and 20 random Contacts. For each, verify the assigned rep matches what was in the source system. Incorrect rep assignment creates two problems: reps can't see records they own, and reps can see records they don't own.

Common causes: username format mismatch between source and destination (firstname.lastname vs. firstname_lastname), inactive users in the source who need to be reassigned, or a catch-all assignment that routed unmatched records to one user.

How to Document and Triage Findings

Severity classification:

Severity Description Example Fix timeline
P1 — Data loss Records missing entirely or critical fields blank 500 Contacts failed to import Before sales access
P2 — Data quality Records imported but with incorrect or missing values Custom field blank on 15% of contacts Within 24 hours
P3 — Business logic Automation or routing misfired Welcome emails sent to all imported contacts Within 72 hours
P4 — Cosmetic Display issues, formatting, minor inconsistencies Phone format inconsistency Within 30 days

Triage template:

For each finding, document:

  • Finding description
  • Severity level
  • Record count affected
  • Root cause (if known)
  • Remediation approach
  • Owner
  • Target fix date

Keep this as a shared document with the sales manager and IT lead. P1 and P2 issues should be resolved before reporting "migration complete" to stakeholders.

Communicating Audit Results to Stakeholders

What to tell the VP of Sales:

Lead with what's working. Give the count of Contacts, Accounts, and open Deals that migrated successfully. Harvard Business Review research on change management found that employees resist changes they don't understand — transparent, factual communication about migration status significantly reduces the skepticism that slows CRM adoption in the first weeks. Report any P1 findings with the fix timeline. Don't give a technical breakdown of every check — lead with business impact.

If there are meaningful issues: "We identified 220 Contacts with missing email fields. We're fixing this today and it won't affect any open deals. The issue was in the source data, not the import process." Communicating the migration to your sales team covers how to frame these conversations so they don't erode rep trust in the new system before adoption takes hold.

What to keep internal:

P3 and P4 findings don't need to go to the sales leadership. Handle them operationally and include them in a written summary at the 30-day mark.

How to manage expectations on known issues:

If there are issues that take more than a day to fix, tell the team proactively. "You may see some contacts without phone numbers this week — we're running a batch fix and it'll be resolved by Thursday." This prevents reps from logging support tickets and assuming the CRM is broken.

Common Pitfalls

Spot-checking instead of systematic scanning. Opening 10 random records and declaring success isn't an audit. It's optimistic guessing. Use the row count, field completeness, and relationship integrity checks as a structured process.

Skipping the business logic tier. Most teams only run Hour 1 checks and then open the system. Automation misfires and routing errors — the Hour 72 problems — are often the ones that damage rep trust and create ongoing noise in the CRM.

Not comparing to a pre-migration baseline snapshot. Without a snapshot of the source system taken immediately before migration, you can't definitively verify what should have migrated. Take a snapshot before every migration. Export the record counts and pipeline totals to a reference file.

Declaring success before the 72-hour window closes. The three-tier timeline exists because different problem types surface at different intervals. Closing the audit after Hour 1 is like checking if a patient's heart is beating and sending them home — it's a necessary check, but not a sufficient one.

What to Do Next

Schedule a 30-day data quality review after the 72-hour audit closes. This review looks at the data quality metrics that only become visible after a month of real use: field population rates, duplicate accumulation, records with missing relationships that reps have been working around.

For guidance on preventing problems before the import even runs, testing the migration with a shadow import covers how to catch most of these issues in a test environment before go-live.

And if the audit surfaces findings that require rollback consideration, rollback planning: hope you don't need it defines when and how to make that call — including what "rollback" actually means after 72 hours of live usage.

The audit itself connects directly to cutover day: the checklist that prevents disasters — the checks you run during migration inform what the audit should focus on in the hours that follow.

Learn More