Migrating Tools Without Losing Your Team (or Your Data)

Tool migrations do not fail because the new tool is worse. They fail in two specific, preventable ways: the data arrives broken (tasks without assignees, docs without images, history without meaning), or the people never move (the old tool stays warm, the new one stays empty, and six months later you are paying for both). Feature comparisons get all the attention during selection, but by migration time the feature question is settled. What remains is an operations problem and a change-management problem, and both have known playbooks.

This is that playbook: six phases, from deciding what actually moves through sunsetting the old tool, with the specific export mechanics, champion structure, parallel-running rules, and communication scripts that make each phase work. It assumes you have already chosen the destination; if you have not, start with How to Choose Team Collaboration Software: A Buyers Guide and come back.

The six phases at a glance

For a team of 10 to 100 moving one or two tools, this whole arc runs six to ten weeks. Consolidating five tools into one platform runs longer, but as staggered waves of this same cycle, not as one big bang.

Phase	Duration	Exit criterion
1. Data triage	1 week	Every data category labeled: migrate live, migrate as archive, or leave behind
2. Export and test import	1–2 weeks	A full trial import passes spot-checks; gaps documented with workarounds
3. Champions and pilot	2 weeks	Pilot group working fully in the new tool; friction list triaged
4. Parallel run	2 weeks, hard cap	Whole team in the new tool; old tool read-only
5. Cutover and sunset	1 day + 30 days	Old tool archived, exports stored, licenses cancelled
6. Stabilize and review	30 days	Adoption metrics healthy; migration retro done

The single most common mistake is skipping phase 1 and starting with export, which guarantees you will spend your hardest weeks migrating data nobody needed.

Staff it like a small project, because it is one

Migrations stall when they are everyone's side task and no one's job. Before phase 1 starts, name three roles explicitly, even on a ten-person team where one person may hold two of them:

• Migration lead. Owns the timeline, the gap list, the comms sequence, and the daily adoption number during the parallel run. Budget a quarter to a third of their time for the core six weeks. This should be someone with standing to say "no, we are not extending the parallel run" and be heard — a team lead or senior IC, not the newest hire who happened to like the new tool.
• Data owner. Runs the exports, the test import, and the spot-checks, and keeps the archive organized. This is detail work measured in checklists; give it to someone who enjoys checklists. Budget two to four full days across phases 1 and 2, more if scripting attachment downloads.
• Executive sponsor. Sends message one of the comms sequence, visibly uses the new tool from the pilot onward, and unblocks budget questions (the one month of top-tier pricing for a clean export, the contractor-day of API scripting). Cost in time: an hour a week. Cost of not having one: the migration reads as an IT preference instead of a company decision, and adoption follows accordingly.

Write the names and the dates into a one-page migration plan — phases, exit criteria, roles, comms schedule — and post it where the whole team can see it. Public dates create gentle pressure that private plans do not, and the plan doubles as the outline for every message you send later.

One more staffing note: resist the urge to outsource the whole thing to the vendor's migration service. Vendor importers and support engineers are genuinely useful for the mechanical steps, and you should use them. But the triage decisions, the champion network, and the comms cannot be delegated to someone outside the team, because they are made of context and trust. Buy the crane; keep the architect.

Phase 1: Decide what actually moves

Not all data is equal, and migrating everything is both expensive and actively harmful — a new workspace pre-cluttered with four years of stale tickets feels worse than the old tool, not better. Triage every data category into three buckets:

• Live — open tasks, current sprint, active docs, this quarter's goals, upcoming events, open PTO requests. This moves with full fidelity, structure intact, and it is worth real effort.
• Reference — closed projects from the last year, decision docs, the wiki, evergreen SOPs. This moves, but flat fidelity is acceptable: a searchable page beats a perfect structural replica.
• Archive — everything older, chat history, notification logs, abandoned drafts. This gets exported to storage you control and does not get imported. It exists to answer the occasional "what did we decide in 2023" question, and a searchable export file answers that fine.

Run the triage as a 90-minute working session with one representative per team area. The default placement for anything contested is one bucket colder than its advocate wants; you can always promote an archive item later, but you cannot un-clutter a workspace gracefully.

Chat history deserves a specific ruling because someone will fight for it: chat is where context goes to die, and importing years of it is almost never worth it. Export it for the archive, migrate nothing, and treat any genuinely important content trapped in chat (decisions, agreements, how-tos) as a prompt to write the doc that should have existed anyway.

Phase 2: Export everything, then test the import

Export mechanics by data type

Do the full export before the team starts moving, even for archive-bucket data, and store it outside both the old and new vendors' clouds. Specifics that bite people:

