How to Migrate Between SaaS Tools Without Losing Data

Switching SaaS tools is rarely a technical problem — it's a data and people problem. The new tool is usually ready in days. The migration of records, relationships, attachments, history, and team habits takes weeks, and it's where most projects fail. A botched migration loses customer history, breaks integrations, and trains the team to distrust the new system.

This guide walks through a 5-step migration process that works whether you're moving from one CRM to another, switching project management tools, or replacing an entire help desk. The same principles apply: plan before you move, export everything, validate before you cut over, and over-communicate with the humans whose work depends on the tool.

Why SaaS migrations fail

Before the process, understand the failure modes. Most migrations don't fail because the data is too hard to move — they fail because of one of these:

• Underestimating data complexity: Records reference each other (contacts belong to companies, deals reference contacts, tickets link to deals). Migrating records without their relationships produces orphan data.
• Attachment and file loss: The CSV export doesn't include file attachments, and nobody notices until a rep needs a signed contract that's gone.
• History and activity loss: Comments, email logs, call notes, and status change history often don't map to the new system's schema.
• Integration breakage: The old tool was wired to your billing system, Slack, and marketing automation. The new tool isn't. Cutover breaks the wiring.
• Poor team communication: Users show up Monday morning, the old tool is gone, the new tool feels different, and they blame the migration for every friction point — real or imagined.

Step 1: Plan the migration before exporting a single record

The planning phase sets the scope, timeline, and success criteria. Skipping it is the most common cause of blown timelines and budget overruns. Spend a week here; it saves three weeks later.

Inventory what actually lives in the old system

Before you can move data, you need to know what data exists. Document:

• Record types: Contacts, companies, deals, tickets, tasks, projects, custom objects.
• Volume: How many records of each type. This affects whether you can use CSV import or need API migration.
• Relationships: Which records reference which. A deal belongs to a contact, which belongs to a company. Tickets reference deals. Tasks reference projects.
• Attachments: Files attached to records, and total storage volume.
• Activity history: Comments, emails, calls, status changes, audit logs.
• Custom fields: Every custom field, its type, and which records use it.
• Integrations: Every tool connected to the old system, what flows in, what flows out, and the sync direction.
• Automations: Workflows, triggers, rules, reports, and dashboards that need to be rebuilt.

Define what moves and what stays

Not everything should migrate. Decide explicitly:

Decision	Typical choice	Why
Active records	Migrate	Team needs them daily.
Closed/won deals > 2 years old	Archive in old system (read-only)	Rarely accessed; clutters new system.
Inactive contacts (no activity 18+ months)	Archive or skip	GDPR cleanup opportunity.
Attachments on archived records	Archive with parent record	Don't carry dead weight.
Full activity history	Last 12–24 months only	Older history rarely referenced.
Duplicate records	Dedupe before migration	Don't import problems.

Build a field mapping document

This is the single most important artifact of the migration. For every field in the old system, document where it goes in the new system — or mark it as "not migrated." A simple spreadsheet works:

• Source object (e.g., Contact)
• Source field (e.g., "Lead Source")
• Source field type (text, picklist, date, etc.)
• Target object
• Target field
• Transformation needed (e.g., map 5 old picklist values to 3 new ones)
• Status (mapped, needs transformation, not migrating)

Every row should have an owner. Every transformation should have a rule. This document is what you test against in Step 3.

Set a realistic timeline

Migrations take longer than vendors suggest. A realistic timeline for a mid-size migration (10k–100k records, 25–100 users):

Phase	Duration	Key activities
Planning & inventory	1–2 weeks	Scope, field mapping, timeline
Cleanup & dedup	1–2 weeks	Clean source data before export
Test migration	1–2 weeks	Move a subset, validate, fix mappings
Integration rebuild	2–3 weeks (parallel)	Reconnect Slack, billing, marketing, etc.
Training & dry run	1 week	Train champions, run parallel
Production cutover	1 weekend	Final export, import, validation
Hypercare & old system read-only	2–4 weeks	Fix issues, keep old system accessible

Budget 6–10 weeks for a mid-size migration. Enterprise migrations run 3–6 months. Anything shorter is either trivial or unrealistic.

Step 2: Export and prepare the data

