A partner at a small firm described it plainly: "The software side of running cases bothers me more than the legal work itself." That shows up in attorney communities consistently, and the frustration is specific: a system built or bought to solve a problem that is now creating new ones.
What happens next is the interesting part. Some firms cut their losses. Others try to fix it. Most don't know which call is correct until they've spent more money on the wrong one.
This is the diagnostic we use when a law firm brings us a broken system.
Two types of broken law firm software
Before the diagnostic, it helps to name what "broken" means in this context. There are two distinct failure modes in law firm software, and they point toward different outcomes.
The customization failure. The firm is on a commercial platform (Clio, Filevine, MyCase, or similar) and something built on top of it has stopped working: an intake pipeline that dropped, a custom reporting layer producing wrong numbers, a webhook that silently fails, an API connection to document management that broke after a platform update. The platform is fine. The layer built over it is not.
The custom build failure. The firm or a developer they hired built a bespoke system from scratch. The system worked for a while, or never quite worked. The original developer is unavailable or the code is undocumented. The system now holds case data hostage while the firm decides what to do with it.
The resolution path differs between these two. The customization failure is almost always a rescue: the underlying data model is sound, the platform isn't going anywhere, and the broken piece is contained. The custom build failure is the harder call. It can go either way based on three questions.
The diagnostic: three questions
1. Is the core data model sound?
Before any line of code, a legal system is an opinion about how to represent cases, contacts, documents, and billing. If that opinion is correct, the system can be rebuilt around it. If the underlying schema is a tangle of compromises (matters stored as flat text, contacts mixed with opposing counsel, documents not linked to cases) then you're not rescuing the software, you're rescuing the data from the software.
The quickest test: ask a developer to describe what happens when a case is opened, how documents are linked to it, and where the billing record lives. If the explanation makes sense in 90 seconds, the model is probably sound. If it requires extended qualification to cover the workarounds, the model is probably not.
2. Is the code accessible and does anyone understand it?
Undocumented code with no original author available is often faster to replace than reverse-engineer. Reverse-engineering a bespoke legal system built by a single developer over three years, with no comments and no tests, takes roughly the same amount of time as rebuilding it and carries the additional risk that you rescue something that shouldn't have been built the way it was.
Accessible code means: the repository exists and you can reach it, there is some documentation or a developer who can answer questions, and the technology stack is current enough that a modern team can work in it. None of these need to be perfect. All three being absent is a replacement signal.
3. Is there a compliance or regulatory deadline?
If there is, rescue is almost always the right call regardless of code quality. Replacement takes longer than repair. A clean replacement is typically an 8-20 week project from scoping to go-live. A targeted repair to address a compliance gap or deadline-critical failure can usually be completed in 4-6 weeks.
We built this priority into practice directly. A federal regulatory compliance platform, a case tracking and management system for a regulated agency, came to us with 8 weeks before a statutory deadline and software that had not been updated in over a year. Replacement was not viable given the timeline. We rescued it: rebuilt the broken modules around the existing data model, remediated the compliance gaps, and had a production-ready system three weeks before the deadline.
What rescue looks like in practice
A rescue engagement for law firm software runs in three phases regardless of whether the final outcome is repair or replacement.
The three phases
- Assessment (weeks 1-2): Codebase audit, data model review, integration mapping, and compliance gap analysis. Output: a written assessment of what is broken, what is salvageable, what compliance obligations the fix must satisfy, and a fixed-price recommendation.
- Rebuild (weeks 3-6+): Targeted repair of broken components or full rebuild around the sound architectural decisions. In a legal context this phase also includes data migration planning and privilege-chain documentation.
- Stabilization (weeks 6-8+): Testing against real case data, integration verification with document management and e-filing tools, and handoff with documentation sufficient for the firm's internal team to operate without the rescue firm.
Timeline varies by scope. A repair of a single broken integration, such as a Filevine webhook that stopped syncing or a Clio billing export producing wrong numbers, is 4-6 weeks. A full system recovery with data migration and core module rebuild is 8-12 weeks. The fastest outcomes come from firms that provide codebase access immediately and a clear written description of what stopped working and when.
The compliance layer general rescue firms miss
Legal software rescue is not the same as general software rescue. The difference is not technical difficulty. It is compliance obligation. Three constraints follow case data wherever it moves, and a rescue firm without direct legal tech experience will deliver a working system that creates new bar exposure.
Attorney-client privilege in transit. During data migration from a failing system to a repaired or replacement system, case data is in motion. That motion does not suspend confidentiality obligations. A competent rescue firm handles migration with the same access controls as the production systems: encrypted transfer, scoped access, no case data on general-purpose developer machines, and documentation of who touched what during the migration.
ABA Formal Opinion 512 if the system uses AI. If the failing or rebuilt system incorporates AI tools for document review, drafting assistance, or case analysis, Opinion 512 requires that the firm can demonstrate what the AI did and that an attorney supervised it. That means the rebuilt system needs an audit log of AI interactions with client data as a day-one requirement, not a feature to add later. A rescue firm that has not read Opinion 512 will deliver a clean system that is a bar complaint away from becoming a problem.
Integration with court rules and e-filing. If the system connects to PACER, CourtListener, e-filing systems, or jurisdiction-specific docket tools, those connections carry technical requirements and must be verified on day one of the rescue deployment. These are the integrations most likely to break silently after a platform update and the integrations most likely to cause a missed deadline if they are not confirmed working before handoff.
None of this is unusual. It is the baseline for legal software work. The reason it matters in a rescue context is that the general software rescue market treats these obligations as optional scope to be priced separately. We treat them as the starting point.
What to look for in a rescue firm
- Direct legal tech experience. Not "we have worked with regulated industries" specifically. The firm should know Clio, Filevine, MyCase, and what attorney-client privilege requires during a data migration. Generic software rescue shops will build a technically correct system that violates bar rules.
- Fixed-price after assessment, not open-ended hourly. Rescue work with no price ceiling has no natural stopping point. A firm that will not commit to a fixed scope after the assessment phase is either not confident in their diagnosis or is optimizing for billing hours rather than recovery speed.
- Assessment before commitment. Any credible rescue firm wants to see the codebase, the data model, and the compliance context before quoting the build. Walk away from any firm that quotes a rescue without asking to see what they are rescuing.
- Compliance as default, not add-on. Privilege-safe data migration, ABA Opinion 512 audit logging if AI is involved, and e-filing integration verification should all be in the scope description unprompted, not offered as add-ons to negotiate.
Any credible rescue firm wants to see the codebase before they quote it. Walk away from any firm that quotes a rescue without asking to see what they are rescuing.
The Oktopeak rescue path
We build software for regulated industries: legal tech, healthcare, and compliance-critical systems. Rescue work is part of what we do alongside new builds, and the regulated-industry constraint means the compliance layer is built into every engagement.
How the engagement works
- Rescue Audit ($2,420 fixed): 2 weeks. We review the codebase, data model, integrations, and compliance posture. You receive a written assessment of what is broken, what is salvageable, what compliance gaps exist, and a fixed-price scope for repair or replacement. No commitment to the build until you have the assessment.
- Rescue or rebuild (fixed price, scoped from audit): Builds start at $12,000; the exact figure comes from the audit findings, not from a guess on a call. Fixed price, fixed timeline, agreed scope before any work begins.
- Stabilization and handoff (included): Testing against your actual case data, integration verification, and documentation sufficient for your team to operate the system without us.
Start with the audit, not the commitment
If your law firm software is failing and you are not sure whether it is fixable, the audit is the right starting point. It gives you a written assessment of what is actually wrong and what it would take to fix it, before you commit to anything. Fixed price, two weeks, no open-ended billing.
Book a call →If your case management setup uses Clio, Filevine, or MyCase as the base platform, we also maintain open-source MCP connectors that extend Claude's AI capabilities directly into your practice management data, including read/write access, ABA 512 audit logging, and encrypted credential storage. See the connector comparison, the Filevine MCP hub, or the software rescue service page for the full picture.
