The Tool Consolidation Playbook: From Ten Apps to One

Most tool consolidations fail the same way: someone picks the new platform first, announces it second, and discovers third that nobody mapped what the old tools were actually doing. Six months later the company is paying for the new platform and most of the old ones, adoption is at 40%, and "remember the consolidation" has become a punchline in planning meetings.

The successful version runs in the opposite order. Map first, choose second, migrate in sequenced waves third, and measure the whole way. This playbook covers that sequence end to end — the same phases whether you're a 12-person startup collapsing six apps into two or a 150-person company collapsing fifteen into five. Steal the templates, adjust the timelines, and skip nothing, because every phase here exists because someone skipped it and paid.

Why Consolidations Fail

Three patterns account for most failed consolidations. Name them up front so you can watch for them:

1. Tool-first, map-second. The team falls in love with a product demo, buys it, then tries to retrofit their work into it. Discovery happens during migration — the worst possible time — when someone realizes the old tool's obscure feature was load-bearing for the finance close, or that two departments used "the same tool" in incompatible ways.
2. The big bang. Everything moves on one glorious cutover weekend. Monday morning, 60 people hit friction simultaneously, the loudest complaints win, and leadership rolls it back "temporarily." Rollbacks are never temporary. Momentum, once spent, doesn't refund.
3. Migration without deletion. The new tool launches; the old tools linger "just for reference" or "until Q3." With both available, people default to habit, the new tool never reaches critical mass, and you end up with n+1 tools — the exact opposite of the goal. A consolidation isn't done when the new thing launches. It's done when the old things are canceled.

Every phase below is a countermeasure to one of these.

Phase 1: Inventory — Know What You're Consolidating

You cannot consolidate what you haven't counted. Build a one-row-per-tool inventory: what job it does, who owns it, what it costs, how many people actively use it, what data lives in it, and when it renews. Pull from finance records, card statements, expense reports, and your SSO app list, then run an amnesty email so the tools on personal cards surface too.

We've published a full one-week method for this — including how to price the invisible costs of integration labor and attention — in SaaS Sprawl: What Your Tool Stack Really Costs, so this playbook won't repeat it. Two outputs from that audit matter here:

• The consolidation cluster: the set of tools whose jobs overlap enough that fewer tools could cover them. Typically it's some combination of chat, social feed, project tracking, docs, wiki, whiteboards, surveys, standups, and status reporting spread across five to eight products.
• The business case: license savings plus estimated integration and attention savings, on one page. You'll need this number twice — once to get the project approved, and once at the end to prove the win.

One addition for consolidation specifically: for each tool in the cluster, record its switching anchor — the thing that makes leaving hard. Data volume? Integrations? Muscle memory? One power user's elaborate workflow? Anchors, not features, determine migration difficulty, and you want them listed before you sequence anything.

Phase 2: Overlap Mapping — The Capability Matrix

The inventory tells you what tools exist. The capability matrix tells you what jobs exist — and that distinction is the heart of the whole playbook. Teams don't need "a Trello replacement." They need the eleven jobs currently spread across Trello, two spreadsheets, and a chat channel.

Build the matrix like this. Rows are jobs to be done, phrased as work, not as software categories. Columns are the tools in your cluster. Cells get one of three marks: P (primary home — this is where the job officially lives), S (shadow home — the job also happens here, unofficially), or blank.

A realistic matrix for a 40-person product company:

Job	Chat app	PM tool A	PM tool B	Docs tool	Wiki	Whiteboard	Survey tool
Team announcements	P			S
Task tracking (eng)	S	P
Task tracking (marketing)	S		P	S
Sprint planning		P				S
Meeting notes	S			P	S
Process documentation				S	P
Brainstorms / workshops						P
Team polls & pulse checks	S						P
Status reporting	S	S	S	P
Decision records	S			S	S
Q&A / "how do I..."	P				S

Now read it diagnostically:

• Columns full of S and light on P are tools doing little official work — prime removal candidates.
• Rows with multiple S marks and no clear P (see "Decision records" and "Q&A" above) are jobs with no home. These cause the daily "where does this go?" friction, and your target stack must give each one an explicit home, or the friction survives the consolidation.
• Rows where the P is a chat app are jobs being done in the one place with no memory. Announcements, Q&A, and status living primarily in chat means your company's knowledge has a retention window of about two weeks.
• Split rows ("Task tracking" appearing twice because two departments diverged) are your political hot spots. Flag them now; Phase 6 deals with them.

The matrix takes one workshop afternoon with one representative per team, and it is the single highest-value artifact in the project. Every later decision — target choice, wave order, training content — reads directly off it.

Phase 3: Choosing the Target Stack

With the matrix in hand, the tool decision becomes tractable: which minimal set of tools covers every row with a P, leaves no orphan jobs, and removes the most columns?

