The decision to consolidate is usually the easy part. The stack is expensive, nobody trusts the numbers, and the case makes itself. What sinks these projects is the order things happen in.
Almost every failed consolidation looks the same from the inside: months of building, a big switch-over date, a rough two weeks, and a team that quietly keeps using the old spreadsheet because the new system doesn't do the one thing they needed on day one. After that, trust is gone and it doesn't come back cheaply.
Here is the sequencing that avoids it.
Rule 1: start where the pain is, not where the architecture is tidy
There is always a technically satisfying place to start — usually the data model underneath everything, or the module with the fewest dependencies.
Resist it. The first thing you ship should be the thing people complain about most, even if it is architecturally awkward, because the first release has a job beyond its features: it has to convince the people who will live in this system that it is going to be better. A first release that removes a genuine daily irritation buys you patience for everything after it. A technically elegant first release that nobody notices buys you nothing.
Ask the team which part of their week they would delete. Build that.
Rule 2: run old and new in parallel, deliberately
Parallel running gets treated as a failure to commit. It is the opposite — it is what makes the switch reversible.
For a defined period, the new module is authoritative and the old tool stays readable. Nobody is forced to trust the new numbers on faith; they can check. Most people check twice and then stop, and that is exactly the point. The cost is some duplicated effort for a few weeks. The alternative is a cutover with no way back.
Two things to decide up front, or parallel running becomes permanent:
- What ends it. A date, or a condition — "two full billing cycles with no discrepancies". Write it down.
- Which system wins a disagreement. From day one of parallel running, the new system is the source of truth and the old one is a reference. If both are authoritative you have made your data problem worse, not better.
Rule 3: migrate data in three passes, not one
Data migration is where consolidations quietly die, because the problem is never the moving — it is discovering what your data actually looks like.
Pass one: a sample. A few hundred records, early, before anything is built on top. This is where you find that the same customer exists four times under four spellings, that a required field has been used for three different purposes since 2019, and that a date column contains free text. Every business has some version of this. Finding it in week two is a discovery; finding it the week before go-live is a crisis.
Pass two: full dry run. Everything, into a staging environment, with a reconciliation report: counts per entity, totals that should match the old system, and an explicit list of records that failed and why. Show that list to the people who own the data. They will recognise things you cannot.
Pass three: the real one. By now it is mechanical, because the surprises already happened.
The trap is treating migration as a task at the end of the project. It is a discovery activity, and it belongs at the beginning.
You are not migrating data. You are finding out what your data has been hiding.
Rule 4: don't rebuild the workarounds
Every fragmented stack has accumulated workarounds — the status field used as a flag, the naming convention that encodes a category, the spreadsheet that exists because the system couldn't express something.
These are all requirements in disguise, and they need separating into two piles. Some encode a real business rule the old software couldn't express: model it properly in the new system. Others are scar tissue from a limitation that no longer applies: delete them.
The failure mode is faithfully reproducing all of it, which means paying for a new system that behaves exactly like the old one. If a workaround exists, ask what it was working around, and whether that constraint still exists. Often nobody has asked in years.
Rule 5: automate after adoption, not before
It is tempting to launch the AI agents with the first module. Don't.
Agents act on your data, so they need the data to be clean and the process to have settled. Automating a process that is still changing means rebuilding the automation each time it moves — and if an agent produces a wrong result in week one, people conclude the whole system is unreliable, not that the rule needed tuning.
Let a module run manually until it is boring. Then automate the boring part. That sequencing is also why the agentic layer comes last in how we phase a build.
A realistic shape
For a mid-sized business consolidating six to eight tools, this tends to look like:
- Weeks 1–2: process mapping and the first data sample. Expect uncomfortable discoveries.
- Weeks 3–6: the highest-pain module live, running in parallel.
- Weeks 6–12: two or three more modules, each parallel-run then cut over. The old tools start getting cancelled.
- Month 4+: the remaining modules, then agents on the processes that have settled.
Note what is missing: a single date on which everything changes. There isn't one, and a plan that has one is worth re-examining.
The thing nobody budgets for
Your team's time. Not the build — the discovery.
The people who know how the work actually happens are, without exception, the busiest people you have. Mapping a process properly means watching real work, not reading a document, because the document describes the process as designed and the value is in the difference between that and what people really do.
Budget for that access explicitly and early. It tapers sharply once the map is agreed, but a consolidation that can't get an hour a week from the operations lead will produce a system built on assumptions — and you will find out which assumptions were wrong at the worst possible time.
If you want a second opinion on your sequencing before you commit, that's roughly what our first call covers. Book one, or read the FAQ first.
