Migrating to Asana feels straightforward until you start. Then the team realises the spreadsheet had columns nobody noticed, Jira had custom workflows nobody documented, and Trello had a board everyone forgot existed but the marketing team apparently lives in. Six weeks in, both systems are running in parallel, the new one looks half-built, and adoption is sinking.
Migrations don't fail because Asana is missing features. They fail because nobody decided up front what to move, what to abandon, and when the old system would die. Here is a playbook that lands a migration in six weeks and retires the source system on a defined date.
Step 1: Decide what you're actually migrating
Every source system is a graveyard of abandoned boards, archived tickets, and templates someone built in 2019. Resist the urge to bring it all over. Ask three questions of each artefact:
- Is anything active here? If the last task was completed nine months ago and nothing new has appeared, archive it in the old system rather than reproducing it in Asana.
- Does the structure still match how we work? A three-year-old board is often a fossil of an older operating model. The migration is a free chance to refactor.
- Is anyone willing to own this in the new system?Unowned work doesn't survive a migration. If no one will own it, drop it.
A useful rule of thumb: aim to migrate 30–50% of what currently exists. Anything more and you're recreating the swamp.
Step 2: Pick a primary structure before configuring anything
Asana has Teams, Projects, Sections, Tasks, Subtasks, Portfolios, and Goals. Migrating teams almost always pick the wrong primary unit because they default to whatever maps directly from the source.
- From spreadsheets: a tab usually wants to become a project. But rows that represent recurring work want to become tasks in a recurring project, not one task per row.
- From Trello: a board becomes a project; columns become sections. Avoid the trap of cloning every single board — consolidate boards that share a workflow into one project with a custom-field segmentation.
- From Jira: an epic becomes a project, stories become tasks, subtasks remain subtasks. Workflows translate to custom fields plus rules — there is no direct equivalent to Jira status transitions in Asana, which is usually a feature, not a bug.
Draw your target structure on paper before you create anything in Asana. A 30-minute whiteboard session saves three weeks of reorganising live data.
Step 3: Build templates, not projects
The first artefact you build in Asana should be a template, not a project. Pick the one workflow that fires most often (e.g. campaign launch, customer onboarding, hiring cycle) and template it properly:
- Sections covering each phase
- Tasks with placeholders for assignees and due dates
- Custom fields the team will actually use, not aspire to use
- Rules to handle the obvious automation (auto-assign on completion, move-to-section triggers)
Test the template with one real instance of the workflow before rolling it out. If you can't fit a real piece of work into the template without resizing the template, the template is wrong, not the work.
Step 4: Migrate by team, not by data
The temptation is to move everything at once on a weekend. Don't. Migrate one team at a time, in this order:
- An enthusiastic early-adopter team.Pick the team that already wants this. They'll find the gotchas while they're still motivated.
- A high-volume team with simple workflows. Marketing ops, customer success, or studio teams are often a good second wave. They generate enough activity to validate the setup.
- The reluctant team. By now you have working templates, a known-good structure, and internal advocates. Save the hardest team for when momentum is on your side.
Wave 1 takes two to three weeks; the rest takes one week each. Do not try to compress wave 1 — it's where you learn what your team actually needs.
Step 5: Run a parallel period — but cap it
Parallel running (both systems live) is necessary for confidence but toxic if it lasts more than three weeks. Set a hard cutover date before you start, communicate it widely, and stick to it.
A good parallel-period rule: any work that starts after day 1 of migration lives in Asana only. Existing in-flight work finishes in the source system or moves over with a clear deadline. Don't duplicate-track. Duplicate-tracking is how migrations die.
Step 6: Retire the source system loudly
On cutover day, the old system should be visibly retired — not quietly deprecated. Best practices:
- Make the old system read-only on cutover day (most tools have a mode for this).
- Replace the homepage of the source tool with a banner pointing to Asana.
- For the first two weeks post-cutover, redirect a designated person (or rotate the role) to be the on-call helper for anyone who forgets and opens the old system.
Without a hard cutover, holdouts will quietly keep using the source system, undermining the new one. Be visible about the death.
Common migration mistakes
Migrating the org chart instead of the workflow
New Asana users often build one project per team and stop there. That works fine for status updates but fails for any work that crosses teams — which is most real work. Build projects around workflows (where work flows from one team to another), not around org structure.
Importing comments and history
Asana's API supports bulk task creation but not historical comment threads from arbitrary sources. Don't try to migrate the conversation — link to the source artefact if the history genuinely matters, but for most work, the past is the past.
Configuring rules on day one
Rules (Asana's automation engine) are powerful, but you don't know what to automate yet. Run the workflow manually for two weeks first; the right automations will become obvious. Add them when they would save real time, not when they look impressive in the configuration screen.
Six-week timeline
- Week 1: Decide what migrates, draw target structure, build wave-1 template.
- Week 2: Wave-1 team begins parallel run; daily debrief to refine.
- Week 3: Wave-1 cutover; wave-2 team starts parallel run with refined templates.
- Week 4: Wave-2 cutover; wave-3 begins.
- Week 5: All teams in Asana; final clean-up of structure based on real usage.
- Week 6: Source system retired; first round of "Asana week" rituals embedded.
Six weeks is achievable for teams up to about 100 people on a single workflow style. Larger or more fragmented orgs add two to three weeks per additional workflow archetype. Anything beyond ten weeks usually means the scope crept and you're migrating the swamp, not the work.