Ground rules for the decision:

• Cover jobs, not features. The question for each candidate is "which rows can this be the P for?" — not how long its feature list is. A tool that's the P for eight rows beats two tools that are each dazzling at two.
• Apply the 80% rule honestly. A consolidated platform will usually do each individual job at 80–90% of the depth of the specialized tool it replaces. That trade is worth it when the job's users are generalists, and not worth it when the job is a specialist's core craft. Your accounting system and your code host stay. Your fourth place to write documents does not. The full version of this tradeoff argument — including when best-of-breed genuinely wins — is in All-in-One vs Best-of-Breed: An Honest Analysis.
• Weight the connective tissue. Ask of every candidate: does search span everything? Do notifications land in one place? Can a task reference a doc reference a discussion without leaving? The matrix rows with no P — the homeless jobs — are usually homeless precisely because they live between tools, and only a connected platform gives them a home.
• Trial with the matrix, not with a demo. Give two or three finalist stacks a two-week trial with one real team doing real work, and score them per matrix row: can this be the P for announcements, for sprint planning, for retros? Scoring against your own rows immunizes you against demo charisma.

For teams whose cluster is the common one — feed, boards, docs, wiki, whiteboards, check-ins, Q&A scattered across many apps — a modular platform like Openbook maps unusually cleanly onto the matrix, because each room type corresponds to a row: Feed rooms for announcements, Kanban and Table Boards for the split task-tracking rows, Docs and Wiki for their respective rows, Check-in rooms for the pulse checks, Q&A rooms to finally give "how do I..." a home with memory. If you're comparing specific tools you'd be replacing, the compare pages map them one by one.

Phase 4: Migration Sequencing — What Moves When

