Data Migration Best Practices for Email Lists: CRM Switches, Platform Moves and Consolidation
On this page
When Migration Happens
Email list migration happens when you switch CRMs, change email marketing platforms, consolidate multiple systems, merge companies after an acquisition, or move from spreadsheets to a proper platform. Every migration carries the risk of losing data, breaking automations and damaging deliverability.
This guide covers how to migrate email lists without those problems.
Common Migration Scenarios
CRM switch. Moving from one CRM to another (e.g., Salesforce to HubSpot, Pipedrive to Salesforce). The most complex migration because CRMs hold relationships between contacts, companies, deals and activities.
ESP switch. Moving from one email marketing platform to another (e.g., Mailchimp to ActiveCampaign). Simpler than CRM migration but requires careful handling of subscriber status, tags and engagement history.
Consolidation. Combining multiple lists, databases or systems into one. Common after acquisitions, department mergers, or when replacing a patchwork of spreadsheets with a unified platform.
Spreadsheet to platform. Moving from Excel/Google Sheets to a CRM or ESP for the first time. Requires structuring unstructured data.
Planning Phase
Audit the source data
Before migrating anything, understand what you have.
Inventory all data sources:
- Primary CRM or ESP.
- Secondary systems (other CRMs, ESPs, project management tools).
- Spreadsheets (local files, shared drives, personal files).
- Third-party tools (webinar platforms, form builders, event systems).
- Email archives (Outlook PSTs, Gmail exports, EML files).
Assess data quality in each source:
- Total records.
- Percentage with email addresses.
- Duplicate rate (within each source and across sources).
- Data completeness (how many fields are populated).
- Data freshness (when was the last update).
- Format consistency (are phone numbers, names and addresses standardised).
Map the data
Create a field mapping document that shows how every field in the source maps to a field in the destination.
| Source field | Source format | Destination field | Destination format | Transformation needed |
|---|---|---|---|---|
| Mixed case | Lowercase | LOWER() | ||
| First Name | Mixed, sometimes full name | firstname | Title case | Split if needed, PROPER() |
| Company | Various formats | company | Standardised | Remove Inc/Ltd, title case |
| Phone | Various formats | phone | E.164 | Strip formatting, add country code |
| Created Date | MM/DD/YYYY | create_date | YYYY-MM-DD | Reformat |
| Tags | Comma-separated string | tags | Array | Split on comma |
Fields that need special attention:
- Opt-out/unsubscribe status. This must be migrated perfectly. Emailing someone who unsubscribed is both a legal violation and a trust violation.
- Bounce history. Hard-bounced addresses should remain suppressed in the new system.
- Engagement history. Open/click data helps with segmentation. Not all platforms export this.
- Custom fields. Fields specific to your business (lead score, customer tier, product interest) need corresponding fields created in the destination before import.
- Relationships. Contact-to-company associations, deal linkages, activity history. CRM migrations must preserve these.
Define success criteria
Before migrating, define what "success" looks like:
- Record count matches (within acceptable tolerance for intentional deduplication).
- All opt-out records preserved.
- All suppression lists transferred.
- Key automations rebuilt and tested.
- No duplicate records created.
- Engagement data accessible for segmentation.
- No unintended emails triggered during migration.
Cleaning Phase
Migration is the best time to clean your data. You are touching every record anyway. Clean before you move, not after.
Extract and deduplicate
Export all source data. Upload each export to Email Extractor to extract and deduplicate email addresses across sources. The tool handles CSV, XLSX, JSON, VCF and 15 other file formats, and deduplicates case-insensitively.
This gives you a clean, deduplicated master list of email addresses. Then match this list back to your full records to identify which source record to keep for each unique email.
Verify email addresses
Run the deduplicated list through an email verification service before importing into the new platform. Do not migrate known-bad addresses.
- Remove hard bounces.
- Flag risky addresses (catch-all, disposable, role-based).
- Remove syntax errors.
See Best Email Verification Services and How to Clean an Email List.
Standardise formats
Apply normalisation rules before import:
- Email: lowercase, trimmed.
- Names: title case, split into first/last.
- Phone: E.164 format.
- Company: standardised (remove legal suffixes, consistent capitalisation).
- Dates: ISO 8601 (YYYY-MM-DD).
- Country: ISO 3166-1 alpha-2 codes.
- Tags/categories: consistent taxonomy.
See Data Normalization Workflows.
Handle duplicates across sources
When the same email appears in multiple source systems with conflicting data:
Resolution rules (define these before starting):
- Most recent wins. The record updated most recently is the authority. Good for contact details.
- Most complete wins. The record with more populated fields is the authority. Good for enrichment data.
- Source hierarchy. Designate a priority order for sources (e.g., CRM > ESP > spreadsheet). The highest-priority source wins conflicts.
- Manual review. For high-value contacts (enterprise accounts, top customers), flag conflicts for human review instead of automated resolution.
Pre-Migration Testing
Test with a small batch
Never migrate your entire database in one go. Start with a test batch.
Test batch composition:
- 100-500 records.
- Include records from each source system.
- Include records with edge cases (special characters in names, international phone numbers, long company names).
- Include at least one unsubscribed contact and one hard-bounced address.
Validate the test batch
After importing the test batch into the destination:
- Record count. Did all records import?
- Field mapping. Open individual records and verify every field mapped correctly.
- Opt-out status. Verify unsubscribed contacts are marked as unsubscribed.
- Relationships. Verify contact-to-company associations (CRM migrations).
- Tags and segments. Verify tags imported correctly and segments populate.
- Automations. Verify the import did not trigger unwanted automations (welcome emails, nurture sequences).
Disable automations during migration
Before the full migration:
- Pause all email automations and workflows in the destination system.
- Disable triggered emails (welcome emails, follow-ups, reminders).
- Disable form notifications if forms are already connected.
- Document everything you paused so you can re-enable after validation.
Execution Phase
Migration order
For CRM migrations, order matters because of record relationships:
- Companies/Accounts first (no dependencies).
- Contacts second (link to companies).
- Deals/Opportunities third (link to contacts and companies).
- Activities fourth (link to contacts and deals).
- Suppression lists (must be in place before any email is sent).
For ESP migrations:
- Suppression/unsubscribe list first (non-negotiable).
- Contact records with tags and custom fields.
- Segments and lists.
- Templates and automation workflows (rebuilt, not migrated, in most cases).
Batch import
Import in batches rather than all at once:
- 5,000-10,000 records per batch.
- Verify each batch before importing the next.
- Keep a log of what was imported, when, and from which source.
- Maintain a rollback capability (keep the source data untouched until migration is fully validated).
Handling opt-outs and suppression
This is the most critical part of the migration.
- Export the complete unsubscribe/opt-out list from the source.
- Import it into the destination BEFORE importing any contacts.
- Verify the suppression list is active and working.
- Test by attempting to send to a suppressed address (it should be blocked).
Common mistake: Importing contacts into a new platform without the suppression list, then triggering a welcome email to contacts who unsubscribed from the old platform. This violates CAN-SPAM, GDPR, CASL and other regulations, and generates spam complaints that damage your new platform's reputation.
Post-Migration Validation
Verify record counts
| Source | Expected count | Migrated count | Difference | Explanation |
|---|---|---|---|---|
| CRM contacts | 25,000 | 23,847 | -1,153 | Duplicates merged, invalids removed |
| ESP subscribers | 18,000 | 16,922 | -1,078 | Duplicates merged with CRM contacts |
| Spreadsheet contacts | 3,000 | 2,541 | -459 | Duplicates, invalids removed |
| Total unique | N/A | 23,847 | N/A | After deduplication |
Spot-check records
Randomly select 50-100 records and verify:
- All fields populated correctly.
- Opt-out status preserved.
- Tags and categories correct.
- Company associations correct (CRM).
- Engagement history accessible (if migrated).
Test email sending
Before resuming normal operations:
- Send a test email to an internal list.
- Check deliverability (inbox, spam folder, not delivered).
- Verify personalisation tokens render correctly.
- Verify unsubscribe links work and connect to the new suppression system.
- Verify tracking (opens, clicks) works in the new platform.
Re-enable automations
After validation:
- Review each paused automation.
- Adjust trigger criteria if needed (field names may differ in the new system).
- Enable automations one at a time.
- Monitor for unintended triggers (did re-enabling a workflow send to the entire migrated list?).
Deliverability During Migration
Warm up the new platform
If you are moving to a new sending IP or domain, you cannot immediately send at full volume.
Warm-up schedule:
- Week 1: Send to your most engaged contacts only (recent openers, clickers). 500-1,000 per day.
- Week 2: Expand to moderately engaged contacts. 2,000-5,000 per day.
- Week 3: Expand further. 10,000-20,000 per day.
- Week 4+: Gradually increase to full volume.
Authentication setup
Before sending from the new platform:
- Configure SPF to include the new sending service.
- Set up DKIM with the new platform's signing keys.
- Update DMARC policy if needed.
- Verify with a test send and check authentication headers.
See SPF, DKIM, and DMARC Explained.
Monitor closely
For the first 2-4 weeks after migration:
- Watch bounce rates per send.
- Monitor spam complaint rates.
- Check Google Postmaster Tools and Microsoft SNDS.
- Compare open and click rates to pre-migration benchmarks.
Rollback Planning
Have a rollback plan before you start.
Keep the source system active. Do not decommission the old platform until the new one is fully validated and running for at least 2-4 weeks.
Maintain source data exports. Keep complete exports from every source in a secure location.
Document the migration. Every step, every batch, every decision. If something goes wrong, you need to know exactly what was done and what to undo.
Define rollback triggers. Under what circumstances would you revert? Examples: more than 5% of records lost, suppression list not functioning, deliverability drops below acceptable threshold.
Migration Checklist
Planning:
- Inventory all data sources.
- Create field mapping document.
- Define deduplication and conflict resolution rules.
- Define success criteria.
- Create rollback plan.
Cleaning:
- Export all source data.
- Extract and deduplicate with Email Extractor.
- Verify email addresses.
- Standardise formats.
- Resolve cross-source duplicates.
Testing:
- Import test batch (100-500 records).
- Validate all fields, opt-outs, relationships.
- Confirm no automations triggered.
Execution:
- Disable all automations in destination.
- Import suppression list first.
- Import records in batches (correct order for CRM).
- Log each batch.
Validation:
- Verify record counts.
- Spot-check 50-100 records.
- Test email sending.
- Re-enable automations one at a time.
Post-migration:
- Warm up new sending infrastructure.
- Monitor deliverability daily for 2-4 weeks.
- Keep source system active for 2-4 weeks.
- Decommission source system only after full validation.