Every data migration checklist you find online was written for data engineers moving warehouses. They assume you have staging environments, ETL pipelines, and weeks to plan. But the migration most teams actually face is simpler and more urgent: you're switching CRMs, replacing a billing tool, or graduating from a spreadsheet to a real platform. You need the data in the new tool by Friday, and you have no data engineer on staff.
This is a data migration checklist built for that scenario. It works as a database migration checklist too, if your app's Postgres is the source. Twelve steps for moving data between SaaS tools without losing records, breaking field mappings, or spending a month on a project that should take a day. For the fundamentals of what data migration is and the types you'll encounter, see our guide to data migration.
The data migration checklist starts before you move anything
Most failed migrations fail before the first record transfers. The source audit is where you catch the problems that would otherwise surface as missing fields, broken references, and mysterious blank records in the new tool.
Step 1: Inventory your source data. Open your source tool and list every record type you need to migrate. For a CRM migration, that's contacts, companies, deals, and activities. For a billing tool switch, it's customers, subscriptions, invoices, and payment methods. Write them down. If you don't have a list, you'll forget something.
Step 2: Audit field completeness. For each record type, check which fields are actually populated. A CRM with 15,000 contacts might have email on 98% of records but phone number on only 40%. This matters because your field mapping decisions depend on what data actually exists, not what fields are theoretically available.
Step 3: Identify your matching key. How will you link records between the old tool and the new one? Email is the most reliable matching key for contacts. Company domain works for organizations. If your source data doesn't have a consistent unique identifier, you need to create one before migrating, or you'll end up with duplicates.
Step 4: Document custom fields and picklist values. Standard fields (name, email, company) map easily. Custom fields are where migrations break. Your old CRM has a "Lead Source" picklist with 12 values. Your new CRM has a similar field but uses different labels. Map every custom field and every picklist value before you start transferring data.
Data migration checklist: field mapping and data type alignment
Field mapping is where you decide what goes where. Get this wrong, and you end up with phone numbers in email fields and dates formatted as strings.
Step 5: Create a field-by-field mapping document. For each record type, build a table with three columns: source field name, destination field name, and any transformation needed.
Source (old CRM) | Destination (new CRM) | Transformation |
|---|---|---|
Full Name | first_name + last_name | Split on first space |
Company | organization_name | Direct map |
Phone | phone_number | Convert to E.164 format |
Lead Source | lead_source | Remap picklist values |
Created Date | created_at | ISO 8601 conversion |
This table is your data migration plan example in its simplest form. It eliminates guesswork during the actual transfer and gives you a reference for data migration validation afterward.
Step 6: Handle data type mismatches. The old tool stores dates as "MM/DD/YYYY" strings. The new tool expects ISO 8601 timestamps. The old tool stores currency as a formatted string ("$1,234.56"). The new tool expects a decimal number (1234.56). Identify every mismatch and define the conversion rule before running the migration.
Step 7: Decide what not to migrate. Not every field deserves a new home. Internal notes from three years ago, deprecated custom fields, and system-generated metadata (like "last login timestamp" that won't carry meaning in the new tool) should stay behind. Migrating everything is a common data migration best practice to ignore. Migrate what your team will actually use.
Test your data migration on a small batch first
Never run a migration on your full dataset first. A test migration catches mapping errors, data type issues, and edge cases before they affect every record.
Step 8: Select a representative test batch. Pick 50-100 records that cover your edge cases. Include records with custom fields populated, records with empty required fields, records with special characters in names, and records with the oldest and newest creation dates. A random sample misses edge cases. A deliberate one catches them.
Step 9: Run the test migration and inspect results. Transfer the test batch to the new tool. Then check every field on at least 10 records manually. Verify that names didn't get truncated, dates landed in the right format, picklist values mapped correctly, and no fields are blank that should be populated. This manual review takes 30 minutes and saves days of cleanup later.
Step 10: Fix mapping issues and run again. If the test batch reveals problems (and it will), fix the field mapping, adjust the transformation rules, and run the test again. Repeat until a test batch transfers cleanly. Two or three iterations is normal.
Data migration validation: verify counts, fields, and integrity
After the full migration runs, you need proof that it worked. Record counts alone are not enough. A migration can transfer the right number of records while dropping half the fields on each one.
Step 11: Run a three-level validation check.
Record count validation: Compare the number of records in the source against the destination. For each record type (contacts, companies, deals), the counts should match within 1-2%. Small discrepancies from duplicate handling are normal. Large gaps mean records were dropped.
Field completeness validation: For your five most important fields, compare the percentage of non-empty values in the source versus the destination. If email is 98% populated in the source but only 85% in the destination, the mapping dropped records.
Data integrity spot check: Pull 20 records at random and compare every field value between source and destination. This catches formatting issues, truncation, and mapping errors that aggregate counts miss.
Validation type | What to check | Acceptable threshold |
|---|---|---|
Record count | Total records per type | Within 1-2% of source |
Field completeness | Non-empty % on key fields | Within 1% of source |
Spot check | Field-by-field on 20 records | 100% match required |
This is the most skipped step on every data migration checklist, and it's the most important. A migration that "completed successfully" but dropped 15% of phone numbers is worse than one that failed with an error message, because nobody knows the data is wrong until a rep calls a blank number.
After the data migration checklist: ongoing sync replaces repeat migrations
The traditional data migration plan treats the migration as a project with a start and end date. Move the data, validate, decommission the old system. But SaaS tool transitions don't work that way.
Step 12: Set up ongoing sync for the transition period. Your team will use both tools during the switch. New leads come into the old CRM because integrations haven't been updated. Existing deals progress in the new CRM. Without ongoing sync, the two systems diverge within hours.
The better approach: treat migration as sync with a starting point. The initial transfer is a backfill that moves all historical records. Then incremental sync keeps both tools aligned every 15 minutes during the transition. When your team has fully moved to the new tool, stop the sync and decommission the old one.
This is where most published data migration best practices fall short. They end with "validate and decommission." They don't address the transition period where your team uses both systems and data drifts in both directions.
With Oneprofile, the migration and the ongoing sync are the same configuration. Connect the source, connect the destination, map fields, enable backfill. The first run migrates everything. Subsequent runs sync changes incrementally. Property-level change tracking ensures only fields that actually changed get updated in the destination, reducing API calls and preventing overwrites. If a record fails during migration (rate limit hit, field validation error), it lands in a dead letter queue for review instead of being silently dropped.
The transition from migration to ongoing sync happens automatically. No second tool, no new configuration, no re-mapping fields. The same sync that migrated your data keeps it current until you're ready to cut over.
How long does a SaaS data migration take?
Most SaaS tool migrations (CRM to CRM, spreadsheet to CRM) finish in under a day. The migration itself takes minutes. The verification and transition period takes a few days.
Do I need a data engineer to migrate between SaaS tools?
No. SaaS tool migrations involve mapping fields between two APIs with well-defined schemas. A sync tool with field mapping handles it without writing code.
What is the most common cause of data migration failure?
Skipping the source audit. Teams start migrating before understanding what fields exist, which are populated, and how data types differ between source and destination.
Can I keep both tools running during migration?
Yes. Run the initial migration, then enable incremental sync. Both tools stay current during the transition. Cut over when you've verified the new tool is complete.