Law Firm Merger Integration: The Operational Checklist

Most law firm mergers are negotiated as a financial event and executed as an operational one, and the gap between those two things is where they fall apart. The letter of intent talks about combined revenue, complementary practice areas, a shared brand, and a partner compensation structure everyone can live with. Almost none of that language addresses the four things that will consume the first six months of the combined firm's life: reconciling two client rosters that were never built to the same standard, running conflicts across a book neither side has ever seen in full, merging two sets of trust ledgers without commingling a single dollar, and getting two groups of people who each think their old way was better to work off one system.

The uncomfortable truth about merger integration is that the technical work and the cultural work are the same work. When you tell the smaller firm's paralegals that their matter numbering scheme is being retired, you are not making a database decision, you are telling six people that the way they have organised their working life for eleven years is now wrong. When you consolidate onto one platform and the other side's partners quietly keep using their old system for three months because nobody forced the issue, you do not have a merged firm, you have two firms sharing a letterhead and a bank account. That situation is not stable and it is not safe.

This is the operational checklist, written in the order the work actually has to happen rather than the order it appears on a deal timeline. It assumes you have already agreed the commercial terms and are now facing the far less glamorous question of how two functioning practices become one without dropping a deadline, breaching a trust account rule, or losing a client who never quite understood what was happening to their file.

What a merger actually does to your conflicts surface

Two firms of comparable size do not produce twice the conflicts exposure when they combine, they produce something considerably worse, because every party in one firm's history now has to be tested against every party in the other's. A firm with a decade of files has thousands of named entities in it once you count opposing parties, co-defendants, witnesses, guarantors, expert witnesses, corporate affiliates, and former clients whose matters closed years ago. The combined firm's exposure is the product of those two sets, not the sum, and that is why a merger conflicts exercise takes weeks rather than an afternoon and why running it late is the single most expensive sequencing mistake available to you.

What makes this genuinely hard is that neither firm's data was collected with the other firm's data in mind. One side may have recorded corporate clients by trading name, the other by registered entity name. One may have logged an opposing party as a single line of free text, the other as a structured contact with a role attached. Until both datasets describe parties the same way, a conflict search across them produces confident silence rather than a real answer, and confident silence is far more dangerous than a messy list of possible hits. The normalisation work is unglamorous, it is usually done by the two firms' most experienced administrators sitting together for a week, and skipping it does not save time, it moves the discovery of the problem to a point where it costs a client.

Building one client roster before you build anything else

Start by freezing both rosters at a fixed date and reconciling them as a standalone exercise, entirely separate from any system migration. You are looking for four categories: clients unique to firm A, clients unique to firm B, clients both firms genuinely share, and the ones that look shared but are not, the near duplicates where two different entities carry similar names or where a parent and a subsidiary have been treated as one relationship by one side and two by the other. That last category is where the real errors live, and it is the reason automated deduplication on name similarity alone should never be trusted to make the final call.

The shared clients deserve particular attention because they carry a commercial question as well as an operational one. If both firms have acted for the same company in different practice areas, the combined firm now holds a much larger share of that client's legal spend than either side did, and the relationship partner question has to be settled before anyone sends an invoice under the new name. If both firms have acted for entities on opposite sides of the same transaction or dispute, you have found the merger's first real problem and you have found it at the right time. Record every one of these determinations against the client record itself, with the reasoning stated, because in eighteen months nobody will remember why a particular call was made and somebody will need to.

Running the combined conflict check across both histories

Once the rosters are normalised, the combined conflict check has to search the full contact and matter history of both firms, not the active matter lists. This point gets nodded at and then ignored constantly. A conflict does not stop existing when a matter closes, and a merger is precisely the moment when a closed file from six years ago becomes relevant again because the other firm is currently acting against that former client. Any conflict tool that only indexes open matters will pass a merger check cleanly and leave you exposed, and you will not find out until a disqualification motion lands.

