Too Many Tools, Not Enough Value: How to Consolidate Without the Regret

If you’ve ever opened your software bill and thought, ‘what on earth is all this?’, you’re not alone.

Software spend is back at the top of the list for pretty much every CFO and CIO we talk to across Australia and New Zealand. Not because anyone has suddenly worked out that SaaS is expensive, but because the easy savings are gone. Headcount has been squeezed. Contracts have been renegotiated. What’s left is the harder question: are we actually getting value out of the forty-odd tools we’re paying for?

We ran a four-part series on this last year called Strategic Software, and what came out of it was uncomfortable but consistent. Most organisations aren’t overspending because they made bad purchases. They’re overspending because nobody owns the portfolio as a whole.

Let’s take a look at what sprawl is really costing you, how to run a consolidation that actually sticks, and some of the patterns we come across most often.

The Real Cost Isn’t on Your Invoice

There’s a whole genre of content out there that counts your apps and tells you the number is too high. It isn’t very useful. Plenty of organisations run a wide stack brilliantly, and plenty run a narrow one badly.

The costs that matter are the ones that never show up as a line item.

When Steven Baker of Node (formerly VendorSage) joined us for the series, he shared numbers we’ve been repeating in client conversations ever since:

• Organisations have visibility into only about 30% of their SaaS footprint
• Around 88% are overpaying
• Roughly 70% of implementations don’t deliver what they were bought to deliver
• 75% of software contracts sit on auto-renew, costing about 15% in worse commercial outcomes versus a negotiated renewal

His summary says it best: “You have the opportunity to optimise somewhere between 20-40 percent of every dollar you spend on software.”

Then there’s the friction cost, which is harder to see and usually bigger. Forrester’s 2024 research found 75% of IT decision-makers report moderate to extensive technology sprawl. Okta’s Businesses at Work data has consistently shown that fewer than 28% of the tools in a typical stack actually talk to each other.

So who fills the gaps? People do.

Someone exports a CSV every Monday. Someone maintains the spreadsheet that reconciles two systems. Someone’s actual job, quietly, has become keeping things in sync.

ClickUp has done a fair bit of work on this under the banner of Work Sprawl, splitting it into app sprawl, process sprawl, context sprawl and AI sprawl, and arguing that each one creates the conditions for the next. Some of the headline figures in their report come from ClickUp’s own surveys rather than independent research, so treat those as directional. But the shape of the argument holds up.

That last pillar is the newest problem and probably the most consequential. AI only produces useful output when it can see enough context. If your project data is in one system, your decisions are in a chat tool and your documentation is somewhere else again, you’ll get thin results no matter which model you’re paying for.

Fragmented systems now produce fragmented intelligence. That’s a cost that didn’t exist three years ago.

Why Consolidation Projects Go Sideways

Most consolidations that go wrong go wrong for the same reason. They get run as a procurement exercise instead of a workflow exercise.

You’ve probably seen the pattern. Finance pulls the spend data, spots the overlap, picks the tool with the biggest licence count as the survivor, and mandates that everyone moves onto it.

Six months later the savings haven’t materialised. Half the teams quietly kept using the old tool, or replaced it with something on a credit card.

Three Playbooks That Still Hold Up

Steve’s framework from the webinar is still the clearest we’ve come across:

• Rationalise first. Give every tool a job description and measurable KPIs, the same way you would a role. Tools without a defined job get retired. It sounds administrative, but it surfaces duplication faster than any spend analysis, because it forces someone to say out loud what a tool is actually for.
• Then consolidate. Map your technology against how work actually flows, not against your org chart. Two teams doing genuinely different work in different tools is fine. Two teams doing the same work in different tools is the problem.
• Then procure smarter. Start renewal conversations 90 to 120 days out. Use real usage data. Build price-uplift caps into the contract.

In another session in the series, Rick Earl added something we keep coming back to: the idea of a roadmap of roadmaps. Consolidation isn’t a project with an end date. It’s a continuum that has to account for change appetite, economic conditions, regulatory shifts like data residency, vendor behaviour and your own internal capability.

Sometimes the right answer is to consolidate now. Sometimes it’s to hold, because the team simply can’t absorb another change this quarter.

