HotDocs migration plan: a practical, low-risk sequence

Most HotDocs conversions do not go wrong at the point of conversion. They go wrong about three weeks in, when somebody opens the template library properly for the first time in years and finds dormant templates, three versions of the same document, workarounds nobody can explain and drafting that no longer reflects the firm’s position. The instinct at that moment is to stop and fix it. It is the right instinct and the wrong moment, and it is the single most common reason a conversion that should take weeks takes three quarters. A good HotDocs migration plan separates the two pieces of work and sequences them deliberately. This piece sets out that sequence, step by step, with what to check at each stage before moving on.

Why the sequence matters more than the tooling

A conversion is two distinct jobs. The first is mechanical: translating templates from one system to another so they behave the same way. Software does this well, it is bounded, and it is testable — you regenerate an old document with the same data and compare. The second is a design exercise: rationalising the library, restructuring interviews, moving repeated language into governed clause management, connecting to your document and practice systems. That work is valuable, unpredictable per template, and gated by partner time rather than authoring capacity.

Conflating them is what creates risk, because the two have completely different shapes. Leaving the old platform is time-bound and has an end. Reviewing a precedent library is not time-bound and, done properly, never really ends. Attach the second to the first and the first inherits an open-ended scope.

Worth saying plainly: HotDocs Classic is a capable product with a long history, and firms that built substantial libraries on it made a reasonable decision at the time. Since Mitratech acquired HotDocs from CARET in June 2024, a number of firms have taken the ownership change as a natural moment to review their options. That is a review, not an emergency, and the plan below assumes you have time to do this properly.

💡 Insight

It is worth writing down, before anything starts, which of the two jobs each stage belongs to. Firms often find that the arguments during a conversion are not really disagreements about the plan — they are two people talking about different projects and assuming they are discussing the same one.

Step one: audit the library before you convert anything

The audit answers one question: what is actually in use? Pull a usage report from HotDocs covering at least the last twelve months, and put three columns next to every template — how often it was run, who ran it, and when its content was last changed.

That is usually uncomfortable reading. Most libraries that have been running for years contain templates nobody has used in a year, near-duplicates that diverged when two people needed slightly different things, and content that has quietly fallen out of date. The Legal Practitioners’ Liability Committee makes the risk case for reviewing precedents on a regular cycle in its guidance on what makes a good precedent, and out-of-date precedent is a recognised claims pattern rather than a tidiness issue.

Then sort every template into three buckets. Convert as-is: in regular use, content still correct, interview tolerable. Convert then tidy: in use, but with known irritations worth fixing after the move. Redesign: either heavily used and structurally poor, or dormant enough that it should be retired rather than carried across. Sort on four things — how often it runs, what happens if it is wrong, how quickly its content changes, and whether the drafting still reflects what the firm would say today.

Do not skip the retirement decision. Every template you decide not to carry across is work you do not do, twice — once in conversion and again in every future review.

Step two: convert one representative suite, not one simple template

The temptation is to prove the concept on something easy. That proves very little. Choose a suite that is representative of your library’s real character — ideally one that includes a repeating schedule, some conditional logic of the kind your authors actually write, and a document that shares data with another.

The free HotDocs Classic Converter converts basic and moderately complex templates on the fly; more sophisticated suites go to an implementation partner. The point of doing a representative suite first is to find out which of those two categories your library mostly falls into, before you have committed a schedule to anyone.

Two things usually determine how smoothly this goes, and neither is template count. The first is how consistently your variables and components were named — a library built to a convention converts far more predictably than one built by six people over eight years. The second is how much logic lives in scripting rather than in structure. Both are worth checking during the audit, because both are knowable in advance.

💡 Insight

Effort on a conversion scales with template complexity and naming consistency rather than with the number of templates. Firms often find a library of four hundred consistent templates converts more smoothly than one of eighty inconsistent ones. It is worth resisting any estimate expressed purely as a per-template figure.

Step three: verify by comparing output, not by reading templates

This is the step most often shortened, and it is the one that makes everything after it safe. The test is specific: take a set of real answer data, generate the document in HotDocs, generate it in XpressDox, and compare the two outputs.

Compare the document, not the template. A converted template can look different and be correct; what matters is whether the produced document is the same. Build a small set of test cases per template that deliberately exercises the branches — the optional clause in and out, the schedule with one row and with twenty, the jurisdiction that changes three paragraphs. Five test cases that hit the conditions are worth more than fifty that all take the same path.

Record the results. A short comparison log per suite gives you something to show a nervous partner, and it becomes the evidence base for signing off the rest of the library. It is also what turns “we think it works” into a defensible position if anyone asks later.

Step four: convert the rest like for like — and hold the line

With one suite verified, convert the remainder to match the original behaviour. Not improved. Matching.

This is where the plan is tested, because by now people have seen the audit and have opinions. The discipline is to keep a running list — call it the modernisation backlog — and put every good idea on it rather than into the current work. Nothing is refused; everything is scheduled. That single device does more to keep a conversion on time than any amount of project governance, because it lets you say yes and later in the same sentence.

One exception is worth making. If the audit found content that is actually wrong — a superseded statutory reference, a clause the firm no longer stands behind — fix it now. Carrying a known error across because of a process rule is not a plan, it is a formality.

Step five: run both systems in parallel for a defined period

