How to Switch Project Management Tools Without Losing Work in Progress
You’ve outgrown your project management tool. Maybe your teams have scaled beyond the tool’s capacity. Maybe the features you use most are stronger in another tool. Maybe you need enterprise-grade security and automation that your current tool can’t offer. Whatever the reason, you need to migrate to switch to a new tool. But you can’t quite put all your workflows on pause, and working while you switch creates the risk of lost data and duplicate tasks. Neither the tool you’re switching from nor the tool you’re switching to has full context. Teams get confused, your migration slows down, and historical data goes missing.
That’s why a phased migration is the best way to switch project management tools without pausing your workflows.
Why a phased migration beats the alternatives
A phased migration is a type of migration that relies on a two-way sync tool to keep work in sync across tools as you switch workflows over. That allows your workflows to keep running as you migrate with minimal interruptions. You can transition teams and data between systems over time, at your pace, trusting the two-way sync to keep everything up to date.
Compare this to the two most common approaches to migration: big-bang and manual parallel.
A big-bang migration happens all at once. You scope out your migration, move all your data over in one go, and shut down the legacy system after a set amount of time. The legacy system might be kept as a backup for a time, to ensure all necessary data was migrated over. While a big-bang migration might seem more efficient at first glance, it can create significant problems. For one, it’s high-stakes. When you move everything at once, there’s a much greater chance of something going wrong. And if something does go wrong, you have to put your whole migration on pause or plan a significant troubleshooting period to make it right. This type of migration also requires significantly more planning than a phased migration, as you need to consider every potential problem that could arise—and its solutions.
A manual parallel migration happens over time. Both your old and new project management tools are kept live for weeks or months as teams slowly transition from one to the other. Data is transferred manually over that time. It might be done project by project, workflow by workflow, or team by team. This method mitigates some of the risks of big-bang migrations. Missing data can be pulled from the old tool as long as it’s still live, meaning it doesn’t have to stay missing for long. If a problem occurs during your migration, you can roll things back, fix issues, and then keep migrating. But it does have its issues, as well. Because every bit of data is transferred manually, it takes significant work. Someone (or a whole team) has to move that data, taking resources away from other technical work. Another issue? You’ll likely have to keep the old system running longer than you expect, meaning you’re paying double for what should be one system.
A phased migration solves these problems. It eliminates the work involved in a manual parallel migration and eliminates the risks of a big-bang migration. You can migrate at your own pace, trusting a two-way sync tool to manage the data transfer.
The 6 phases of a phased migration
A phased migration typically follows these six phases.
Phase 1: Define your needs and plan
Before you switch project management tools, you have to know what you need. Do you need to migrate within a few weeks or can you take a few months? How much data do you need to transfer over? Are you doing a full transfer of historical data or do you just need teams to start new work in the new tool?
When you’ve identified what you need, it’s time to make a plan. Someone should own the migration process, making important decisions and answering any questions teams might have. That can be someone in IT, a project manager, or anyone who knows their way around the project management tools involved in your switch. Your plan should also include a rough timeline showing the projects, workflows, and teams you’ll be switching over and when they’ll be making the switch. Add potential risks, how you’ll respond to these risks, and potential impacts on your migration.
Finally, your plan should include a communication framework for sharing the impacts of your migration with affected teams. That means the right channels, the right messaging, and even templates for what you expect to have to communicate.
Phase 2: Test your plan with a portion of your data
Don’t kickstart your migration the moment your plan is done. Because a phased migration needs a two-way sync tool, you’ll need to find the right tool and test it out. That testing means potentially making mistakes, having to roll back parts of your migration, and untangling missing or duplicated data. That’s why you want to pick a batch of data to test your plan and the syncing tool you’ll be using. That data can be an old project, a single workflow, or dummy data created specifically for your test.
Use your two-way sync tool to move data from your old project management tool to the new one. Try making changes on one side and see how it’s reflected on the other. Verify the fields you’re syncing and see whether there’s data getting left behind. Make changes as needed, test again, and see if everything works the way it should.
Once your test is complete and the results are satisfactory, it’s time to start migrating real data.
Phase 3: Set up your syncing tool
A two-way sync tool like Unito allows you to pair projects in your old tool with projects in the new one. You can choose to sync historical data or only new work. You can choose the depth at which you need to sync data, how many fields you need to include, and more. Most two-way sync tools don’t need advanced technical knowledge to set up, and they need little maintenance to keep running.
Here’s how easy it is to set up a flow between two project management tools with Unito:
- Connect tool accounts to Unito: After signing up for Unito, click +Create Flow and connect your project management tools.
- Choose flow direction: Flow direction tells your Unito flow where you need new work items created. For a migration, a one-way flow can ensure new work only gets created in the new tool while still keeping historical data up to date.
- Set rules: Unito rules use trigger-action logic to filter out work items you don’t want to migrate. They can also automate certain actions, like assigning new work items.
- Map fields: In most flows, Unito can automatically map fields in your old project management tool with the fields in the new one. From there, you can customize field mappings to match statuses across tools, send data from some fields to fields specific to your workflows, and more.
- Launch your flow: Once you map your fields, your flow is ready to launch. After an initial sync, Unito will check for changes in real time.
Most Unito users set up their first flow in minutes. That means you can start your migration when you’re ready rather than waiting for a long deployment.
Phase 4: Work in parallel
Once you’ve set up your two-way sync tool, data will automatically start flowing from the old project management tool to the new one. That doesn’t mean you want to move all your teams over at once. You still need to validate that data transferred over cleanly, and you need to onboard teams to the new tool. That’s the strength of a phased migration; you can do it at your own pace. For the first bit of your migration, you’ll have both systems running in parallel. Data in the new tool automatically is updated as your workflows run in the old tool. You’ll move data over in batches, by project or by workflow, without making teams switch right away.
When most (or all) of the data you need to migrate is in your new tool, you can start transitioning teams to that tool.
Phase 5: Transition your teams
Transitioning to a new project management tool can be challenging. The interface is rarely the same, automations and workflows work slightly differently, and features you’ve learned to rely on might be completely absent. It takes time for a team to get used to a new tool, and you need to account for that onboarding time. That’s why you don’t want to move everyone over all at once.
Your migration plan should include a priority schedule for the teams you need to transfer over. If you’re switching project management tools for software development projects, for example, you might decide to move developers over first, followed by project managers, then relevant stakeholders. Whatever milestones you pick, you’ll want to onboard the relevant team, teaching them the differences between the old project management tool and the new one. Show them that the data they need to use has already been transferred over. Then, have them log out of the old tool, log into the new one, and start working exclusively from that tool. That’s what Digital Divide did when they migrated their teams from ClickUp to Asana with Unito.
Once a team is comfortable working in the new tool, you can transition the next team over.
Phase 6: Decommission the old tool
When all your teams have switched to your new project management tool and all your historical data has synced over, it’s time to decommission the old tool. Back up any data you’re worried about losing, deactivate your licenses, and close your accounts. From there, you can turn off the two-way integrations you’ve been using.
Review any compliance requirements associated with the data in your old tool. Data security frameworks like SOC 2 or regulations like GDPR might require that you export and retain data for a minimum amount of time.
FAQ: Switching project management tools without losing work
How long should a phased migration take?
The main advantage of a phased migration is that it happens at your pace, whether you want to migrate all your data over a few weeks or a few months. Using a two-way sync solution, your teams can keep working in both the old tool and the new one as you slowly transition them over.
What happens if a team refuses to switch on schedule?
Because a phased migration runs on a two-way sync over time rather than the hard cutoff dates involved in big-bang or manual parallel migrations, a team that isn’t ready to switch doesn’t have to block your whole migration. Work with the team to find out when they’d be ready to switch, and plan around this change.
Do I need to migrate historical data or just go live with new work?
It’s completely up to you. It’s a good idea to migrate historical data, at the very least so it can be backed up after you decommission your old project management tool. That said, some teams prefer having new work in their new project management tool, only choosing to sync historical data when it’s relevant for that work. Note that the two-way sync tools used in phased migrations can sync both new and historical data.
Can I run a phased migration between more than two tools at once?
You absolutely can. The two-way sync tools used in phased migrations typically let you set up filtering rules that ensure data gets in the right place, preventing the infinite loops and extensive maintenance that one-way automation tools can create.