His other point is the one most people miss. Rationalisation often means fewer tools without fewer features, because platforms have absorbed capability that used to need add-ons. The functionality you’re paying a third party for may already be sitting unused in something you own.

We saw exactly that at Zip. Five or six add-ons they were paying for turned out to be unnecessary once they moved to Enterprise, because the functionality was already built in. That alone was around US$50k a year.

That pattern has only become more common in the last twelve months.

Patterns We Come Across

None of what follows is a recommendation.

Every stack is different, and the right answer depends on things a blog post can’t see: your team’s appetite for change, what you’ve already got sitting unused, what you tried two years ago that left a bad taste.

What we can offer is the situations that come up most often, what we’ve seen work in each one, and where it tends to fall over. Treat them as prompts, not prescriptions.

Non-Development Teams Working Around Jira

The most common one we see. Jira went in for engineering, it worked, and over time marketing, ops and HR got pulled in because it was the tool that existed.

Now those teams are working around it. They use Jira as a task list and do their real coordination in email and chat, while someone in the PMO rebuilds status for leadership every fortnight.

What we’ve seen work: the instinct is to pick one platform and move everyone onto it. More often, the better result comes from letting each group work where it suits them and connecting the two properly. Asana’s Jira Cloud Data Sync handles two-way sync between an Asana project and a Jira project, covering tasks, subtasks, custom fields, comments and dates. Business teams raise Jira issues from inside Asana without leaving their workflow, and engineering doesn’t change a thing.

Where it doesn’t hold up: if the non-dev work is genuinely delivery work with the same rigour requirements, the sync layer is overhead and the fix is configuration, not a new tool. And in our experience engineering is better left in Jira regardless. Pulling them out to hit a consolidation target tends to cost more than it saves.

Two platforms with a clean boundary is a perfectly good end state.

Chat Has Quietly Become the Project Management System

Slack or Teams as the centre of gravity, with work scattered across whatever each team picked up along the way. Decisions get made in threads and then vanish. The recurring meeting exists purely to sync information between systems.

What we’ve seen work: when chat has become the work management layer by default, pulling conversation and work into the same place removes an entire category of problem. ClickUp comes up most often here, partly because it’s invested heavily in chat and partly because its Slack importer brings across channels, settings and message history. The value isn’t the chat feature on its own. It’s that a message can become a task with its context still attached, rather than being retyped somewhere else.

Where it doesn’t hold up: if Slack or Teams is working well and your work management is already sound, leave it alone. Replacing a functional chat tool is disruptive, and the change management cost usually outweighs the licence saving. This only pays off when chat is compensating for something missing elsewhere.

Spreadsheet and No-Code Sprawl

Airtable here, Smartsheet there, and a dozen critical Google Sheets that only one person fully understands. This is the quietest form of sprawl and often the riskiest, because the business logic lives in someone’s head rather than in a system.

What we’ve seen work: rehousing the work somewhere it stays visible. ClickUp handles this well, since custom fields, formulas, relational structures and multiple views over the same data cover most of what these tools are actually being used for. The bigger win is that the logic ends up somewhere the whole team can see it. It also tends to be the easiest consolidation to get agreement on, because nobody is emotionally attached to a spreadsheet.

Worth keeping an eye on this one. We’re hearing ClickUp has a dedicated spreadsheet capability in the works, which would close the gap on the more spreadsheet-native tools considerably. If that lands as expected, the case for pulling this category of sprawl into one place gets a fair bit stronger.

Where it doesn’t hold up: if you’re doing genuine database or analytics work rather than tracking work, a work management platform is the wrong home for it. Don’t force it, at least for now.

Leadership Can’t See How Work Connects to Strategy

Different problem, and a common one in bigger cross-functional organisations. The delivery tooling is fine. What’s missing is the line from company objectives down to what teams are actually doing, so it gets rebuilt by hand in slide decks every quarter.

What we’ve seen work: solving the visibility problem on its own, rather than treating it as a reason to replace the delivery tooling. Asana’s goals and portfolio model is built for exactly this, and the strategy-to-execution linkage is the strongest part of the product. Folding scattered planning spreadsheets and status decks into that structure is usually cheaper and far less disruptive than a full migration.

Where it doesn’t hold up: if the real issue is that nobody agrees on the objectives, no tool will fix it. Sort the goals out first.

