Bringing work in from other tools
Most migrations fail in the same place: somebody tries to bring everything, and everything takes longer than anyone allowed for.
You already have work somewhere else — files in a drive, tasks in a board, notes in three places. Moving it is less about export formats and more about deciding what deserves to come.
Move what is live, archive what is finished
The instinct is to bring everything so nothing is lost. The result is a new workspace that looks exactly as cluttered as the old one on day one, and nobody trusts it because they cannot tell what is current.
Bring the projects that are actually running now, plus anything a client might ask about this quarter. Leave finished projects where they are — the old tool will keep working for reading, and you can pull a single folder across the day someone needs it. A migration you can finish in a week beats a perfect one you abandon in month two.
The order that works
Files first, then the work that references them, then people. Files are the slowest and the least contentious; getting them across early means that when tasks arrive, the links they need already exist.
Do not invite the whole team until at least one real project is fully in and usable. People form their opinion in the first ten minutes, and an empty workspace teaches them there is nothing here yet — a belief that takes months to undo.
Do not rebuild the old structure exactly
Every migration is a rare chance to drop the folder someone made in 2023 that nobody has opened since. If you copy the hierarchy across unchanged, you have also copied every workaround it accumulated.
Ask one question per top-level folder: if we were starting today, would this exist? Usually a third of them would not. That third is where most of the confusion lives.
Set a date to stop running both
Running two systems is the most expensive state, and it is also the most comfortable, so teams stay there for months. Every day of overlap is a day where half the work is in one place and half in the other and nobody is wrong.
Pick a date, say it out loud, and after it treat the old tool as read-only. Not because the migration will be finished — it will not be — but because a deadline is the only thing that converts "we should move that" into someone moving it.
Questions people actually ask
Should I move everything across?
No. Move what is running now plus anything a client might ask about this quarter, and leave finished projects in the old tool as read-only. A migration you finish in a week beats a perfect one you abandon in month two.
What order should a migration follow?
Files, then the work that references them, then people. And do not invite the team until one real project is fully in — an empty workspace teaches people there is nothing here, and that belief takes months to undo.
How long should we run both systems?
Set a date and make the old tool read-only after it. Overlap is comfortable and expensive: while both are live, half the work sits in each place and nobody is technically wrong.
