What Happens When Your Case Management System Goes Down

Every fee earner in the building tries to open a matter file at nine o’clock and nothing loads.

That is the moment most firms discover what their continuity plan is actually worth. Not the document in the compliance folder. The real one, which is whatever happens in the next thirty minutes.

This is a practical guide to what goes wrong, what to do in the first hour, and what needs to be true in advance for a bad morning to stay a bad morning rather than becoming a bad quarter.

Why case management outages hurt more than ordinary IT problems

When email goes down, people are inconvenienced. When case management goes down, the firm stops.

Your practice management system is not one application. It is the diary, the matter files, the time recording, the client ledger, the precedents, the workflow, and increasingly the phone integration and the document store as well. Lose it and you lose the ability to answer a straightforward question from a client about their own matter.

Three things make it worse for a law firm than for most businesses.

Deadlines do not move. A court deadline, a limitation date or a completion date is not sympathetic to an outage. Everything else can wait a day. These cannot.

Money is in flight. Conveyancing and probate teams may be mid-transaction with funds committed. An outage during a completion window is not an IT problem, it is a client problem with a financial consequence attached.

You still have to know what happened. If the outage involves data, the clock on your reporting duties starts when you find out, not when you finish fixing it. A reportable personal data breach must reach the ICO within 72 hours, and a serious breach of the SRA’s Standards and Regulations must be reported under Rule 3.9 of the Code of Conduct. Both of those are far harder to judge when nobody can see the system. We cover the wider picture in our guide to SRA IT requirements for solicitors.

What actually takes these systems down

In our experience the cause is rarely exotic.

The hosting provider has an outage. If your system is vendor-hosted, you are dependent on their infrastructure and their communication. You cannot fix it. What you can control is how quickly you know, and what you do while you wait.

The server or its host has failed. For on-premise systems, this is hardware, storage, or the virtual host underneath. Recovery time depends almost entirely on whether someone has tested restoring it.

The database has become corrupted. Often after an interrupted update or a storage fault. This is the one that catches firms out, because backups may have been faithfully copying a corrupted database for some time.

Connectivity has gone. The system is fine. You cannot reach it. A single broadband line with no failover turns a supplier’s roadworks into your outage.

Ransomware. Less common than the headlines suggest, far more serious when it happens. This is not a restore, it is an incident, and it brings reporting duties with it.

An update went wrong. Applied without a rollback plan, usually at the least convenient moment.

Knowing which of these you are in changes what you do next, which is why the first job is never “fix it”.

The first hour

The order matters. Most firms get this wrong by starting at step four.

1. Establish scope, not cause. Is it one user, one office, or everyone? Can anyone reach the system from outside the building? Is it just case management, or is email affected too? Five minutes here saves an hour of chasing the wrong problem.
2. Decide who is running this. One person, named in advance, who makes the calls and owns communication. Not a committee, and not whoever happens to be least busy.
3. Tell people something. Fee earners will otherwise spend the morning individually rebooting laptops and ringing the same helpdesk. A single message saying what is known, what is not, and when the next update is coming buys you an enormous amount of calm.
4. Now fix it. Or escalate it to whoever can, with the scope information from step one.
5. Start the log. What time it started, what was seen, what was done. If this later turns into a reportable incident, this log is the difference between a defensible account and a guess.
6. Protect the deadlines. Someone should be working out what is due today and this week, independently of the system, while the technical work happens. This is the step most often forgotten and the one clients notice.

Worked example: a Monday morning that stayed manageable

The following is an illustrative scenario rather than a specific client. It is built from the pattern these incidents commonly follow, and the timings reflect what is achievable when the preparation described below is genuinely in place.

08:52. A conveyancing assistant cannot open a matter. She assumes it is her laptop and restarts it.

09:05. Four more people report the same thing. The practice manager, who is the named incident owner, checks whether the system is reachable from her phone on mobile data. It is not. That rules out the office network and points at the system or the host.

09:10. She sends one message to all staff: case management is unavailable, the cause is being investigated, next update at 09:40, do not restart machines. She contacts the IT provider with what she already knows, which means the engineer starts from a position rather than from scratch.

09:15. The IT provider confirms the vendor’s hosted platform is down and it is affecting multiple firms. Nothing can be fixed locally. Focus shifts entirely to working around it.

09:20. The continuity plan is opened. Three things happen at once. The head of conveyancing pulls today’s completions from the exported diary held outside the system. Time recording moves to paper, with a note that it must be entered retrospectively. The reception team is briefed on what to tell clients, in one agreed sentence rather than seven improvised ones.

09:40. Second update to staff, on time. Still down, still no cause, next update at 10:30. Being on time matters more than having news.

