How to migrate project management software
The switching-cost reality nobody costs in: the CSV moves your tasks, but comments, attachments, dependencies and automations do not — and the hardest part is getting a whole team to actually move. What breaks, and the sequence that survives contact with real users.
The data is the easy half; the team is the hard half
Most write-ups about switching project tools obsess over the export. That is the wrong worry. Tasks, assignees and due dates move fine. What does not move is the context wrapped around the work — the comment threads, the attached specs, the subtask trees, the dependency chains and the automation rules that quietly run your process. Lose those and the tasks arrive as hollow shells.
The bigger risk only shows up at scale: adoption. A project tool is only as good as the share of the team actually using it, and a migration is the moment that share can collapse. Run two tools too long and work scatters; rush the cutover and people revert. Jira makes both halves harder, because its workflows, custom fields and automations are the product, and importers carry almost none of that. Treat this as a change-management project, sequence it deliberately, and tie the move to what you chose in how to choose project management software.
The five phases of a PM migration
Separate active projects from done ones, then list what carries risk: custom fields and their types, automation rules, dashboards and reports, views (board, timeline, gantt configs), dependencies, and the comments and attachments that hold your institutional memory. Naming the non-exportable items now is what stops a silent loss after cutover.
Choose a clean cutoff date and archive completed projects in place rather than dragging them along. Export active projects to CSV, knowing you are getting task data, not the discussion or files around it. Decide deliberately which attachments and key threads to carry by hand versus leaving in a read-only old workspace for reference.
Recreate spaces, projects, custom fields, saved views, automation rules and dashboards in the new tool by hand — none of this ports cleanly, and on a Jira move it is most of the work. Re-upload the attachments that matter. Get the scaffolding right before you pour the tasks in, or you will redo it with live work loaded.
Import active tasks, reconnect integrations (Slack, GitHub, calendars, time tracking) and re-authenticate them. Then run a real pilot: one team works fully in the new tool for a sprint while everyone else finishes in the old one. The pilot surfaces the broken automations and missing fields before the whole org depends on them.
Set the cutover date up front and hold it. On the date, move everyone, switch the old tool to read-only, and run short retraining so the team’s workflow habits transfer with the data. Indefinite parallel running is how adoption dies — a clean, dated cutover is what makes the migration actually stick.
The export gotchas, named
Mostly no, and this is the loss people discover too late. Task names, assignees, due dates and statuses usually export to CSV. The discussion thread on each task, the files attached to it, the subtask hierarchy, dependencies and the activity log generally do not. If those conversations are your institutional memory, copy the important ones out deliberately or keep the old workspace read-only for reference — do not assume an importer carries them.
There are importers, and they will move issues and basic fields, but they are lossy on exactly the things that make Jira Jira: custom workflows, complex field types, automation rules, permission schemes and historical transitions. A Jira migration is the hardest in this category because the configuration is the value. Plan to rebuild workflows and automations by hand and use the importer only for the raw issue data.
For a small team on a light setup, a few days. For an organization with custom fields, automations, dashboards and integrations, three to eight weeks is realistic, and a Jira migration can run longer. The data move is rarely the bottleneck — rebuilding the structure and getting people to actually adopt the new tool is. This is a change-management project wearing a data-migration costume.
No. Migrating years of done work is the most common way these projects balloon and stall. Pick a clean cutoff, archive completed projects in the old tool or export them to a read-only store, and migrate only active work. You almost never reopen a closed project, and carrying its baggage into the new tool just slows adoption and clutters the workspace from day one.
Briefly, and with a hard cutover date — not indefinitely. A short pilot where one team runs the new tool while the rest finish in the old one is smart. But open-ended parallel running is where PM migrations quietly fail: work scatters across two systems, nobody trusts either one, and people drift back to the familiar tool. Set the cutover date up front and retire the old tool on it.
One email when the rankings move. The shortlist, the tradeoffs, the price changes. No filler.