A migration is a change to a working system, not just a new subscription. Before you move, establish what must survive, how you will verify it and how you will get back. This framework turns a vague switch into a decision you can review.
Evidence correction: the earlier version presented migration percentages, averages and risk scores without a published dataset or test records. Those figures have been removed. The framework below is editorial planning guidance; it does not estimate population failure rates or promise a completion time.
First decide whether switching is worth it
Write the problem as a requirement: “Our support team cannot see the customer’s previous conversation” is useful. “The new dashboard looks cleaner” is a preference. Name the current limitation, the proposed replacement and the smallest workflow that would prove the replacement solves it.
Compare the expected benefit with subscription cost, implementation work, retraining, duplicated bills and the risk of losing information. If a configuration change in the current tool solves the problem, try that before moving the whole system.
A migration worksheet you can copy
| Decision | Record before you start | Acceptance check |
|---|---|---|
| Data | Objects, fields, attachments, comments and permissions | Counts reconcile; sampled records remain readable and correctly linked |
| Automation | Trigger, conditions, action, owner and credentials | One realistic example completes and a failure creates an alert |
| Identity | Accounts, roles, invitations and external collaborators | Each role sees the right records; a denied role cannot access them |
| URLs and integrations | Public links, webhooks, embedded forms and API clients | Existing links and callers reach the intended destination |
| Billing | Renewal date, cancellation terms, usage and overlapping plans | You know when the old bill stops and what the new bill includes |
| Recovery | Backup location, restore owner and cutover reversal | A sample restore works before you delete the source |
Run a representative rehearsal
Use a disposable copy of a small, realistic project. Include a busy record with comments and attachments, a relationship between records, one automation, and an account with restricted access. A successful import of plain text proves little about these harder cases.
- Export and store a read-only source copy.
- Import into an isolated destination and record warnings.
- Compare totals, then inspect the representative records manually.
- Exercise integrations and permissions from each user’s perspective.
- Export from the destination and try the recovery path.
- Record unresolved gaps and decide whether to continue.
Record hands-on work separately from elapsed waiting. Domain verification, account approval, email delivery and colleague availability can dominate the calendar even when the technical steps are short. Build your estimate from the rehearsal, with contingency for the gaps it exposes.
Different switches have different failure modes
- Notes and project systems: inspect linked databases, mentions, attachments, archived projects and shared permissions. A Markdown or CSV export may not preserve the behaviour of the original workspace.
- Newsletter platforms: reconcile subscriber consent, suppression lists, paid subscriptions and sending-domain configuration. Never treat an exported address list as permission to contact everyone.
- Websites: inventory existing URLs, map redirects, check forms, analytics choices and search indexing. Follow Google’s site-move guidance; a redesign is not a reason to discard valuable URLs.
- Databases and authentication: plan schema, identifiers, permissions, credentials and service dependencies separately. Compare the vendor’s actual migration procedure with your application’s requirements.
- AI assistants: a personal chat subscription can be easy to change; an application depending on an API, saved workflows, connectors or a shared knowledge base is a different migration.
Cut over only when the checklist passes
Assign an owner and a rollback decision point. Tell collaborators which system is authoritative, pause writes during the final transfer if necessary, reconcile again, and keep the source available for the recovery period you agreed. Avoid cancelling a plan just to stop a duplicated bill before you have verified the replacement.
A useful decision log records what changed, why, known losses, the current owner and where the backup lives. It makes a future rollback or a second migration easier to assess.
Explore a specific switch
The switch directory contains starting outlines for named migrations. Treat any time or risk labels there as planning estimates and validate the current vendor instructions for your data. For a new selection, use comparisons and the evidence policy to distinguish editorial judgement from measured results.