Migration method
Plan a migration as a ledger, not a weekend.
Four published migration ledgers, across files, knowledge bases, secrets, and chat, all follow the same nine steps. This page is that method, with each step linked to the ledger that shows what it looks like in practice.
You leave with a nine-step ledger structure, the four worked examples behind it, and an explicit statement of what these plans do not prove.
What a migration ledger is
A ledger is a written record of decisions, scope, owners, evidence, and unknowns, kept while you plan a move and updated as each check passes or fails. It exists so that the question “did we lose anything?” has an answer other than a memory.
Do not put workspace content, customer data, credentials, or export contents into the ledger. Record counts, owners, dates, and results.
The nine steps
- 1
Establish export authority
Name who is allowed to export what, under which account or administrator role, and what the export legally and technically covers. Individual and organization exports are different lanes; some scopes need approval, and an export is a snapshot that can complete with errors.
- 2
Inventory the source scope, not the byte count
Count the behavior you are moving: item types and counts, owners, versions, comments, links, permissions, public shares, integrations, automations, and the exceptions. Record what the export cannot see, because content the exporting account cannot access is simply absent. Keep secrets and customer content out of the ledger itself.
- 3
Test conversion fidelity on a pilot
Decide and then test every format conversion on representative or synthetic data in a non-production destination, before anything real moves. Destinations say plainly that fidelity is not guaranteed, exports of database views are partial, and repeated imports can duplicate rather than update.
- 4
Reconstruct access and permissions
Sharing is a system, and it does not travel inside an archive. Build the destination groups, collections, roles, administrators, identity path, guest access, recovery owners, and offboarding path before the data arrives, then test internal, external, and public access against it.
- 5
Decide who operates the destination
A successful import does not prove a service is operable. Name owners for identity, database, storage, mail, TLS, backups, restore, monitoring, upgrades, security response, user support, and incidents, and price that work as labor rather than assuming a salaried team absorbs it. Record the exact component, version, edition, and license of what you will actually deploy; source-available and open-source terms carry different obligations.
- 6
Prove backup and restore
A backup you have never restored is a belief. Restore configuration, application data, files, and the database into a clean environment, and confirm the destination can produce its own export afterwards. If a production responsibility has no named owner and no tested failure path, pilot a hosted option or stop.
- 7
Reconcile totals against the source
Compare counts and representative records item by item, not impressions: people, containers, documents, messages, files, threads, attachments, permissions, integrations, and search. Run a final delta for everything created after the export snapshot.
- 8
Gate the cutover
Cutover is a decision with named approvers and written criteria, not a date. Validate an authorized export in staging and prove files, permissions, search, calls, identity, integrations, backup restore, and rollback first. Anything the pilot could not reproduce is either a shrunken scope, an explicit coexistence period, or a stop.
- 9
Keep a rollback
Keep the source live and paid for through an agreed rollback window with a named approver, and only then retire it. Clean up afterwards: delete temporary export copies, rotate high-consequence credentials, and record who owns the deletion.
The four ledgers
Each one runs the same method against a different failure mode. Read the one closest to your move, then reuse the structure for the rest.
| Ledger | What it adds to the method |
|---|---|
| Google Drive to Nextcloud | Individual versus organization export authority, and conversion decisions for native documents, comments, versions, and shortcuts. |
| Notion to Outline or AppFlowy | Import fidelity that the destination itself will not guarantee, and a license boundary that changes what you may deploy. |
| 1Password to Bitwarden | A secret-free inventory, a synthetic pilot because imports do not deduplicate, and a bounded plaintext interval. |
| Slack to Mattermost | The operator hours nobody quotes, the export scope that depends on your plan, and a costed self-managed path. |
What these ledgers are not
They are planning kits, assembled from vendor documentation and primary sources. They tell you what to check and in what order. They are not evidence that a migration has been run, and no measured migration data exists on this site yet: there are no observed hours, no observed durations, and no customer results behind any of these pages.
Where a ledger contains numbers, as the Slack scenario does, they are editable assumptions rather than vendor quotes or observed costs. A calculated scenario is not a migration benchmark. Replace every assumption with a dated invoice, a quote, or an explicitly marked unknown before you make a decision with it.
Vendor behavior also moves. Re-check export scope, import fidelity, licenses, and pricing against the primary sources cited in each ledger before you rely on them.
The two questions to settle before step one
A migration plan answers “how”. These two answer “whether”, and they are cheaper to run than any of the nine steps.
- Can you actually leave? Score the export you have already tested against export, open, restore, operate, and reconcile, rather than trusting that a download button is an exit.
- What does the move cost? Price implementation, the annual run, and the one-time cost of leaving, including the operator hours the license price never contains.
Get the next migration ledger
One maintained recipe each week. Explicit opt-in, no vendor-paid ranking, unsubscribe any time.