With the plan in place, export the data from the old system and transform it to match the new system's import format. The order of operations matters: clean first, export second, transform third.

Clean the source data before exporting

Migrating messy data into a clean new system just gives you a clean-looking messy system. Dedupe contacts, standardize phone number and address formats, fill required fields, archive inactive records, and fix picklist inconsistencies (e.g., "USA", "U.S.", "United States" all mapping to one value). Cleaning after migration is 5x harder because you're working in an unfamiliar system.

Choose your export method

Three options, in order of preference:

• Native export tool: Most SaaS tools offer CSV or Excel export per object. Fine for small migrations (<10k records) with simple relationships. Limited for attachments and activity history.
• API export: The vendor's REST or GraphQL API lets you pull records programmatically, preserving relationships via IDs. Required for complex migrations, large volumes, or when you need activity history and attachments. More setup, but far more complete.
• Third-party migration tool: Tools like Import2, Trujay, or Cirrus Insight specialize in SaaS-to-SaaS migration. They handle field mapping, relationships, and attachments. Worth the cost ($2k–$20k) for CRM and help desk migrations where data integrity is critical.

Handle the three problem children: attachments, history, and custom objects

These are the data types most likely to be lost in migration:

• Attachments: CSV exports don't include files. Use the API to download attachments and re-upload to the corresponding records in the new system. Verify file sizes and counts match.
• Activity history: Comments, emails, and status changes often live in separate API endpoints. Pull them as separate exports and import as "activities" or "notes" on the target record. Some history may not have a direct equivalent — decide whether to merge into a single note or drop it.
• Custom objects: If the old system has custom objects with their own relationships, map them carefully. The new system may not support custom objects at your plan tier, or may model them differently (e.g., as tags instead of records).

Step 3: Test the migration on a subset

Never run a full migration on cutover weekend without a test run. Pick a representative subset — 5–10% of records, including edge cases (records with the most custom fields, longest history, most attachments) — and migrate them to a sandbox or test instance of the new system.

Validate against the field mapping document

For each field in your mapping doc, verify the data arrived correctly. Common issues:

• Picklist values that didn't map (5 old values, only 3 new ones — where did the other 2 go?)
• Date formats that shifted (MM/DD/YYYY vs DD/MM/YYYY — silently wrong by months)
• Number fields that became text, breaking sorts and filters
• Relationships that broke (contact linked to wrong company, deal lost its primary contact)
• Required fields that were empty in the source and blocked import
• Special characters and emojis that corrupted during encoding conversion
• Attachments that uploaded but linked to the wrong record

Run a reconciliation report

Metric	What to check
Record counts	Source count = target count per object (or document why they differ)
Relationship integrity	Every child record has a valid parent
Attachment counts	Number and total size of files match
Required field coverage	No required field is empty in the target
Picklist value distribution	Distribution matches (no values silently dropped)
Sample record audit	Pick 20 random records, compare field-by-field

Fix every issue before the full migration. The test run exists to surface problems — if you find none, you weren't looking hard enough.

Step 4: Execute the production cutover

With a validated test migration, the production cutover is mostly execution. Schedule it for a low-traffic window — Friday night or weekend — and communicate the freeze window to the team in advance.

The cutover sequence

1. Freeze the old system: Announce a hard cutoff. No new records, no edits after a specific time. Ideally, set the old system to read-only.
2. Final export: Pull a fresh export from the old system to capture any changes since the test migration.
3. Transform and import: Apply the same transformation pipeline from the test run to the full dataset.
4. Validate: Run the reconciliation report against the full dataset. Don't skip this — a silent failure here means Monday morning surprises.
5. Rebuild integrations: Point Slack, billing, marketing automation, and any other integrations at the new system. Test each one.
6. Rebuild automations: Recreate workflows, assignment rules, and notifications in the new system. Test with real scenarios.
7. Switch DNS / SSO / bookmarks: Update any single sign-on configurations and shared bookmarks.
8. Announce go-live: Send the team clear instructions on where to log in and what to do if something's missing.

Keep the old system on read-only

Do not cancel the old subscription immediately. Keep it accessible in read-only mode for at least 30 days — longer for regulated industries. Users will need to look up old records, verify that data migrated correctly, and occasionally find something nobody thought to migrate. Budget for one extra month of the old subscription; it's cheap insurance.