The search also has to be role aware. A party who appeared as a witness on one of firm A's matters and appears as an adverse principal on one of firm B's current files is a hit, and a system that only records the client and the opposing party will never surface it. This is why conflict checking that searches every role a party has played, across closed matters included, is not a nice feature in a merger, it is the whole exercise. Casely's conflict checking is built to search the full contact and matter history rather than a filtered slice of it, and contact labels carry the role and referral source with the party record, which is exactly the structure the combined check depends on. Run the check in both directions, document the run itself with a date and a scope, and keep that documentation, because the record of having run a proper check is nearly as important as the result.

What you actually do when a hit lands

A hit is not automatically a disaster and it is not automatically a declination. The realistic outcomes are that the combined firm declines or withdraws from one of the matters, that the affected clients give informed consent to the conflict continuing under a properly documented arrangement, or that the matter proceeds behind an ethical wall where the relevant regulator permits screening and the client is informed. Which of those is available to you varies materially by jurisdiction. Screening rules, imputation rules, and the circumstances under which consent can cure a conflict differ between US states, between the position in England and Wales and the position in Canadian provinces, and again in Australian jurisdictions. Do not assume the rule you learned in one place travels. Confirm with your own regulator before you build the plan around it.

Where a wall is the answer, it has to be a real one from the first day of the combined firm's existence, and this is where most integrations quietly fail. A wall that is a policy document plus a hidden menu item is not a wall, it is an intention. The test is whether a walled attorney can reach the restricted matter by any route at all, including the global search bar, a shared calendar entry, a document link a well meaning colleague forwards, or an internal report that lists matters they should not see. Casely enforces ethical walls at the server and data access layer rather than in the interface, so a walled user genuinely cannot reach a restricted matter through any of those paths. In the first weeks after a merger, when hundreds of people are moving fast and sharing things without thinking hard about who is on the other end, that distinction is doing real work.

Merging trust ledgers without commingling a single dollar

Here is the part where the language matters. You do not merge two trust ledgers. You migrate two sets of per matter client balances into one system while keeping every single one of them isolated, and the underlying bank accounts move on a separate track governed by whatever your regulator requires. Client money belonging to firm A's clients cannot be pooled with client money belonging to firm B's clients into an undifferentiated balance while somebody sorts out the paperwork, and it cannot pass through the combined firm's operating account on the way. The specific mechanics of moving client funds between accounts on a merger are prescribed differently across jurisdictions, and the account itself carries different names and different rules depending on where you practise, so this is a step you plan with your regulator's guidance in front of you rather than from memory.

Operationally, the discipline is that every matter's balance moves as its own line with its own documented history: the exact amount, the source of the funds, the date it was received, and what has been disbursed against it. A balance that arrives in the combined system as a single opening figure with no history behind it is a balance you cannot defend if it is ever questioned, and trust discrepancies are treated as among the most serious categories of misconduct by essentially every regulator in every common law market. Casely holds per matter isolated ledgers rather than one pooled figure, and it blocks any disbursement that exceeds a matter's actual trust balance at the database transaction level, not through a warning dialog someone can click past. During a merger, when unfamiliar files are moving through unfamiliar hands at speed, a structural block is worth considerably more than a prompt.

The reconciliation that has to clear before go live

Both firms should run a full reconciliation of every client balance immediately before the migration and again immediately after, and the two sets of figures have to agree to the cent before anyone declares the integration complete. This sounds obvious and it is skipped constantly, usually because the migration weekend runs long and everyone wants to open on Monday. Opening on Monday with an unreconciled trust position is how a firm ends up eighteen months later trying to reconstruct which side's records were right about a balance that has since been partially disbursed to a client who has now sued.

The other half of this is what happens when the two sets of figures do not agree, which they often will not, because the two firms almost certainly booked interest, bank charges, or small residual balances differently. Corrections at this stage must be recorded as corrections and remain visible, never quietly overwritten to make the numbers line up. Casely voids corrections rather than deleting them so the entry stays on the ledger with its history intact, which means the record shows what was originally recorded, what it was changed to, and when. If a regulator or a client ever asks what happened to a particular balance during the merger, the honest answer with a full audit trail behind it is the only answer worth having. Firms that tidy their ledgers to make a migration look clean are creating a problem they will meet again later under much worse conditions.

