Migrating from HTA Pro: what an Ontario paralegal office should expect

HTA Pro has run a large share of Ontario traffic and paralegal offices for years, and for good reason: it understood provincial offence work at a time when nothing else did. But it is an MS Access application, and the constraints that come with that get harder to live with every year. One machine holds the real database. Remote access is awkward. Backups are somebody’s job rather than a property of the system. Adding a second office means duplicating something.

If your office is thinking about moving, the question is almost never whether the new system has the features. It is whether twenty years of client history will survive the trip. This guide is about that question specifically.

What is actually inside your HTA Pro database?

HTA Pro stores everything in an Access database file, usually with an .mdb extension. That file is a real relational database with tables, and those tables can be read and exported without HTA Pro’s cooperation. In practice a paralegal office’s database contains:

• Client records, often with several addresses and phone numbers accumulated over the years
• Tickets and offence matters, each tied to a client and an offence notice number
• Court dates and appearance history, including adjournments and outcomes
• Disclosure requests and what came back from the Crown
• Trust transactions, general receipts, payments and refunds
• Bank reconciliations, sometimes going back a decade
• Invoices, fee entries and outstanding balances
• Staff records, office details and your file-numbering scheme
• Generated documents and letters, or at least references to where they were saved

The accounting tables are the ones that matter most and get overlooked most often. Trust history is not optional record-keeping, and a migration that brings across clients and cases but leaves trust ledgers behind has not actually moved your practice.

How the data comes out

You do not need HTA Pro running, and you do not need a vendor’s permission. An .mdb file can be read directly with standard tooling and exported table by table. That is the first step of any competent migration: take a copy of the file, export every table, and look at what is really there rather than what the documentation claims.

The important word is copy. Your office keeps working on the live system throughout. Nothing about the migration process should require you to stop taking calls or opening files.

Mapping is where firms differ from each other

Every office that has used HTA Pro for more than a couple of years has bent it to fit their practice. Fields get repurposed. A notes column becomes a status tracker. A prefix on the file number quietly encodes which office owns the matter. One firm’s "type" field means something completely different from another firm’s.

This is why a generic importer does not work, and why you should be sceptical of any vendor offering a one-click conversion. The mapping step is where someone sits with your data, works out what your conventions actually mean, and writes that down as rules:

• Which of your lookup values map to which case types
• How your file-number prefixes and postfixes identify offices
• Which staff records are still active and which are historical
• How your trust and general accounts separate
• What to do with records that are incomplete or contradictory

The dry run is the part that matters

A dry run is a complete import of your data into a private staging environment that is not your live system. Everything goes in: clients, cases, court history, documents, trust transactions, payments, reconciliations. Then you look at it.

This is the single most useful thing you can insist on, because it converts promises into evidence. You can open your five busiest clients and check their trust balances against what HTA Pro shows. You can pull up a matter you remember being complicated and see whether the court history survived intact.

What a verification report should contain

After the dry run you should receive something you can actually check, not a reassuring email. A useful verification report includes:

That last row is the one that separates a real report from a marketing document. Every migration has exceptions. A vendor who tells you there were none either did not look or is not telling you.

Traceability after go-live

Six months after the migration, someone will ask a question that can only be answered by looking at the old system. A client will dispute a payment from years ago, or an audit will ask about a trust transaction from before the move.

This is why every migrated record should keep its original identifier from the legacy database. With that link in place, any client, case or transaction in the new system can be traced directly back to its source row. Without it, your old database becomes an archive you have to search by hand.

Planning the switch itself

The technical migration is usually the easy part. The scheduling is what causes stress. A few things worth planning:

1. 1Pick a quiet week. Never go live the day before a heavy court date, and never at month end while you are reconciling.
2. 2Do a final delta import. Between the dry run and go-live your office keeps working, so the last few weeks of data need to come across too.
3. 3Keep the old system readable. Do not uninstall HTA Pro on go-live day. Leave it available, read-only, for a few months.
4. 4Train before, not after. Your team should have seen the new system during the dry run, using their own real files rather than demo data.
5. 5Nominate one person to own the checklist. Migrations drift when everybody assumes somebody else is checking the trust balances.

Questions worth asking any vendor

• Will you do a dry run before go-live, and can we review it ourselves?
• Does the migration include trust history and bank reconciliations, or only clients and cases?
• What does your verification report show, and can we see a sample?
• Do migrated records keep a reference to their original identifiers?
• Who runs the migration, and what do we have to do ourselves?
• What happens to records that cannot be imported cleanly?
• If we ever leave, how do we get our data out?

That last question tells you a great deal about a vendor. A system confident in its own value will answer it plainly.