• Tasks and boards. CSV exports usually carry titles, statuses, assignees, and dates, but check three things: do comments come along or vanish; do custom fields export with their values or just their names; and do attachments export at all, or only as links back into the tool you are leaving. Links back into a tool you are cancelling are worthless. If attachments do not export directly, most trackers expose them via API — a contractor-day of scripting now beats discovering the gap after cancellation.
• Docs and wikis. Markdown or HTML export preserves substance; PDF-only export is a red flag you should have caught at purchase time. Check that images are bundled (not hotlinked to the vendor's CDN), that page hierarchy is represented (folder structure or a manifest), and that internal doc-to-doc links either survive or are rewritable with a find-and-replace pattern.
• Chat. Export to JSON or text for the archive. Note that many chat vendors gate full-history export behind top-tier plans; if so, decide consciously whether one month of top-tier pricing for a clean export is worth it (usually: yes, once).
• Files. Bulk-download from wherever they live, keep folder structure, and deduplicate later, not during the migration.
• Users and permissions. Export the member list with roles. You will not import it mechanically, but you will rebuild permissions in the new tool, and a written record of who could see what prevents both security gaps and access complaints.

Assemble it all in dated folders — migration-export-2025-10/source-tool/ — with a README noting what each file is and what is known to be missing. Future-you, answering a question in 2027, will be grateful.

The test import

Before announcing anything, import the live-bucket data into a staging area of the new tool and spot-check it against a written checklist: pick ten real tasks and verify status, assignee, dates, comments, and attachments arrived; open ten docs and check images, tables, and links; confirm counts match (147 open tasks exported, 147 imported). Every mismatch goes on a gap list with a decision: fix with scripting, fix by hand during cutover week, or accept and document. The gap list becomes part of your comms — "comments older than a year did not migrate; they are in the archive export" — because a surprise gap destroys trust in the migration, while a disclosed gap is just a footnote.

If the destination has import tooling or templates, use them and then adjust, rather than building structure from scratch. Moving a monday-style board or a Trello export into Openbook's table and Kanban rooms, for instance, goes faster if you provision the room from a template close to your structure and map columns during import, instead of hand-creating fields first and fighting the mapping later.

Phase 3: Champions, then pilot

Choosing champions

A champion is a peer who has moved early, knows the new tool's equivalents for every old-tool habit, and answers "how do I" questions in public. One champion per five to eight people is the working ratio; below that, questions route to the project lead and bottleneck.

Choose for adjacency and credibility, not enthusiasm alone. The ideal champion set includes at least one person who was skeptical during selection and got convinced by the trial — a converted skeptic reassures other skeptics in a way no enthusiast can. Give champions three concrete things: early access (they live in the new tool for the full pilot), a private channel with the migration lead where their friction reports get same-day responses, and explicit time — "support questions from your pod are two hours a week of your job this month" — so championing is work, not charity.

Their duties, written down: answer usage questions in the open (public answers scale, DM answers do not), maintain a living "old way / new way" crib sheet, and escalate anything broken rather than teaching workarounds silently. The crib sheet matters more than any vendor documentation because it is phrased in your team's vocabulary: "Where standup used to be (Slack thread), it now lives (Check-in room, posts due by 11am)."

The pilot

Champions plus one real workstream operate fully in the new tool for two weeks while everyone else stays put. The pilot's job is to make the second wave boring: by the end, the crib sheet exists, permissions have been tested by real usage, the import gaps have workarounds, and there are visible artifacts in the new tool — a live board, real docs, a feed with actual posts — so the wider team walks into a furnished house rather than an empty one. Empty workspaces read as abandoned, and first impressions during migrations are nearly impossible to reverse.

Phase 4: The parallel run, with a hard cap

Some overlap between tools is unavoidable: people need time to move habits. But parallel running is where migrations go to die, because every day both tools are alive, every person makes a private choice about where to post, and the old tool wins by muscle memory. The fix is to make the parallel run short, asymmetric, and pre-scheduled.

Short: two weeks, announced as two weeks from the start, with the cutover date in every calendar. Extensions require the migration lead to publicly explain why, which is enough friction that drift does not happen silently.

Asymmetric: the tools are not equals during the run. From day one of the parallel phase, the rule is "new work starts in the new tool; the old tool is for finishing what is already in flight." Concretely: no new tasks, docs, or threads in the old tool; anything created there gets moved by its creator with a gentle nudge from a champion. Halfway through, ratchet: the old tool goes read-only for everyone except the migration lead. Most tools support workspace-wide read-only or permission downgrades; where they do not, removing edit rights team-by-team approximates it.

Never bidirectional: do not set up two-way sync between old and new "to make the transition smoother." It makes the transition permanent. Sync tools guarantee neither side is ever the source of truth, conflicts corrupt data in both, and the team correctly concludes that nothing has actually changed.

Two small tactics smooth the run. First, hold a one-hour "moving party" on day one: everyone on a call together, each person moving their own in-flight items and setting up their notifications, champions circulating. Shared effort beats individual homework, and the workspace fills with real content in a single afternoon. Second, have champions post one "old way / new way" tip per day in the team feed for the two weeks — small, specific, skimmable — so fluency builds without anyone scheduling training.

During the run, the migration lead watches one number daily: items created in the new tool versus the old. It should cross 80/20 by the end of week one. If it does not, the blocker is almost always one specific workflow with no good new-tool answer yet — find it by asking the champions, fix it, and re-announce, rather than exhorting people to "give it a chance."

Phase 5: Cutover day and sunset communications

The comms sequence

Sunset communication is a sequence, not an announcement. Six messages, most of them short:

1. T minus 4 weeks (with the migration announcement): what is changing, why (one honest paragraph — cost, consolidation, the gaps the old tool had), the phase dates, and who the champions are. Send from the most senior sponsor, not from IT, so it reads as a direction rather than a chore.
2. T minus 2 weeks (parallel run starts): the "new work in the new tool" rule, the crib sheet link, where to get help.
3. T minus 1 week: the read-only ratchet, plus the disclosed gap list ("here is exactly what did not migrate and where it lives").
4. T minus 1 day: a two-line reminder with the archive location and the promise that nothing is being deleted.
5. Cutover day: short, positive, specific: "The old tool is now read-only permanently. Everything current lives here [link]. Archive exports live here [link]. Champions are in #migration-help through the end of the month."
6. T plus 30 days: the closing note — license cancelled, final archive stored, thank-yous to champions by name, and two or three concrete wins ("standup now takes 6 minutes of async posting instead of a 25-minute call").

The tone throughout should assume good faith and acknowledge cost. People are losing fluency they spent years building; a sentence like "the first two weeks will feel slower, and that is expected and priced in" defuses more resistance than any feature list.

Cutover-day checklist

• Old tool: workspace read-only; billing set to cancel at period end (not instantly — you want the read-only window); admin access retained by two named people.
• Final delta export: anything created or changed during the parallel run gets re-exported so the archive is complete as of cutover.
• New tool: permissions audit against the exported roles list; notification defaults set sanely — a migration is the one chance for a team to start quiet instead of factory-loud; integrations and calendar feeds pointed at the new home.
• Redirects: update every place the old tool was linked — bookmarks doc, onboarding guide, browser homepage policies, pinned messages, the intranet. Stale links are how stragglers end up back in the old tool in week three.

The 30-day read-only tail

Keep the old tool readable for 30 days, then cancel. The tail exists for the "wait, where is X" moments, and 30 days is enough to catch essentially all of them. What you should not do is keep it readable indefinitely "just in case": it costs real money, it splits search behavior, and the archive export answers the rare historical question. When the tail ends, the two named admins verify the final export one last time, cancel, and confirm the vendor's data-deletion terms in writing.

Phase 6: Stabilize, measure, and run the retro

Migration ends not at cutover but when the new tool is the unthinking default. Three checks at day 30 post-cutover:

• Adoption: weekly active users at or above the old tool's baseline; work items and docs being created at comparable or better rates.
• Straggler workflows: survey one question — "what do you still do outside the tool that you used to do inside the old one?" Every answer is either a training gap (champion follow-up), a configuration gap (fix it), or a genuine product gap (document it for renewal season; do not gaslight people about it).
• Shadow revival: watch for the old tool's free tier quietly reappearing, or a new unofficial substitute. This is a signal about unmet needs, not a discipline problem — the dynamics and the response are covered in Shadow IT: Why Teams Adopt Tools Behind Your Back.

Then hold a one-hour migration retro with champions and the lead: what took longer than planned, which export gaps hurt, what the comms missed. Write it down. If you are consolidating a multi-tool stack, this retro is the difference between wave two taking six weeks and taking three — and the broader sequencing strategy for multi-wave consolidation lives in The Tool Consolidation Playbook: From Ten Apps to One.

Next steps

If a migration is on your horizon: run the data triage session this week (90 minutes, three buckets), then immediately run a full export and test import, because the export gaps you find determine your real timeline. Recruit champions before announcing dates, cap the parallel run at two weeks with a read-only ratchet in the middle, script all six sunset messages before sending the first one, and book the day-30 retro now so it actually happens.

And if the destination is still undecided, weigh the consolidation option while you are already paying the migration cost once: moving three tools into one platform costs barely more than moving one tool to another, and it is the last migration of its kind for a long while. Openbook's 18 room types — boards, docs, chat, standups, feeds, whiteboards, and reviews in one workspace — exist for exactly that move, and the free plan lets you run your entire test-import and pilot phases before paying anything. Start the trial import at openbook.work.