Never migrate everything at once, and never migrate in random order. Sequence by two variables: pain relieved (how much daily friction disappears when this job moves) and anchor weight (how hard the move is, from Phase 1's switching anchors). Move high-pain, light-anchor jobs first.

A sequencing pattern that works for most teams:

Wave	What moves	Why this order
Wave 0 (week 1)	One pilot team moves everything they do	Finds the sharp edges while the blast radius is one team; produces your champions
Wave 1 (weeks 2–3)	New work only: announcements, polls, new projects, new docs	Zero data migration, immediate visible activity — the platform looks alive, not empty
Wave 2 (weeks 4–6)	Active work: current boards, in-flight projects, standups, retros	The daily-habit jobs; heaviest change-management load, so it gets the most support
Wave 3 (weeks 7–10)	Knowledge: docs, wikis, process pages — curated, not bulk-copied	Migrate the 20% of pages with recent views; archive the rest as read-only export
Wave 4 (weeks 11–12)	Stragglers, integrations, and the long tail; old tools go read-only	Endgame; see Phase 5

Three sequencing rules worth underlining:

• Wave 0 is not optional. A pilot team that has lived in the new platform for two weeks before the company arrives gives you tested setup decisions, honest FAQ answers, and advocates who aren't the buyer. Choose a friendly-but-honest team, not the most enthusiastic one.
• "New work first" beats "old data first." Empty platforms die. If people's first experience is a ghost town while a data migration grinds along, they bounce. If their first experience is this week's announcements and this sprint's board, the habit forms and the data can follow.
• Curate knowledge, don't bulk-move it. Wholesale-importing 2,000 wiki pages transfers your mess to a new address. Move what's been viewed in the last quarter, rewrite the ten most-used pages properly, and archive the corpse as a searchable export. Teams that skip curation report the same complaint six months later: "the new wiki is just as bad as the old one." Of course it is — it's the same wiki.

Phase 5: Parallel Running and the Cutover

Some parallel running is inevitable; unmanaged parallel running is how consolidations die. The discipline that keeps it short:

• Every wave gets a read-only date. From the day a job moves, its old home has a announced date — two to four weeks out — when it goes read-only. Not deleted: read-only. People can look things up; they cannot add. Read-only is the mechanism that converts "the official tool changed" from an aspiration into a fact, while staying humane about reference needs.
• One direction of truth during overlap. During the parallel window, the new platform is canonical and the old tool is a mirror at best. Never sync bidirectionally "to be safe" — dual-write is how you get two half-true systems and a reconciliation job nobody wanted.
• Leaders switch first and visibly. The single strongest adoption signal is where leadership posts. If the CEO's updates appear in the new feed and the old chat channel goes quiet at the top, the org follows in days. If executives keep using the old tool "just for quick things," everyone correctly reads the consolidation as optional.
• Kill dates are contract dates. Put cancellation on the calendar against the renewal dates from your inventory, and let the finance deadline backstop the project deadline. A consolidation with no cancellation dates is a subscription-growth project.

Phase 6: Change Management — The Human Migration

The data migration is the easy half. The human migration decides the outcome, and it runs on three tracks:

Champions. Recruit one per team — ideally from the Wave 0 pilot — with a real mandate: they get input into setup decisions, early access, and a direct line to the project owner. Their job is not cheerleading; it's translation. "Here's how our team's workflow maps onto the new boards" lands from a peer in a way no rollout email can. Budget them two or three hours a week during their team's wave.

Communication that respects the reader. Announce the why before the what: the audit numbers, the daily frictions being removed, and — credibility matters — what will be worse in the new setup, named honestly, with the reason the trade is still right. Then per wave: what moves, what date, what dies, where to get help, in five sentences. Repeat each message at least twice in different channels; announcement singularity is a myth. Handle the split-row political fights from Phase 2 privately and early — the two teams with rival PM tools need a decision meeting with their leads, not a surprise in a rollout email. Expect to trade: one team gets its structure preserved, the other gets first pick on template setup.

Training shaped like work. Nobody attends "Introduction to the New Platform, Session 3." Run 25-minute sessions per job — "your standup now works like this," "where documents live now" — recorded, at wave time, when the knowledge is immediately usable. Pair each with a one-page "old way → new way" crib sheet per team, written by the champion. The crib sheet outperforms every other training artifact, because it answers the only question people actually have: where did my thing go?

And expect the resistance curve: enthusiasm from the frustrated, silence from the majority, sharp pushback from power users whose elaborate workflows don't transfer. Take the power users seriously — they're often right about specific gaps — and give them a named channel to report holes, with visible fixes. A power user whose gap gets closed in a week becomes your loudest advocate; one who gets ignored becomes the resistance's quartermaster. For the deeper mechanics of moving people between tools without losing them, see Migrating Tools Without Losing Your Team (or Your Data).

Phase 7: Sunsetting — Exports, Archives, and Actually Canceling

The unglamorous phase that makes it real:

1. Full export from every departing tool, even the ones you migrated from, even the free tiers. JSON or CSV plus attachments, stored in cold storage with a README saying what it is and what format it's in. You will need something from it in eight months; budget for that day.
2. Read-only period ends on schedule. When the announced date arrives, access ends. Keep one admin account alive through the export-verification window, then close it.
3. Cancel in writing against contract terms. Auto-renew clauses commonly require 30–60 days' notice. Send cancellations early, confirm receipt, and calendar the final billing date to verify the charges actually stop. Companies routinely pay for "canceled" tools for quarters.
4. Revoke the periphery. OAuth grants, API keys, webhook endpoints, SSO entries, browser extensions. Each departing tool leaves residue; sweep it.
5. Update the map. Your tool ledger, onboarding docs, and "where things live" page all change. New hires should never learn a dead tool's name.

Phase 8: Measuring the Win

You made a business case in Phase 1; now close the loop, because the next hard change you propose will be judged on whether this one delivered. Measure four things, before and after (30/90/180 days):

• Hard savings. Canceled subscriptions in dollars, against the audit baseline. This number is unambiguous — publish it.
• Tool count per workflow. Pick three common workflows (ship a feature, run a campaign, onboard a hire) and count the tools each touches. This is the metric that captures the actual point of consolidating; a workflow going from six tools to two is the win, stated plainly.
• The pulse question, re-asked. Whatever you asked in the audit ("how much time do you lose to hopping and hunting daily?"), ask again at 90 days. Self-reported, imperfect, and still the best available measure of the attention dividend.
• Adoption honesty. Weekly active users in the new platform versus lingering activity anywhere old. If an old tool still shows activity past its read-only date, you have a workflow gap to close, not a compliance problem to enforce — find the job that never got a home.

Report all four in one short update to the whole company. Consolidations have a long memory; a published win buys you the credibility for the next one.

The 90-Day Version, Compressed

1. Weeks 1–2: Run the audit; build the capability matrix in one workshop; identify the cluster, the anchors, and the political split-rows.
2. Weeks 3–4: Trial finalists against the matrix with one real team; choose; make the case with the audit numbers; recruit champions.
3. Weeks 5–6: Wave 0 pilot; setup decisions and crib sheets come out of it.
4. Weeks 7–12: Waves 1–3 with read-only dates trailing each; leaders switch first; champions run the crib sheets; power-user gaps triaged weekly.
5. Weeks 12+: Wave 4, exports, cancellations, residue sweep; measure at 90 days and publish the result.

Ten apps to one is a real outcome, but the honest goal is ten apps to few — a connected core plus the two or three specialist tools that earn their keep. If your consolidation cluster looks like most teams' — feed, boards, docs, wiki, whiteboards, check-ins scattered everywhere — Openbook was built to be that core: compose the rooms you need, search everything from one place, and cancel the rest. Start with the free plan, run your Wave 0 pilot on it, and let the pilot team tell you whether the matrix rows get their P.