Every growing business hits the same conversation eventually.
"The tool is the problem. We need to migrate."
Sometimes that is true. Often it is not.
We have seen businesses spend three months migrating from one project management tool to another, and end up with the same problems in the new tool. The tool was not the issue. How the team used it was the issue. Migration solved nothing.
We have also seen businesses spend three years bending a tool that genuinely could not do what they needed, when a migration would have taken six weeks and solved everything.
The question is not "is this tool good?" The question is "is the tool the actual cause of our pain, or is the cause something else?" Most teams ask the wrong question and end up with the wrong answer.
Here is how to tell which problem you have before you spend three months on a migration that may not fix anything.
The Test: Three Questions
Before you start evaluating new tools, run through three questions.
Question 1: Have you actually used the tool the way it is designed to be used?
Most tools are powerful but require setup. CRMs need pipelines configured. Project management tools need workflows defined. Email automation needs sequences built. Accounting software needs charts of accounts and approval rules.
If your team set up the tool in 30 minutes during onboarding and has been bending it ever since, you have not actually used the tool. You have used a default configuration that probably does not match your business.
The most common pattern: a team has a CRM that "does not work for them." On inspection, the pipeline stages are the default Salesforce ones from when they signed up four years ago. They have never customised the fields, the stages, or the automation. Of course it does not work for them. It was never configured to work for them.
Migrating to a new CRM and using the default configuration again will produce the same result.
Question 2: Is the tool failing for one reason or many reasons?
A tool that fails for one specific reason is often fixable. A tool that fails for many reasons is often the wrong tool.
One reason: "Slack does not have proper task assignment, so things get lost." This is fixable. Add Linear or Asana for tasks. Use Slack for chat.
Many reasons: "The CRM is slow, the data is wrong, the reporting is unusable, the integration with our email tool is broken, and the support team hates the interface." This is not one problem. This is the tool genuinely not fitting the team.
When the list of complaints is long and varied, it usually points to a deeper mismatch between the tool and the work being done. When the list is one or two specific items, the fix is usually to address those items, not migrate.
Question 3: When you describe the ideal tool, are you describing this tool with three changes, or a different tool entirely?
If you are describing this tool with three changes, fix those three changes. Either configure them in, integrate them with another tool, or build a small workaround.
If you are describing a fundamentally different tool, you have outgrown this one. Migrate.
The test that helps here: write out the top three things you wish the tool did. Look at the official feature list of the tool. Are those things possible, just not enabled? Then enable them. Are they impossible without leaving the platform? Then migrate.
The Most Common "Wrong Tool" Misdiagnosis
Six patterns we see repeatedly where teams blame the tool when the real problem is something else.
The CRM that "does not give us visibility into the pipeline."
Almost always a process problem, not a tool problem. The team is not updating deals. The stages do not match how the business actually sells. There is no discipline about logging activity. A new CRM will have the same problem within a quarter.
The fix: define clear pipeline stages with exit criteria. Make CRM updates a weekly habit (not optional). Run the pipeline review off the CRM data, which forces people to keep it accurate.
The project management tool that "is too complicated."
Usually means the team has not invested time in learning it. Tools like Asana, ClickUp, and Notion are powerful and have a learning curve. If your team is using 10% of the features and complaining about complexity, the complexity is not the issue. The training is.
The fix: dedicated training. One person becomes the internal power user. They teach the rest. The team starts using the tool properly within two weeks.
The accounting software that "produces wrong numbers."
This is almost never the software. This is the chart of accounts, the categorisation rules, the bank feed setup, or the closing process. The software is doing exactly what it was told. The setup told it the wrong thing.
The fix: get an accountant or operational expert to review the configuration. Most issues are fixable in a day. Migrating to different accounting software with the same misconfiguration produces the same wrong numbers.
The email tool that "does not let us segment properly."
Usually a data problem. The contact data is incomplete, inconsistent, or full of duplicates. No email tool can segment well on bad data. A new tool will fail the same way.
The fix: clean the data. Add the segmentation fields you need. Then segment.
The HR system that "does not work for our team."
Usually a process problem. The team is not using the system for what it is designed for (time off, reviews, employee records). Important data lives in spreadsheets and Slack. The HR system feels useless because it is empty of useful data.
The fix: commit to the system as the source of truth. Move the data in. Use it.
The communication tool that "creates noise."
Almost never the tool. The team's communication norms are the problem. Channels are not named clearly. Messages cross channels. No one knows where things should go. New tool, same problem within a month.
The fix: norms. Which channels are for what. What requires a thread. What requires a DM. What needs to be in a doc, not a chat. Write it down. Train people.
When the Tool Genuinely Is the Problem
Five signals that mean the tool is actually wrong for the business.
The tool was designed for a different stage of company. A spreadsheet works at five people. A spreadsheet does not work at fifty. A startup CRM works at thirty employees. A startup CRM does not work at three hundred.
The tool was designed for a different industry. Generic project management tools work for many teams. They struggle for industries with specific requirements (construction, healthcare, agencies, legal). At a certain size, vertical-specific tools genuinely fit better.
The tool is being abandoned by its vendor. Acquisitions, lack of updates, end-of-life notices. If the vendor has stopped investing, the tool will slowly decay regardless of how well you use it.
The tool cannot integrate with the rest of your stack. Modern operations run on data flowing between tools. A tool that cannot connect (no API, no Zapier integration, no native integrations with major platforms) becomes an island that needs manual data entry. That cost compounds.
You have outgrown a core capability. The tool handles 80% of what you need, but the 20% it cannot do is now critical. Workarounds are starting to break. The 80% you do have is no longer enough to justify staying.
When you see one or more of these clearly, migration is the right move. The cost of migration is real, but the cost of staying is now higher.
The Cost of Migration That Most Teams Underestimate
Migration is not just "set up the new tool and import the data." A real migration involves:
Data cleanup. The data in the old tool is messy. Bringing it into the new tool brings the mess too. Cleanup before migration takes one to four weeks depending on volume.
Process redesign. The new tool works differently. Your existing processes are designed around the old tool. Redesigning the processes for the new tool takes one to three weeks.
Team training. Every person who used the old tool needs to learn the new one. Productive use takes two to six weeks of regular use, not just one onboarding session.
Integration work. Every system that talked to the old tool needs to be reconnected to the new tool. Each integration takes a day to a week.
Parallel running. Most teams need to run both tools for a month while the new one stabilises. Twice the cost during that period.
Productivity dip. The team is slower for one to three months while learning the new tool. Real cost in delayed work and missed deadlines.
Total realistic timeline: three to six months for a real migration. Total realistic cost: ten thousand to fifty thousand pounds in time, training, and productivity. This is why migration should not be the default answer. It is expensive even when it is the right answer.
How to Decide
Before you decide to migrate, run the three questions from the start of this article. Then run the six "wrong tool" patterns and check whether you might be misdiagnosing.
If the answer is still "yes, the tool is the actual problem," and one or more of the five "tool is wrong" signals applies, migration is the right call. Plan it properly. Budget the time. Do not underestimate the cost.
If the answer is "actually, this is a setup or process or training problem," fix that first. The fix is cheaper, faster, and often produces results comparable to migration without the disruption.
Most teams default to migration because it feels like decisive action. Migration is decisive action, but it is the wrong decisive action if the problem is not the tool. The right decisive action is fixing what is actually broken, which is often less glamorous than ripping out the tool and starting over.
The teams that operate well are not the ones with the best tools. They are the ones who use their tools properly. The tool stack rarely matters as much as how the team uses it.
If you are about to start a migration, take one more week. Run the questions. Make sure the diagnosis is right. The cost of being wrong is high, and the cost of being right just means another week of patience.