Systems consolidation, one platform on one dated cutover

The decision that most determines whether an integration succeeds is whether you pick one system and set a hard date, or allow both to run in parallel while people transition at their own pace. Parallel running feels humane and is operationally corrosive. Two systems means two versions of a client's contact details, two places a deadline might have been entered, two document repositories where the current draft could be sitting, and an unanswerable question every time somebody asks where the authoritative record is. It also means your conflict checking is running against half the firm, which quietly undoes the entire exercise you just spent six weeks completing.

Choosing which system survives should be decided on capability and on the combined firm's needs, not on which side is larger or which partner shouts loudest. In practice a merger is often the right moment to move both firms onto something neither was using, because a genuinely neutral platform removes the losing side problem entirely and nobody spends the next year describing the change as a takeover. Cloud native matters here too, since there is no local install to roll out across two offices with different hardware, different IT arrangements, and probably different opinions about who owns the laptops. Whatever you choose, the cutover is a single dated event with a communicated plan, and the old systems go read only on that date rather than staying open for convenience.

The order the data has to move in

Migration order is not arbitrary and getting it wrong creates work that has to be redone rather than errors you can patch. Contacts and parties move first, because matters reference them and a matter imported against an unresolved contact creates a duplicate that then has to be untangled by hand. Matters move second, with practice area, stage, and responsible attorney assigned at import rather than left blank to be fixed later, because blank fields are never fixed later. Documents move third, attached to matters that already exist. Financial records move last and separately, because they need their own reconciliation and their own sign off, and because a financial import that fails halfway through a combined push is far harder to unwind than a standalone one.

Two details are worth building into the plan from the start. Matter numbering across the combined firm needs a single scheme decided in advance, with a documented mapping from each legacy scheme, because people will be looking up old numbers for years and a lookup that fails is a call to a client that starts badly. And every migrated matter should land with its stage set to where the matter actually sits procedurally rather than defaulting to the first step. A configurable stage tracker, set per practice area, is what lets an attorney from the other side of the merger open a file they have never seen and understand its position without ringing someone. That is a small thing that compounds enormously across the first three months.

Rates, work in progress and the invoices that straddle the merger date

Two firms almost never bill the same way. One may be predominantly hourly with a rate card that has drifted upward informally, the other may run flat fees for a large share of its work, and there is usually at least one contingency matter and a handful of blended arrangements sitting in the mix. The combined firm has to decide what happens to unbilled time recorded before the merger date, whether it bills at the old rate or the new one, and how that is explained to the client. My strong view is that pre merger work in progress bills at the rate the client agreed to, at the old rate, and that any rate change applies prospectively with notice. Anything else is a fee dispute you have volunteered for.

The practical consequence is that the combined system has to handle several billing models natively rather than forcing everything into one shape. Hourly, flat fee, contingency, and blended arrangements all need to coexist in the same firm without a workaround, and a firm doing institutional work will need LEDES 1998B export intact from the first billing cycle after the merger, because insurance and corporate clients will not accept a gap while you sort your systems out. Casely handles all four models natively and supports LEDES 1998B export, which matters less as a feature list and more as a constraint on your integration plan: if the surviving system cannot bill the way the other firm bills, you have not chosen a platform, you have chosen a rewrite of half your engagement terms.

Deadlines and calendars, the quietest failure point

Everyone plans for conflicts and trust because the consequences are visible and career ending. Almost nobody plans properly for the calendar, and the calendar is where a merger most often causes actual client harm. Two firms have two sets of court dates, limitation periods, filing deadlines, and internal reminders, kept in two systems with two sets of conventions about who owns a date and how far in advance it prompts. During a cutover, the window where a deadline can fall between the two is measured in days, and a missed limitation date is not recoverable by apology.

