Switch apps after the replacement fits the workflow and a representative sample reconciles. Name one migration owner, one authoritative system at each stage, and a rollback condition before the final move. A successful import message is not migration acceptance.
Inventory the dependencies
List the people, records, files, integrations, automations, shared links, and reporting processes that depend on the source. Identify the account with authority to export and the people who must approve access in the destination. Keep credentials out of migration notes.
Rehearse with a small sample
Use the export check and import representative non-sensitive records into a test workspace. Reconcile counts, files, dates, links, and ownership. A successful import message does not establish a complete move.
Plan the cutover and rollback
Choose a point at which edits stop in the source and begin in the destination. Decide how to capture changes made during the move and who can call a rollback. Keep a recoverable source copy until the destination has been reconciled and accepted by the people using it.
Use a cutover sheet
Make the final move small enough to reconcile and clear enough that everyone knows where to work:
| Item | Decision to record |
|---|---|
| Scope | Which records, files, and active projects move; what remains archived |
| Freeze | When edits stop in the source and who can make an exception |
| Last changes | How updates after the first export reach the destination |
| Reconciliation | Expected counts and representative records to inspect |
| Acceptance | Who confirms that the workflow can continue |
| Rollback | What failure stops the cutover and where work resumes |
Avoid a vague “move everything this weekend” plan. An inactive archive and a current operational queue may need different handling. Record the treatment of each rather than silently dropping material that is inconvenient to import.
Rehearse the handoff as a normal user
An administrator may be able to see records that a teammate cannot. Ask the people receiving the work to locate a current item, open its supporting file, update it, and find the change again. Check those permissions before declaring the destination ready.
For an illustrative task-board move, a successful result would include preserving the task owner and due date, identifying where comments went, and rebuilding any essential link that did not transfer. If the destination cannot represent a relationship, decide on a documented substitute before the final import rather than leaving people to infer it.
Keep one place authoritative
During rehearsal, the source stays authoritative. After an accepted cutover, tell people where new work belongs and what the old system is for. Two editable “current” copies create a reconciliation problem immediately.
Retaining a recovery copy does not mean retaining every live integration or every former user’s access indefinitely. Review both deliberately under your own policies. A completed migration includes ownership and access decisions as well as moved records.
Rehearse a rollback before it becomes urgent
For a fictional task-board move, decide that a missing approval discussion or inaccessible required file stops cutover. If either is found before acceptance, keep the source authoritative, record destination-only edits, and reconcile those edits before restarting. Do not simply tell users to resume in the source while ignoring work created in the destination.
A rollback record needs the trigger, decision maker, source recovery point, destination-only changes, and message telling users where to work. Rehearse this with the sample. The purpose is to show that work can continue, not merely that old files still exist.
Close the loose ends after acceptance
Update shared links, integrations, access, and procedures. Keep the accepted archive and recovery information under your retention process. Verify cancellation and renewal terms separately; accepting a new workspace does not cancel the old agreement.
Use export acceptance to decide what must survive and the subscription audit to verify the old cost and access have actually been resolved. Retire the source only after the named owner accepts the destination and the recovery decision.
By Ranker.dev · Editorial standards · Suggest a correction
Ranker.dev is an independent software directory and publication. It is not affiliated with Ranker, Inc. or ranker.com.