Keep HotDocs available and read-only alongside the new templates for a fixed window — a matter of weeks rather than months, with a stated end date. Parallel running is what lets a firm move without a single high-stakes cut-over, and it answers the objection that stops most conversions before they start: we cannot afford for this to go wrong.

Two rules make it work. Set the end date at the beginning, because a parallel period without one becomes permanent and you end up maintaining two libraries. And make the new system the default for new matters from day one, with the old one available for reference, rather than leaving the choice open — given a free choice under time pressure, people use what they know.

Pilot with one practice group rather than the whole firm. A group that produces documents daily will find the problems inside a fortnight, and a fortnight of concentrated use is a better test than a month of occasional use across five teams.

Step six: modernise in waves, by practice group

Now the backlog. Take it a practice group at a time, in waves, and let each wave finish before starting the next. Working by practice group means you are asking one set of partners about documents they own, which is the only way to get drafting decisions made at a reasonable pace.

The work in each wave tends to be the same four things: restructuring interviews so they ask fewer and better questions, moving repeated language out of individual templates and into governed Intelligent Clause Management so a single approved position feeds every template that uses it, connecting templates to your document and practice systems so matter data populates automatically, and rebuilding the handful of templates the audit marked as redesign.

This is also the point at which the firm gets the benefit it was hoping for when it started. A like-for-like conversion buys you a modern platform with the same documents. Modernisation is what makes the documents better. Keeping them separate is what makes both achievable.

Common mistakes in a HotDocs migration plan

Five patterns account for most conversions that overrun.

1. Starting the library review mid-conversion. The review is necessary and it is not urgent. Audit before, backlog during, modernise after — in that order.
2. Piloting on an easy template. An easy template tells you the converter works, which was not in doubt. A representative suite tells you what your library is going to cost.
3. Verifying by reading rather than generating. Templates can look wrong and produce correct documents. Compare the output, with test data that exercises the conditions.
4. Converting everything because it exists. Dormant templates are the cheapest thing to remove and the most expensive thing to carry. Decide what is being retired before conversion, not after.
5. Leaving the parallel period open-ended. Without a stated end date, two libraries are maintained indefinitely and the firm gets the cost of both systems and the benefit of neither.

💡 Insight

It is worth agreeing at the outset who can add to the modernisation backlog and who decides when a wave is finished. Firms often find that the backlog is what keeps the conversion honest — but only when someone owns it, otherwise it becomes a list nobody revisits and the good ideas leak back into the current work.

Our view: the schedule risk is scope, not technology

After fifteen years of doing this work with firms in more than 25 countries, our position is that a HotDocs migration plan rarely fails technically. It slips because the scope grew, and the scope grew for a good reason — somebody looked at the library properly and did not like what they saw.

So the discipline we would argue for is not “convert first, ask questions later”. It is the opposite: ask the questions first, in the audit, write the answers down, and then refuse to act on them until the mechanical job is finished. The audit is what makes it safe to hold the line, because nobody has to worry that a problem will be forgotten.

We would also encourage firms to measure their own library rather than trusting anyone’s averages, including ours. How much of a library is dormant, how much converts cleanly and how much needs redesign varies enormously by firm, practice mix and how the templates were built. Your usage report will tell you more in an afternoon than any benchmark will.

Where to start

The first step costs nothing and can be done this week: pull twelve months of usage data from HotDocs and sort the library into the three buckets. Most firms find that conversation changes the shape of the HotDocs migration plan before any software is involved, usually by making it smaller.

If it would help to talk through what your audit is showing, or to run a representative suite through the converter and see what comes back, our team works on exactly this with firms leaving HotDocs Classic. You can book a demo or write to us at support@xpressdox.com.

Frequently asked questions

How long does a HotDocs Classic conversion take?

It depends far more on template complexity and naming consistency than on how many templates you have. A library built to a convention converts predictably; one built by several people over many years takes longer per template regardless of count. The reliable way to find out is to convert one representative suite early — including a repeating schedule and real conditional logic — and use that as your estimating basis.

What should be in a HotDocs migration plan?

Six stages in order: audit the library using twelve months of usage data, convert one representative suite, verify by comparing generated output against the original, convert the remainder like for like, run both systems in parallel for a defined period with a pilot group, then modernise in waves by practice group. The plan’s main job is keeping the mechanical conversion separate from the library redesign.

Does the free converter handle everything?

It converts basic and moderately complex HotDocs templates on the fly. More sophisticated suites go to experienced implementation partners for conversion services. Running a representative suite early is how you find out which category your library mostly sits in before committing to a timeline.

Should we improve our templates while we convert them?

We would suggest not. Improvement is valuable but open-ended, while leaving the old platform is time-bound, so attaching the first to the second gives the whole project an open-ended scope. Capture every improvement in a modernisation backlog during the conversion and work through it in waves afterwards. The exception is content that is actually wrong — a superseded reference or a position the firm no longer stands behind — which should be fixed rather than carried across.

How do we know the converted templates are correct?

Compare generated documents rather than templates. Take real answer data, produce the document in both systems and check the output, using test cases that deliberately exercise the branches — optional clauses in and out, schedules with one row and with many, jurisdiction switches. Keep a short comparison log per suite; it is what lets you sign off the rest of the library with confidence.