Never Click "Update" in Your Practice Management Software
William “BJ” Pote
CEO, eTop Technology
There is a button inside most legal practice management systems that says something like Help, then Update Software. It looks like the safe, official way to stay current.
It is the single most dangerous button in your firm.
What can go wrong, concretely
We have worked an incident that went like this, and the shape of it is worth understanding even if you never use the same product.
A firm ran the in-application update on a weekday morning. The installer that link served did two things at once. It jumped the software forward by roughly sixteen builds, and it migrated the underlying database from one engine to a completely different one.
Neither of those is routine. Together, in a single unattended step, they are a serious risk.
The conversion did not carry every record forward. The firm was locked out firm-wide that morning. Users were let back in around midday and carried on working, which is the detail that turned a bad morning into a bad week. Because by the afternoon, staff started noticing that the calendar was going backward. Trials that should have been there were not. Mediations were missing.
A well-intentioned partial restore made it worse, because restoring only the data folder onto the new engine left the system straddling two database formats at once.
The eventual fix was to go back to the verified pre-update database, confirm against known reports that the records were genuinely all there, and then apply a small, controlled step within the original engine. The firm’s data was intact up to the moment before the update. What had to be re-entered by hand was roughly half a day of work, reconstructed from a two-hundred-page audit report.
The four rules that would have prevented all of it
1. Updates to line-of-business software are vendor-driven, never self-service.
The vendor confirmed afterward that the in-app link intermittently serves the wrong installer. That is not a rare defect you can assume away. For practice management, billing, accounting and tax software, the update should be scheduled with the vendor or performed by your IT provider in coordination with them. Never by clicking the button because it appeared.
2. Paired backups immediately before, every time.
Not last night’s backup. Two backups taken right before you start: a full system image, and an in-application backup using the software’s own export. The image lets you put the machine back. The in-app backup lets you put the data back. You need both, because they fail in different ways.
3. Baseline reports before and after.
This is the step almost nobody does and it is the one that catches silent loss. Before the update, run three or four reports you know the answers to and screenshot them. Count of open matters. Count of upcoming trials. Calendar entries for the month. Then run exactly the same reports immediately after.
If the numbers match, you are done. If they do not, you have caught the problem in the first ten minutes rather than after half a day of new work has been layered on top of a broken database.
4. Treat a database engine change as a project, not an update.
If a release note mentions moving between database platforms, that is not a version bump. That is a migration, and it needs a scheduled window, a tested rollback, and the vendor on the call. Any version jump large enough to cross engines should be done in incremental, vendor-supervised steps.
The part that actually costs money
Notice where the real damage came from. Not the failed update itself, which was recoverable. It came from the gap between the update finishing and anyone realizing data was missing.
During that gap, people worked. They entered new information into a database that was already wrong. Every hour of that made the recovery harder, because now you cannot simply roll back without losing legitimate new work too.
That is the argument for baseline reports in one sentence: they close the gap between the failure and the discovery.
What to ask your IT provider
Ask how they handle a practice management update. A good answer includes: coordinating with the vendor, taking paired backups first, capturing before-and-after reports, and having a rollback plan they have actually tested.
If the answer is “we run the updater,” you now know what to fix, and you know it before it costs you a week.
Related reading
William “BJ” Pote
CEO, eTop Technology
eTop Technology has spent over 15 years in IT and over 12 years serving the Inland Empire as a trusted managed IT provider. We host the Business Tech Playbook podcast and are passionate about helping business leaders make smarter technology decisions.