How to cut down your tool stack without paralysing the company

Deciding you have too many tools is easy. Acting on it without stopping the company for a month is not.

In the companies we talk to, consolidation fails on switching the old tools off, not on choosing the new one. Someone announces that from Monday everything happens in one place; three weeks later half the team is back in its own spreadsheet and the company has seven tools, not six.

What follows: what to write down, how to spot a tool worth dropping, in what order to migrate, and what to do with the leftover data.

The inventory you have to start with#

Not the licence list from your invoices — that shows only what you pay for.

Four columns:

The tool. Including what nobody bought: private spreadsheets, a drive on someone's personal account, the messenger group where the rota gets agreed. The most commonly skipped part of the list.

Who uses it. By name, not by department. "Marketing" means nothing when the real users are two people, one of whom leaves next month.

What for. One sentence describing an activity, not a category. Not "project management" but "tracking job status for the three largest customers". A category compares with nothing; an activity does.

Whether it is the only place that data exists. Yes or no. This column decides everything else.

The inventory takes a week, built by asking people, not guessing. Best question: what do you open first thing in the morning.

The column that decides#

A tool where data is merely displayed can go at any point. A tool that is the only place something is stored is a liability — until you know what kind, leave it alone.

Two things hide there most often:

History, not just the current state. Open jobs move by hand in a day. Three years of closed jobs with comments and attachments are another matter — that is where the answer to "why did we do it this way" lives.

Dependencies nobody wrote down. A spreadsheet two others pull from by formula. An automation emailing on a status change.

The criterion for dropping a tool#

Not "is it needed" — every user of every tool says yes to that.

The question is: can the activity this tool supports be done where you work anyway, without a loss you cannot name.

Three conditions, all at once:

The activity has an equivalent. Not something similar, but a specific way of doing exactly the same thing. If the answer is "there's a workaround", there is no equivalent.

The loss can be named. Something is always lost — a faster shortcut, a clearer view. It has to fit in one sentence and the tool's main user has to accept it. A loss you cannot name is usually one you have not noticed yet.

Someone owns the move. By name, with a date. A tool with no migration owner never gets switched off — it just gets used less, the worst state of all.

Tools meeting all three go on the retirement list. The rest stay and get reviewed again in six months.

Order: do not start with the favourite#

The first migration decides whether people believe in the next one.

Do not start with the tool the team likes. The instinct runs the other way: if there is to be one place, move what everyone uses first. Then the first experience of consolidation is losing something that worked well, and every change after that reads as taking away rather than tidying up.

Start with the tool nobody defends. There is usually one: bought three years ago for a single project, assigned to four people, two of whom no longer open it. Retiring it hurts nobody and gives you a rehearsed export procedure, proof the company can switch things off, and one invoice fewer.

Then the one that hurts most. Whichever generates the most manual retyping. The gain shows in the first week, so the migration defends itself.

The favourite last. By then the new place is familiar, the procedure rehearsed, and the team has seen that the earlier changes did not end in disaster.

One tool at a time, at least two weeks between migrations. The gap exists so the things nobody thought of have time to surface — usually at the first month-end.

What to do with the data#

Split it three ways before you export anything.

Operational data. What is in circulation now: open jobs, active customers, current tasks. Into the new tool, with a record-by-record check.

The archive. Closed matters that must stay accessible but need not sit in a system. Export to files, sensible naming, on a drive. No point loading five years of history into the new tool — a mess moved somewhere clean is still a mess.

Retention-bound documents. Invoices, contracts, anything with a required holding period. Rules decide here, not convenience — a question for your accountant, not your team.

Settle two things before switching off: how long the old tool stays read-only (a month is enough, three makes it a second source of truth) and who holds the export outside it. Access disappears with the subscription, often without warning.

What not to consolidate#

Consolidation has a limit, better known before you start.

Tools required by someone outside. The system a customer places orders in, software matching what your accounting firm uses. You do not change those because you happen to be tidying up.

Single-role tools that do one thing very well. A designer with a graphics package, a warehouse with a barcode scanner. Pulling them into a shared tool means worse work for that role and no gain for anyone else. It is enough that the output of that work lands where the rest of the context sits.

Summary in one paragraph#

Start with a four-column inventory and take the last column seriously. Drop a tool only when the activity has an equivalent, the loss fits in one sentence, and someone owns the move by name. Go from the tool nobody defends towards the one with defenders, one at a time. Split the data into operational, archive and retention-bound before clicking export.

The wider context — how to choose a toolset for a distributed company in the first place — is in the guide on remote work tools.