How to Audit an Inherited Legal Tech Stack: What to Keep, Kill, or Leave Alone

Two weeks into the job, the new Head of Legal Operations opens a spreadsheet their predecessor left behind. Fourteen tools. Six with active contracts, four with expired licenses nobody cancelled, two that nobody on the current team can remember being implemented, a CLM that cost six figures and is used by three people, and a case management system that exists primarily as a place where legal requests go to be forgotten.

The instinct in week three is to start cancelling licenses and consolidating tools. And while that instinct is mostly correct, the execution is where people get it wrong.

So in this blog, we will explore a working framework for deciding what to keep, what to kill, and what to leave alone in an inherited legal tech stack. 

Confirm Your Understanding of Processes & Foundations

A common mistake that new legal leaders make is reading the technology stack as a list of tools. The stack is actually a list of decisions as every tool was bought because someone, at some point, was trying to solve a problem. Sometimes the problem was real and the tool solved it. And other times the problem was real and the tool didn't. Sometimes the problem changed and the tool stayed.

The diagnostic question that comes before any keep-kill-leave decision is: What was each tool bought to solve, and is that problem still the right problem to be solving?

Answering that question requires understanding the workflow that each tool was supposed to support, who was supposed to use it, and what state the function was in when the purchase was made. For instance, legal software that was bought during a hyper-growth phase three years ago was likely solving a different problem than the one your function has today.

There's one more thing worth checking before you start sorting tools into categories. Make sure your function actually has a structured intake and triage process that sits at the top of the existing legal technology. Most inherited stacks were assembled around contracting, e-signature, or matter tracking, with little attention paid to how work enters legal in the first place. If that upstream layer is broken or missing, you can't reliably judge whether any tool downstream is working.

For example, a CLM with low adoption looks like a failed CLM, and a matter management system full of stale data looks like a failed matter management system. In reality, those tools are being judged on whatever survived a chaotic intake process, not on their own merits.

So, it is important to first confirm whether that layer is in place, or at least account for its absence, before you start making decisions about everything downstream.

What to Keep in Your Legal Tech Stack

The easy cases are obvious. For instance, a CLM with strong adoption and a clean integration path, an e-signature tool that's embedded in how the business actually works, or a matter management system that the team trusts typically stay.

The harder cases to distinguish are tools that are partially adopted but solving a real problem. The temptation is to kill them and start over. However, the smarter move is usually to figure out why adoption is partial before you write off the tool. 

Sometimes the answer is the tool itself. More often than not, the answer sits somewhere else in the process. It could be that work isn't reaching the tool in a structured way, the handoff between the requester and the lawyer is broken, or the team trained on the tool has turned over twice since implementation. None of those are reasons to kill the tool per se. Instead, they offer a strong case to fix what's happening around it.

What to Kill: Legal Tech Tools to Cut from Your Stack

Some candidates for this typically include contract analysis tools no one opens, compliance dashboards that require manual data entry from three other systems to produce a report that one person looks at once a quarter, and AI tools bought during a board-driven AI initiative that solves a problem the legal function doesn’t actually have.

Why Cutting Tools Without Fixing the Operating Model Backfires

Killing tools doesn't create the savings most leaders hope for. The real savings come from fixing the operating model that made the redundant tools necessary in the first place. For example, if your team built three workarounds to compensate for the absence of a legal front door, killing the workarounds without implementing the actual front door just creates new ones. 

What to Leave Alone: Inherited Legal Tech Tools Not Worth Replacing Yet

This is the most under-discussed category, and the one where new leaders most often overreach.

This could look like the Microsoft Forms intake setup that someone built three years ago and the business has muscle memory for, the shared folder that’s functioning as a de facto knowledge management system, or the Slack channel that’s currently operating as a request queue.

The tools that look like the easiest wins are usually the most expensive mistakes, because they're load-bearing in ways the new leader can't see yet.

For example, the Microsoft Forms intake, however imperfect, is what the business currently uses to send work into the function. Getting rid of it before you've built something better leaves the business with nowhere to send work, and work doesn't stop arriving just because the form is gone. It routes through Slack DMs and hallway conversations instead, and the audit trail vanishes with the form.

Key Takeaways

The instinct to audit an inherited tech stack in your first 90 days is correct. The instinct to start with the tools is the part that gets people in trouble. Tools are downstream of operating models. Operating models are downstream of how work enters the function. Start there, and the rest of the decisions get clearer.

The new General Counsels and Heads of Legal Ops who get this right tend to spend their first quarter doing less than they expected. They keep more than they planned to keep, kill less than they planned to kill, and focus their attention on the areas that ensure everything downstream operates smoothly and in harmony.

If you're auditing an inherited legal tech stack and want the perspective from someone who's seen how high-performing legal functions structure theirs, schedule a call with one of our technology consultants today.