How to switch business tools without losing your data

Switching software is the cost that never appears on a pricing page, and the part that goes wrong is rarely the import into the new tool. It is what the export from the old tool silently drops: ownership, history, comments, attachments and the links between records. This note is a checklist built from the vendor documentation read for the reviews on this site, not from a migration anyone here performed, and it is organized in the order the work should happen: establish what the old tool can export, decide what has to survive, check the round trip on a small set, and only then schedule the cutover. Where a review names a specific export limit or a published API, it is cited; where the documentation is silent, that is said too.

Start with what the export preserves, not whether it exists

Every tool reviewed on this site can export something, and the Airtable review states the useful version of the question: can data be exported? Yes, and the question that matters is what the export preserves. A CSV of a table keeps the cells and loses the links between tables, the attachments, the comment threads and the revision history. A project export from a task tool typically keeps task titles, assignees and dates and loses the dependency chain, the custom field definitions and the automation rules. The reviews name the structural features most likely to be lost: Asana's single-owner tasks and dependencies, Airtable's cross-table links and per-base revision history, Notion's page history, which is 7 days on Free and 30 on Plus and therefore already gone for anything older. Open the vendor's export documentation and list, field by field, what the export format carries. If the documentation does not say, export a small real sample and look.

Ownership, permissions and the people who left

Ownership is the field most often corrupted in a migration, because the new tool needs an account for every assignee and some of those people no longer work there. Before exporting, reassign work owned by departed staff to current staff in the old tool, where the history is intact, rather than in the new tool, where the record will arrive with a blank owner. Check what the old tool does with content owned by a deactivated user: some archive it, some reassign it to an admin, some leave it visible but uneditable. The 1Password Business documentation, for example, describes thirteen distinct vault permissions covering whether a person can view, edit, create, export, share or reveal items, and an export of a shared vault depends on the exporting account holding the export permission on every vault involved. For a credential manager, that is the difference between a complete migration and one that silently leaves a vault behind. Permission structures do not migrate; they are rebuilt, and the rebuild should be designed before the export, not after.

History, comments and the things that cannot be re-created

Decide early which history has to survive and which can be archived as a read-only export. Chat history is the clearest example: the Slack review cites the help center statement that free workspaces hide content older than 90 days and may delete data older than a year, so a team on the free tier that has been meaning to export its history may already have lost part of it. Comment threads on tasks, cards and records almost never import cleanly into a different tool's comment model, and the practical approach is to export them as text attached to the record rather than to attempt a structural import. Attachments are their own problem: Trello's free tier allows 10 MB per file and Standard 250 MB per file per the pricing page, so an import into Trello from a tool with larger attachments will fail on the large ones. Where history cannot be re-created in the new tool, keep the old account alive on the lowest tier for a defined period, or keep a complete export in an open format, and write down which of the two was chosen.

• Must survive and be editable: open work, current owners, due dates, the custom fields the team actually uses.
• Must survive as reference only: closed work, comment threads, old versions, resolved tickets.
• Can be discarded after an archived export: automation logs, notification settings, most dashboards.

Integrations and automations are rebuilt, not moved

No export carries the integrations or the automation rules. Pipedrive's plan documentation lists import and export on every plan and automations only from Growth upward; a team exporting from Pipedrive carries the deals and loses the sequences. Zoho CRM's comparison page publishes API credit limits per edition, 5,000 per day on Free and 100,000 on Starter and Standard, which bounds how fast a scripted export can run and may turn a one-evening job into a several-day one on the free edition. The Xero and Zendesk reviews both note public, well-maintained API documentation, and for either tool an API-driven export is the way to get the relationships rather than the rows. Before cutover, inventory every connected app and every automation rule in the old tool, and for each one decide whether it is rebuilt in the new tool, replaced by a connector, or dropped. The automation quota of the new tool's tier matters here: a set of rules that ran unlimited on Trello Premium will hit the 1,000 command-run cap on Standard, and a ClickUp Unlimited workspace has a 1,000-execution ceiling against Business's 5,000.

Billing, access and the order of operations

Two administrative items decide whether the migration is reversible. First, the old subscription: on an annual plan, seats are usually paid through renewal whether or not they are used, so the cost of keeping the old tool alive for a month of overlap is often already paid, and canceling early often saves nothing. Check the renewal date and the written notice requirement before setting a cutover date, and keep the old tool readable until the new one has run through at least one full cycle of the team's work. Second, access: export with an administrator account, store the export somewhere the team controls rather than in the old tool, and verify that it opens before anyone's access is removed. The order that works is export, verify, import a small set, check ownership and dates, import the rest, run both tools in parallel for a short defined period, then downgrade rather than delete the old account.

A short pre-cutover checklist

• Export documentation read, and the fields the export drops listed in writing.
• Departed users' work reassigned in the old tool before export.
• History classified as editable, reference only, or discarded, with the archive location recorded.
• Attachments checked against the new tool's per-file and total storage limits.
• Every integration and automation rule inventoried and assigned a fate.
• Renewal date and notice period of the old subscription confirmed.
• A sample import verified for owners, dates and links before the full run.

Bottom line

The migration cost is real, it is paid in staff time rather than subscription fees, and the Trello review names it as the reason a tool chosen for simplicity can be expensive two years later. Reduce it by reading the export documentation before choosing the tool in the first place, by deciding what must survive before exporting, and by keeping the old account readable until the new one is proven. None of this is a substitute for a trial import with your own data, which is the one step on this list no review site can perform for you; it is the list of things that trial should check.