Step 5: Manage the people side of migration

The technical migration is half the project. The other half is getting the team to actually use the new system. Migration projects that ignore adoption fail even when the data is perfect.

Communicate early and honestly

Tell the team about the migration before it happens, not after. Explain why you're switching (the old tool's limitations, the new tool's benefits), what will change for them, what won't, and what the timeline is. Acknowledge that there will be friction — pretending the new tool is flawless sets you up for backlash the first time someone can't find a feature.

Identify and train champions

Pick 2–5 power users from different teams to be champions. Train them first, deeply. They become the first line of support when colleagues have questions, and they provide honest feedback on what's confusing before go-live. Give them recognition — champions do real work.

Run parallel for a week if possible

For critical tools, run the old and new systems in parallel for 1–2 weeks. Users enter data in both, and you compare the results. This catches integration issues and gives users time to learn the new system without pressure. Not always feasible, but worth it for CRM and help desk migrations.

Provide just-in-time training, not a data dump

A 3-hour training session before go-live will be forgotten by week two. Instead:

• Record short (3–5 minute) video tutorials for the 10 most common tasks.
• Create a one-page quick reference card with the 20 things people do daily.
• Offer 15-minute office hours daily for the first two weeks.
• Set up a dedicated Slack/Teams channel for migration questions.
• Designate champions as first responders in that channel.

Common migration pitfalls (and how to avoid them)

Pitfall	Symptom	Prevention
Lost relationships	Contacts orphaned from companies, deals from contacts	Migrate parents before children; map IDs explicitly
Attachment loss	Files missing on migrated records	Use API export, verify counts and sizes
Picklist collapse	Values silently dropped or merged	Document every value mapping; validate distribution
Date corruption	Dates off by months or years	Standardize to ISO 8601 before import; test with known dates
Integration outage	Sync to billing or marketing breaks at cutover	Rebuild and test integrations in parallel before cutover
Duplicate import	Same record imported twice	Dedupe source data; use external ID to prevent re-import
Permission gaps	Users can't see records they should	Rebuild role hierarchy before import; test with real users
Automation silence	Notifications and assignments stop firing	Recreate and test automations before go-live
Historical data loss	Years of comments and emails gone	Decide retention window explicitly; migrate as notes if needed
Premature cancellation	Old system deleted before issues found	Keep read-only for 30+ days; export final backup

Post-migration: the first 30 days

The migration isn't done at cutover — it's done when the team trusts the new system. The first 30 days determine whether adoption sticks.

• Week 1: Daily office hours. Fix data issues fast — nothing erodes trust like "that record didn't migrate" going unfixed for a week.
• Week 2: Audit adoption metrics. Who's logging in daily? Who isn't? Address non-adopters directly.
• Week 3: Gather feedback systematically. What's confusing? What's missing? What workflows broke?
• Week 4: Decommission the old system only after confirming no critical data or workflow was lost. Export a final backup first.

When to hire migration help

DIY migration is realistic for small datasets (<10k records), simple schemas, and tools with robust CSV import. For anything larger or more complex, professional help pays for itself:

• Migration tools (Import2, Trujay): $2k–$20k depending on volume. Best for CRM and help desk migrations.
• Implementation partners: $10k–$80k. Best when you're also reconfiguring workflows, integrations, and reporting.
• Vendor's own migration team: Sometimes included in Enterprise plans; otherwise $5k–$30k. Get scope in writing.

The cost of professional help is almost always less than the cost of a botched migration — lost productivity, data recovery, and re-doing work that broke.

Key takeaways

• Plan before you export. The field mapping document is your most important artifact.
• Clean source data before migration — dedupe, standardize, archive.
• Test on a subset first. Always. No exceptions.
• Keep the old system read-only for 30+ days as a safety net.
• Treat adoption as part of the migration, not an afterthought. Champions and just-in-time training win adoption.
• For complex migrations, professional help pays for itself.

A successful migration isn't measured by whether data arrived in the new system — it's measured by whether the team trusts the new system six weeks later. Plan for both, and you'll avoid the all-too-common outcome of a technically perfect migration that nobody uses.