The Real Cost of Moving a Team Off a Tool Is Not the Migration

When we moved off our old project tool — the move that six months on Linear describes from the other side — I planned the migration around the data, because that is the visible part and it is what the vendor’s migration guide talks about. The data took three days. The move took six weeks. This piece is about the other five weeks, which I did not budget for and which I now believe are the actual cost of switching anything a team uses daily, and the reason leaving a tool you still like takes so long to decide.

The first category is integrations, and the trap is that you know about half of them. I listed six connections to our old tracker from memory. The actual number was fourteen. The eight I missed were things like a Zapier automation someone built in 2023 that filed support emails as tickets, a status badge embedded in a client-facing page, and a calendar feed that two people had subscribed to on their phones. Each one broke silently. Each one was found by someone noticing an absence, which is the slowest possible detection method.

The way to find them in advance, which I know now: search your entire workspace, wiki, and codebase for the old tool’s domain. Not its name — its domain. Names appear in prose everywhere; domains appear in the places where something is actually wired up. That search would have found eleven of my fourteen in about four minutes.

The second category is links. Over four years our documentation, our client emails, and our own commit messages had accumulated thousands of URLs pointing at issues in the old system. When the account eventually lapses, all of those become dead. There is no good answer to this. What we did was keep the old tool on its cheapest tier for a year purely as a redirect target, at $10 a month — a line that the quarterly stack audit will keep asking about — which felt like an admission of defeat and was much cheaper than rewriting history.

The third and largest category is habit, and it is the one that cannot be solved with a checklist. For roughly three weeks after the cutover, work continued to be filed in the old tool by people who were not being careless — they were being fast, and the old tool was still where their fingers went. We did not fix this with reminders. We fixed it by making the old tool read-only on a date announced two weeks in advance, which converted the habit failure from an invisible fork in our records into an immediate, obvious error.

That read-only date is the single most useful thing I took from the whole exercise. A migration with no cut-off is not a migration; it is two systems, and two systems is worse than either one. But the date has to come after the integrations are fixed, or you will spend it firefighting, and this is why the sequence matters more than the schedule.

The cost I could not reduce is the review of what came across. Our import brought 1,400 issues. About 600 were meaningfully dead — closed years ago, or duplicates of things closed years ago — and the temptation is to bring everything because storage is free. We brought everything, and then spent parts of three weeks pruning inside the new tool, which was worse than pruning before the import would have been, because in the old tool we still had the context to judge.

If I were writing the plan again, the order would be: search for the domain and fix every integration first; agree the read-only date and announce it; prune in the old system; import; then spend the last week on links and redirects. The data migration itself sits somewhere in the middle and takes about a tenth of the time you expect.