Point Tools Stacked Around the Service Desk

You’re an Atlassian shop paying separately for PagerDuty, running a standalone customer service tool alongside your internal service desk, and carrying a separate asset management product. The economics have shifted in your favour here.

What we’ve seen work: checking what you’re already entitled to before renewing anything adjacent. Jira Service Management is now packaged as part of Atlassian’s Service Collection, alongside Assets, a new Customer Service Management app and service-focused Rovo agents. Existing JSM plans transitioned automatically from February 2026, at the same pricing tiers. On-call and incident management were already native, so the PagerDuty case Rick made in his session has only got stronger, and customer service is a genuinely new addition rather than a repackaging of something you already had.

This is a well-trodden path for us. At Pepperstone we moved contract management, website change requests, incident management and IT asset management onto JSM, including migrations off Zendesk and Snipe-IT. At Zip we took eight separate JSM projects down to one and removed a paid procurement add-on by using native functionality instead.

Where it doesn’t hold up: if you’re not otherwise invested in Atlassian, this isn’t a reason to become invested. The value comes from consolidating onto a platform you already run.

Paying Enterprise ITSM Prices for Mid-Market Requirements

The other direction entirely, and one we see regularly. An organisation bought ServiceNow, usually for good reasons, and is now carrying enterprise licensing plus per-module fees for a fraction of the capability they use.

What we’ve seen work: starting from what’s genuinely being used rather than what was originally bought. ServiceNow is an excellent platform, and for large enterprises with the depth of requirement and an internal team to run it, it earns its cost. Plenty of organisations paying for it don’t need that depth. The module structure is where it bites, because every capability added is another commercial conversation, with implementation and maintenance load on top.

Freshservice tends to come into these conversations because it covers the large majority of what a mid-market ITSM team actually uses, it publishes its pricing openly rather than working quote-only, and it’s faster to stand up. Worth knowing that its AI capability, Freddy Copilot, is a separate add-on rather than included.

Where it doesn’t hold up: if you have genuinely complex enterprise requirements across multiple business functions and the team to support them, ServiceNow is the better platform, and switching to save licence cost will cost you more in capability. The deciding factor should be what you use, not what the invoice says.

What Good Looks Like Afterwards

Set your measurement up before you start, because the licence saving will end up being the least interesting number.

Track the direct spend reduction, obviously. But also track:

• How long it takes a new hire to become genuinely confident in the stack
• How many recurring meetings exist purely to sync information between systems
• How long it takes to answer ‘what’s the status of X’ without asking anyone

On the numbers that do show up, the returns can be quick. Harrison AI came to us with multiple Atlassian Cloud sites on separate monthly subscriptions and costs heading past AUD 789k inside two years. Consolidating into a single environment under Atlassian’s Teamwork Collection Premium bundle (which packages Jira, Confluence, Loom and Rovo) avoided AUD 229k over 24 months, returned 4.4x on the services investment and broke even within six months. The whole migration ran in four weeks to beat a price increase.

Zip is the longer-horizon version of the same story: 36% off licensing in year one, 38% year on year, and more than $1M USD over five years.

ClickUp’s commissioned Forrester study points the same way, reporting 384% ROI over three years and a 60% cut in legacy tool costs. Vendor-commissioned studies are what they are, and results depend heavily on execution. But the direction is consistent with what we see on the ground: the coordination savings outrun the licence savings, usually by a wide margin.

Where to Start

You don’t need a full programme to get going. Two things will tell you most of what you need to know.

• Pull your finance data. List every piece of software you’re paying for, including the small ones. Steve’s advice was that finance data is the fastest route to visibility, and he’s right. You’ll find things you’d completely forgotten about.
• Ask each team leader one question. What do you do outside your official tools to get your job done? The answers point straight at where the sprawl is, because every workaround is a gap someone is filling with their own time.

From there it comes down to sequencing, appetite and where each capability should live. That’s the part worth taking your time over, and it’s where we spend most of ours.

We work across Atlassian, Asana, ClickUp and Freshworks, so we don’t have a commercial reason to care where your consolidation lands. We just care that you get the decision right.

Talk to one of our team today about your tooling consolidation and optimisation goals. You can contact us here.