Moving a paralegal office off MS Access: the risks you are carrying
Single-machine databases, fragile backups and no remote access. What an Access-based legal database really costs, and what a move to the cloud involves.
A great many Ontario paralegal offices still run on an MS Access database, often one that has been in service for fifteen years or more and has been shaped around exactly how that office works. There is nothing shameful about it. These systems were well matched to the problem when they were built, and a tool your staff know cold has real value.
The difficulty is that the risks accumulate quietly, and they are structural rather than fixable. This article is about naming them honestly, and about what moving actually involves.
Everything depends on one machine
In most offices running Access, one computer holds the real database file and everyone else connects to it across the office network. That machine is now the most important asset in the practice, and it is usually an ordinary desktop under somebody’s desk.
If it fails, gets replaced, or is simply switched off by someone tidying up, the office stops. Not slows down, stops. Nobody can open a file, check a court date or look up a client until it is back.
Corruption is a real failure mode
Access databases can and do corrupt, particularly when several people use them at once over a network, and particularly when a connection drops mid-write. Anyone who has run one for long enough has seen the compact-and-repair routine become a regular ritual.
The problem is not that repair usually works. It is that when it does not, the recovery position is whatever your last backup holds.
Remote work is a structural limitation
Access was designed for a local network. Working from home, from a courthouse, or from a second office means bolting something on: remote desktop into the office machine, a VPN, or a synchronisation arrangement. Each adds cost, latency and a new thing that breaks.
The same constraint is what makes a second office genuinely hard. You either duplicate the database, which creates two versions of the truth, or you pipe everyone through one location and accept the performance.
Who can still change it?
Access systems are usually maintained by one person, sometimes the original author, sometimes a consultant who has moved on. As the years pass, the number of people who understand the forms and queries shrinks, and at some point it reaches zero.
At that stage the system becomes fixed. You can use it, but you cannot adapt it, and every change in how you want to work has to be absorbed by your staff instead.
The good news: the data is portable
An Access .mdb file is a real relational database, and its tables can be read and exported with standard tooling. You do not need the application running, a licence, or cooperation from whoever built it.
This matters because it means your history is not hostage to the system holding it. The hard part of a migration is not getting the data out. It is working out what it means.
What the move actually involves
The sequence is the same regardless of who does it:
- 1Take a copy of the database. Your office keeps working, untouched.
- 2Export every table and examine what is genuinely there.
- 3Map your conventions: what your fields mean, how file numbers encode offices, which staff are current.
- 4Run a full dry run into a staging environment that is not live.
- 5Review a verification report with per-entity record counts and an exception list.
- 6Go live, with a delta import covering everything entered since the dry run.
Steps three and five are where your time goes, and they are the steps worth spending it on. Extraction is mechanical; interpretation is not.
What changes afterwards
The practical differences that offices notice first are rarely the headline features:
| Before | After |
|---|---|
| One machine holds the database | Hosted, backed up as a property of the system |
| Remote access via workarounds | Open a browser from anywhere |
| A second office duplicates everything | Offices as a first-class concept, with their own letterheads |
| Backups somebody remembers to run | Backups and recovery handled for you |
| One person can change the system | Changes are a support request, not an archaeology project |
| Documents assembled by hand | Generated from the file, in bulk where it helps |
What to do if you are not ready to move yet
Moving is a decision with timing, and there are legitimate reasons to wait. If you are staying on Access for now, three things are worth doing regardless:
- Test a restore. Actually restore a backup to a separate machine and open it. Do this this month.
- Keep an off-site copy. A backup that lives in the same building as the original is protecting you against fewer scenarios than you think.
- Write down what your fields mean. The knowledge currently in one person’s head is an asset, and it is the thing that makes a future migration straightforward.
That third one pays off whether you move next year or in five years, and whoever eventually does the migration will thank you for it.
Common questions
- Can we get our data out of an Access database without the original application?
- Yes. An .mdb file is a relational database whose tables can be read and exported with standard tooling, without the application running and without a licence. Extraction is mechanical. The work in a migration is interpreting what the fields mean in your particular office.
- How risky is an Access database really?
- The main risks are concentration and recoverability: the live database usually sits on one machine, and file corruption is a known failure mode when several people use it across a network. Neither is certain to cause a problem, but both mean your recovery position is entirely determined by how good and how recently tested your backups are.
- Do we have to stop working while we migrate?
- No. The migration runs against a copy, so the office keeps operating normally. Only the final cutover needs a defined switch-over point, and a delta import covers anything entered between the dry run and go-live.
- Should we keep the old system after moving?
- Yes, for a while. Keep it available and read-only for a few months rather than uninstalling it on go-live day. It costs nothing and it is the simplest way to settle any question about what a record looked like before the move.
Keep reading
Migrating from HTA Pro: what an Ontario paralegal office should expect
What actually happens when a paralegal office moves off HTA Pro: how the data comes out, what a dry run proves, and the questions to ask before you commit.
Read the guideChoosing an HTA Pro alternative: an evaluation guide for Ontario paralegals
A practical checklist for comparing HTA Pro alternatives, from provincial offence data models and trust accounting to migration support and your exit plan.
Read the guide