Short answer
Migrating data when switching SaaS is more than downloading an export file: relationships, files, history and permissions must be matched, a trial run made with sample data and the cut-over planned. Success is measured by record and relationship reconciliation and by critical workflows working in the new system.
Is an export sufficient?
Downloading a CSV does not mean relationships, attachments, history and permissions will migrate. Map source and destination data types, relationships and identifiers.
Rehearse the migration
Test mapping and transformation rules with sample data. Check totals, date ranges and relationship integrity alongside record counts. Failed records should not be silently discarded.
Plan the cut-over
Allowing uncontrolled writes in both systems can create conflicting records. Define write freezes, final change transfer, user transition and rollback steps.
What is often forgotten in a migration
While the records themselves are moved, these are often forgotten: comments and activity history, attachments, permissions and roles, automation rules and integration credentials. Write down up front which of these will be migrated, which rebuilt and which archived.
Define success
Authorised users must complete critical workflows, and record and relationship checks must pass. Before retiring the old system, agree on archive, contractual and retention needs with the responsible teams.
Frequently asked questions
Two questions we are often asked on this topic.
How long should I keep the old system open?
Until reconciliation is complete, archive and retention needs are clear and the responsible teams have approved. Closing early can mean lost evidence if problems come up later.
What if data is lost during the migration?
Trial migration and reconciliation checks exist to prevent that. Faulty records must not be skipped silently; why they did not move should be reported, and the migration is not complete until they are resolved.
