Project Management Tool Migration: Agency Playbook

Most agencies do not fail at choosing a new PM tool. They fail at leaving the old one. Six months after the shiny new platform goes live, half the team is still checking Asana for "the real deadlines," the time data is split across two systems, and nobody can produce a clean utilisation report for Q3.

A project management tool migration is an operations project, not a software purchase. Here's the playbook we've seen work at agencies between 8 and 40 people, with the specific decisions that determine whether it sticks.

The short answer: what a successful migration looks like

Four to six weeks. One pilot client first. Under 30% of your old data moves. A hard read-only date on the legacy tool. One person with veto power over structure changes for the first 60 days. That's it — everything below is detail on those five decisions.

Before you migrate: confirm the problem is the tool

Roughly a third of migrations we hear about are really process problems wearing a software costume. If your projects run late because scopes are vague and nobody logs time until Friday, a new tool will reproduce that faithfully in a nicer interface.

Run a quick diagnostic. Write down the three things that broke in the last quarter — a retainer that quietly went 40% over hours, a client audit that shipped two weeks late, a report that took someone six hours to assemble manually. For each one, ask whether the tool caused it or just failed to catch it.

Tool-caused problems are worth migrating for: per-user pricing that stops you inviting freelancers, no time tracking against retainer budgets, no way to see all 22 clients' phases in one view. Process problems are not. If you're not sure where your stack actually hurts, a SaaS stack audit will tell you in an afternoon whether you have a tool problem or a habit problem.

Step 1: Design the structure before you touch data

The single biggest migration mistake is importing your old structure into a new tool. You inherit six years of accumulated workarounds — the "URGENT-2023" tag, the four different naming conventions for technical audits, the project template someone built for a client who churned in 2022.

Spend the first week defining, on one page:

• Client and project hierarchy. Does each client get one ongoing project with phases, or a new project per campaign? For retainer-heavy SEO agencies, one client container with recurring monthly phases usually beats spawning 12 projects a year.
• Naming convention. Pick one. [Client] — [Deliverable] — [Month] is boring and works. Write it down where people can see it.
• Task statuses. Cap it at five or six. Every agency that ships 11 statuses ends up with three that nobody uses and two that mean the same thing.
• Time tracking granularity. Per task, per phase, or per project? Per phase is the sweet spot — granular enough for campaign estimation from historical data, loose enough that people actually log it.
• Who sees what. Decide client visibility rules now, not the day before you invite them.

Build three project templates from this: a retainer month, a technical SEO audit, and a site migration or one-off build. Those three cover most agency work.

Step 2: Decide what data actually moves

Open your current tool and count the open tasks. A 15-person agency typically has 1,200 to 2,000. Now filter to tasks touched in the last 30 days. That number is usually 300 to 500. That gap is your archive.

Move these

• Active tasks and anything due in the next 90 days
• Live client documentation: brand guidelines, access credentials locations, keyword targets, approved briefs
• Retainer scopes and current-period hour budgets
• Recurring work that repeats monthly

Export and archive these

• Closed projects — export to CSV, drop in a dated folder in Drive
• Comment threads older than six months — screenshot or PDF the two or three that have contractual significance, bin the rest
• Attachments — bulk export to cloud storage and link from the new tool rather than re-uploading 4GB of files

The awkward one: historical time data

Time logs are the hardest thing to lose and the hardest thing to move. Most tools export time entries as CSV with columns for user, date, project, and duration — but the project IDs won't match your new structure.

Pragmatic approach: don't import raw entries. Instead, export a summary table of hours by client by month for the last 24 months and keep it as a reference spreadsheet. You need that data for estimating and for renewal conversations, not for line-item audit. Start clean in the new tool from a fixed date — the first of a month, ideally the start of a quarter — so your reports have a clean boundary.

Step 3: Pilot with two or three clients

Do not migrate 22 clients on a Saturday. Pick three that represent your range: one straightforward retainer, one messy multi-stakeholder account, one project-based build. Move them fully — tasks, time tracking, reporting — and run them in the new tool for two weeks while everything else stays put.

You will find things. The phase template doesn't fit content-heavy retainers. Your senior SEO wants a view that groups by deliverable rather than by date. The client portal shows internal time notes you'd rather it didn't. Fixing those with three clients costs an afternoon. Fixing them with 22 clients live costs a week and your team's goodwill.

Assign one migration owner. Not a committee. Someone who can make a call on whether "we need a custom field for target URL" is a real requirement or a preference, and who owns the naming convention for 60 days. Agencies that skip this end up with the same sprawl they migrated away from — the pattern behind most stories about cutting PM bloat.

Step 4: Bulk migration and the hard cutover

Weeks three and four: move everything else, two to four clients per day, with the account lead for each client checking the result the same afternoon. A checklist per client — tasks in, docs linked, retainer budget set, team assigned, client invited if applicable — keeps this from turning into archaeology.

Then set a date and make the old tool read-only. This is non-negotiable. Parallel running is fine for a week; parallel writing is how migrations die. If your old tool doesn't support read-only mode, remove edit permissions for everyone except the migration owner.

Keep the old subscription for 60 to 90 days at the lowest tier as an insurance policy, then cancel it. Diary the cancellation the day you start — otherwise you'll be paying for both tools in March.

Step 5: Adoption in the first 30 days

Training doesn't need to be a two-hour workshop. It needs to be a 20-minute session covering the four things people do daily: find my tasks, log time, comment on a deliverable, mark something done. Record it. New hires will thank you.

What actually drives adoption:

• Daily standup runs off the new tool from day one. If the PM opens a spreadsheet in standup, the tool is dead.
• Time logged weekly, reviewed weekly. Not as surveillance — as the input to the retainer health check. Framing matters here; how you talk about time tracking determines whether you get honest data or padded data.
• Delete the shortcuts. Remove old tool bookmarks, Slack integrations, and email notifications. Friction is your friend here.
• A 15-minute retro at day 30. What's annoying? Fix the top three things, ignore the rest.