11:15. Service is restored by the vendor. The IT provider verifies that the data is intact and that the last transactions before the outage are present, rather than assuming.

11:30. Staff are told they are back, and told specifically what to check and what to re-enter.

Afternoon. The practice manager writes up the log while it is fresh. Because no client data was lost or exposed, no ICO notification is required, but the assessment is documented so the reasoning is recoverable if anyone asks later.

The following week. The firm asks the vendor for a written incident report and reviews two things: whether the diary export should run more frequently than weekly, and whether the reception script was actually good enough.

Two and a half hours down. No missed deadline. No client who felt uninformed.

Now consider the same outage at a firm with no named owner, no exported diary, no agreed message and no log. Same two and a half hours of downtime, an entirely different day.

What has to be true in advance

None of the above is possible to invent on the morning. Six things need to exist beforehand, and they belong in a written plan. If you do not have one yet, our free business continuity plan template walks you through most of them in a few minutes.

A named incident owner, and a deputy. Someone has to decide. If it is not agreed in advance it defaults to whoever is loudest, which is rarely the right person.

A way to reach today’s deadlines without the system. A regular export of the diary and key dates, stored somewhere that does not depend on the system being up. This is unglamorous and it is the single highest value item on this list.

Backups you have actually restored. Not backups that report success. A backup is a theory until someone has restored it. Test restores should happen on a schedule and the results should be written down.

A known recovery time, and a known recovery point. How long it takes to get back, and how much work you lose. Most firms have never asked and are surprised by both answers. If your system is vendor-hosted, these are the vendor’s numbers and you should have them in writing.

A second route to the internet. Failover connectivity is inexpensive relative to a day of lost trading, and it removes an entire category of outage.

An agreed message. One paragraph for staff, one for clients. Written when nobody is panicking.

The question to ask your provider

Whether your system is hosted by the vendor or running on your own server, one question separates a real answer from a comfortable one.

“If our case management system was unavailable at nine tomorrow morning, walk me through exactly what happens, who does what, and when we would expect to be working again.”

If the answer is confident, specific, and includes who calls whom, you are in reasonable shape. If it is a reassurance about the quality of the backups, you have found a gap.

The follow-up is just as useful: “When did we last test that?”

Where ATS fits

ATS supports law firms using both vendor-hosted and on-premise case management systems, including environments built around platforms such as LEAP, Clio and Actionstep. In practice, most of what determines how a bad morning goes is not the case management system itself but the environment around it, and that is where our role usually sits: Microsoft 365, user access, networking and connectivity, security, backups and day-to-day support.

The work that matters here is the boring work. Knowing your recovery time before you need it, testing restores rather than trusting reports, keeping deadlines reachable when the system is not, and having the plan agreed before the morning it is needed.

If you are not confident what would happen at nine tomorrow morning, our free IT and cyber benchmark is a straightforward place to find out. You can also read more about IT support for solicitors and backup and disaster recovery.

Frequently asked questions

What should a law firm do first when the case management system goes down?

Establish scope before cause. Find out whether it affects one user, one office or everyone, and whether the system is reachable from outside the building. Then confirm who is running the incident, send one clear message to staff, and only then begin fixing or escalating. Separately, someone should identify the deadlines falling due today while the technical work happens.

How long should it take to recover a case management system?

It depends entirely on the setup and on whether recovery has been tested. The important thing is that the firm knows its recovery time and recovery point in advance rather than discovering them during an incident. If the system is hosted by the software vendor, those figures should be obtained from the vendor in writing.

Do we have to report a case management outage to the SRA?

Not automatically. An outage alone is not necessarily reportable. A serious breach of the SRA’s Standards and Regulations must be reported under Rule 3.9 of the Code of Conduct, and separately a reportable personal data breach must reach the ICO within 72 hours of the firm becoming aware. Those are two different duties with two different thresholds, which is why keeping a log from the first minute matters.

Is a cloud-hosted case management system safer than an on-premise one?

Neither is inherently safer. Vendor hosting removes hardware failure and usually improves resilience, but it also removes your ability to fix the problem and makes you dependent on the vendor’s communication. On-premise gives you control and makes recovery your responsibility. Both need a tested plan.

How often should backups be tested?

Regularly, and to a schedule with the results recorded. A backup that has never been restored is an assumption. Database corruption in particular can be copied into backups for a long time before anyone notices, which is why a test restore matters more than a successful backup report.

What is the most common cause of legal software downtime?

Rarely anything exotic. Hosting provider outages, server or storage failure, database corruption after an interrupted update, loss of connectivity where there is no failover, and updates applied without a rollback plan. Ransomware is less common than the coverage suggests but far more serious, and brings reporting duties with it.