Consolidating Overlapping Tools

Discovery reliably finds duplicates: several project trackers, several video tools, several file-sharing services. Consolidation is the obvious response and the one most likely to fail.

Why duplicates accumulate

Teams bought independently, each solving their own problem.

Acquisitions brought a second stack.

A central tool was inadequate for one team's specific need.

Nobody knew the organisation already had one.

A champion left and their replacement preferred something else.

Most of these are reasonable at the time, which matters when you propose removing someone's tool.

The arithmetic

Direct saving: the licences you stop paying for.

Indirect saving: fewer vendors to assess, fewer contracts, fewer integrations, better pricing on the survivor through volume.

The cost: migration effort, retraining, lost history, disruption, and the political capital spent.

Consolidation is frequently proposed on the direct saving alone and abandoned when the cost becomes visible.

Choosing what to consolidate

Start where the overlap is genuine. Two tools doing the same job for different teams is a candidate. Two tools that look similar and serve different needs is not.

Start where usage is low on one side. Migrating four people is a conversation; migrating two hundred is a project.

Start where the data is portable. A tool with good export is easier to leave than one without.

Avoid systems of record for the first attempt. Start with something peripheral and build credibility.

Do not start with the tool people love to prove a point about policy.

Doing it without a revolt

Talk to the teams first, before announcing anything. They know why they chose it and the reason is sometimes decisive.

Establish the requirement, not the preference. What must the tool do. Frequently the survivor can do it and nobody checked.

Let the losing team test the survivor properly before the decision is final.

Fund the migration. Effort, not just permission. Consolidation announced with no help attached does not happen.

Migrate the data, including history where it matters.

Set a date and hold it, with a period of overlap.

Accept exceptions where the case is real. A team with a genuine requirement the survivor cannot meet should keep their tool, registered and reviewed. Forcing it produces shadow usage.

The category view

Report by category, not by application. "Four file-sharing services, £X total, serving overlapping populations" is a decision. Four separate line items are four small conversations.

Rank categories by total spend and by number of tools.

Address one category at a time, completely, before starting the next.

What consolidation is not

A cost-cutting exercise dressed as strategy. If the saving is the only argument, say so.

An excuse to impose a preferred vendor.

Free. The migration effort is real and it lands on the teams being consolidated, which is why it needs funding and a sponsor.

Where the honest analysis shows the cost exceeds the saving, the right answer is to register both, assign owners, and leave them alone.

The exception that should be granted

Consolidation programmes lose credibility by refusing every exception. Some are legitimate and granting them visibly makes the rest easier.

A genuine capability gap. The survivor cannot do something the team depends on, demonstrated rather than asserted.

A regulatory or client requirement attached to a specific tool.

A migration cost exceeding several years of the saving.

A team mid-project where disruption would cost more than the licence.

Grant the exception with conditions: registered, owned, reviewed annually, and revisited when the survivor adds the missing capability.

Publish the granted exceptions and the reasons. It demonstrates the process is about the requirement rather than the policy, which is what makes the next consolidation easier rather than harder.

Sequencing a consolidation

The order determines whether the second consolidation is easier than the first or impossible.

Start peripheral. A category where the tools are not systems of record and the data is portable.

Start where one side is small. Migrating four people builds the process; migrating two hundred tests it.

Publish the outcome, including the migration support that was provided.

Do the next one only after the first has settled, with the same visible support.

Leave systems of record until last, when the process has a track record.

Consolidations announced as a programme covering everything at once produce coordinated resistance, and they usually stop after the first one goes badly.