The mitigation is boring and it works. Before cutover, both firms produce a complete list of every deadline in the next twelve months from their own system, those lists are merged and manually verified against the underlying matters rather than trusted as exports, and the combined list is entered into the surviving system before the old ones go read only. For the first month after go live, run both the migrated diary and the printed verification list side by side and have one named person check them against each other daily. Deadlines attached to the matter itself, with the next date tracked automatically, are far more survivable through a migration than deadlines living in individual attorneys' personal calendars, which is exactly the arrangement most firms discover they actually have once they start looking.

Documents, permissions and two different filing cultures

Two firms will have two entirely different relationships with their documents. One may have a disciplined naming convention and a version history going back years, the other may have a shared drive organised by whoever created the folder. Merging those is not a matter of copying files into one place, because a document without a record of what it is and why it changed is a document nobody will trust enough to rely on. Every migrated document should carry a comment recording what it is and where it came from, and every document that arrives should land attached to a matter rather than in a general repository that becomes the combined firm's permanent unsorted pile.

Security posture also has to be settled rather than averaged. If one firm encrypted documents at rest and the other did not, the combined standard is the higher one, applied to everything including the migrated history, and it is worth being able to state plainly to institutional clients what that standard is. Casely applies AES-256 encryption to every document with a per firm key, which is the sort of thing a client's procurement team will ask about in the first review after a merger announcement and the sort of thing you want a one sentence answer to. Permissions need the same treatment: decide the combined firm's access model deliberately, apply it at go live, and resist the temptation to grant everyone broad access during the transition on the theory that you will narrow it down once things settle. Things never settle, and the broad grant becomes permanent.

The cultural work that decides whether it holds

Everything above is achievable by competent people with a plan. What determines whether the merged firm is still one firm in two years is whether the people from the smaller or acquired side believe they were integrated rather than absorbed. That belief is not formed in the town hall meeting where the merger is announced. It is formed in a hundred small operational decisions that each look like a technical matter and read to the people affected as a statement about whose way of working counts. Whose matter numbering survives. Whose intake form becomes the standard. Whose stage names get used on the tracker. Whose administrator ends up training the other side.

The practical answer is not to pretend those decisions do not have a cost, but to make them visibly and to distribute them. Let the acquiring firm's system win on some things and the other firm's practice win on others, and say out loud why each call was made. Configure the workflow to match how each practice area actually runs rather than flattening everything to the dominant group's habits, which is precisely why a stage tracker that can be configured per practice area rather than imposed firm wide is worth more culturally than it looks technically. And put the other side's people in visible ownership of parts of the integration, not as a gesture but because they know things about their own book that nobody on your side does. A merger that is run entirely by one side's operations team produces a system that works for one side's operations team.

The first ninety days, and what to actually measure

Declare the integration finished on evidence, not on a date in the plan. The evidence is specific: the combined conflict check has been run in both directions and documented, every client balance reconciles to the cent, every deadline in the next twelve months has been verified against its underlying matter by a human, every attorney is working in one system with no meaningful shadow use of the old ones, and the first full billing cycle under the combined name has gone out and been collected without a spike in disputes. Until all five of those are true, you are still integrating, whatever the timeline says.

Watch two numbers in particular through the first ninety days. Realisation on matters that transferred across, because a drop there usually means time is being recorded loosely by people still uncomfortable in the new system rather than any change in the work. And client responsiveness, meaning how quickly clients are actually getting answers, because the period right after a merger is when clients are most likely to feel forgotten and most likely to quietly start talking to someone else. A privilege filtered client portal that gives clients real time visibility on their own matters, on mobile, with e-signature in the same login and no separate account to create, does a lot of unglamorous work here, because a client who can see their own file progressing is a client who does not need reassuring that the merger has not lost them.

If you take one structural principle from all of this, take the sequencing. Conflicts before files, files before money, money before go live, and one system on one date. The firms that get merger integration wrong almost never get it wrong because the plan was bad. They get it wrong because the deal closed, everyone was tired, and the operational work got compressed into a weekend it could never fit into. Build the plan around tooling that makes the dangerous steps structurally hard to get wrong rather than merely discouraged, starting with conflict checking that searches your full contact and matter history and trust accounting that isolates every matter's balance, and the merger becomes an operational project rather than a risk you carry for two years.