Two merging firms, two docketing systems, one combined docket that cannot miss a date. See what breaks and what to decide before the build starts.
The press release goes out. The next morning, two docketing teams are still clearing two dockets, in two systems, with two sets of rules about what an office action is called and who it goes to. The combined firm has one name on the letterhead. It does not have one operation.
Nobody misses that the finance systems have to merge. The DMS migration gets a committee. But the IP docket, the one place where a missed date can turn into a malpractice claim, usually gets a line item in the integration plan that says "consolidate docketing" and not much else. If you're the one who inherits that line item, you already know how much is hiding under it.
We've spent years inside firm combinations, group acquisitions, and lateral team moves, doing the operational work behind that line item. This paper is what we've learned. Not the announcement version. The version where someone has to decide what "Response to Non-Final Office Action" is called now, and every workflow rule in the building depends on the answer.
One note before we start. The examples in this paper are composites, drawn from multiple unrelated engagements across many years, with figures rounded to ranges and details deliberately blended. No example describes a single firm or a single combination, and no set of details here should be read together as one engagement.
Why is merging IP operations harder than it looks?
Here's the assumption that sinks integration plans: if both firms run the same docketing system, the docketing part is done. Same software, same operation. Merge the user lists and move on.
We've analyzed combinations where both firms had run the same docketing system for years. They were still two completely different operations. And the contrasts repeat across engagements. One side runs intake in parallel: a document arrives and several things happen at once, indexing, central docketing review, quality review, distribution to the case team. The other runs a serial chain, each document walking from step to step, one reviewer at a time, straight to matter personnel. One side routes work through a rules engine with dozens of active distribution rules. The other doesn't use a rules engine at all.
One side has a dedicated quality-review step baked into intake. The other has none. Reviewers check their own work.
Same platform. Two operations that agree on almost nothing about how a document moves from the mailbox to the matter.
Configuration is where operations actually live. The software tells you what's possible. The configuration tells you what the firm actually does, and after years of client-specific rules, workarounds, and process decisions made by people who've since retired, no two configurations look alike. "We're on the same system" is the beginning of the analysis, not the end of it.
Where do combined dockets actually break?
Not where people expect. The org chart questions get attention because they're visible. The failures that matter hide in the data, and they fail silently.
The two firms don't speak the same language. We've put two firms' activity tables side by side and found thousands of distinct names on each, with fewer than one in twenty matching exactly. And these weren't different events. They were the same events with different names: one firm's "Annuity" is the other's "Annuity Payment Due." Same deadline, same underlying payment, two vocabularies.
That sounds cosmetic. It isn't. Every workflow rule, every report, every reminder keyed on an activity name matches one firm's records and silently misses the other's. The report runs. It looks complete. It's missing half the practice.
Fields with the same name pull from different places. Compare the data caches of two implementations and you find dozens of fields that share a name. Application number. Deadline date. Status. Then you trace them back and find that nearly all of them pull from different underlying source fields. One firm mapped fields directly from the docketing data. The other derived them through views and procedures. Same label, different contents.
One side's deadline model depends on a key the other side never had. This is the sharpest version of the problem we've seen. One firm's docket anchored every reminder to an explicit final-deadline key in its docketing data. The other firm's data simply didn't contain that key. There was a proxy field, close but not the same thing. Which means the relationship between a reminder and its final deadline couldn't be computed the same way for both firms' records. Left unreconciled, that gap would quietly group deadlines wrong across a large share of a combined docket that runs to millions of records.
Matter numbers carry the firm's history. Numbering schemes encode client, family, and filing-type logic, and no two firms encode it alike. Legacy numbers survive from acquisitions one or two firm-generations back. Some clients arrive with two or three numbering systems of their own. And the finance system has opinions about all of it. Renumbering everything mid-combination is rarely realistic, so the real question becomes which numbers the combined systems treat as canonical, and how the legacy numbers survive as searchable aliases everywhere they already live.
The practice mix won't match. One side's filings concentrate exactly where the other side barely practices: different blends of prosecution and renewals, domestic and foreign, high-volume docket work and specialist matters. Routing and rules built for one mix run thin exactly where the other side's volume is heaviest. Default to either firm's configuration without checking and part of the combined practice inherits an operation that was never designed to carry it.
Configuration debt migrates. Routes named "disabled" that are still active-flagged. Templates retired years ago but never removed. One-off logic embedded where nobody remembers putting it. Nobody audited any of this because it mostly worked. Merge it as-is and the ambiguity comes along, except now there's no one left who knows which half of it was intentional.
None of these show up on an org chart. All of them show up in the docket, months later, as a deadline grouped wrong or a report that quietly missed a practice group. These are data problems. They don't announce themselves.
What should you decide before anyone configures anything?
The method we've settled on, across every combination we've supported, has a rule at its center: no production build until the decisions are made, and no decisions until both operations are actually understood. Prototypes, data profiling, and discovery work are fine. Building the real thing isn't.
Assess each side independently first. Same agenda, run separately for each group. Leadership on strategy and what they want the combination to achieve. The docketing manager. The paralegal manager. Records and intake. Staff roundtables where the people doing the work describe how it actually flows, which is reliably different from how the process documentation says it flows. Then a cross-functional walk-through of one day's information: mail arrives, gets sorted, gets docketed, gets to the right desk, gets to the client.
Read the configuration, not just the interviews. Pull the workflow definitions, the field mappings, the activity taxonomies from each environment and put them side by side. Intake model. Routing. Review and QC. Naming. Deadline data model. The interviews tell you what people believe the operation does. The configuration tells you what the systems are actually set up to do. Neither is the full story on its own, and the gap between them is usually where the risk is.
Then build a conflict register. Every structural difference between the two operations becomes an explicit decision: what must be decided, our recommended answer, and who owns the call. Not a wish list. A register, worked through with both firms' leadership before build starts. From real engagements, the register looks like this:
| Decision | The question |
| Routing model | Rules engine or direct routing, and whose becomes the standard |
| Docketing review | Central review then distribute, or straight to the case team |
| Quality review | One firm has a QC step, the other doesn't. Firm-wide, or dropped? |
| Activity vocabulary | Define the canonical names. Build the crosswalk for every legacy name. Keep it permanently. |
| Role vocabulary | You can't write a routing rule that says "send it to the attorney" until both firms mean the same thing by "the attorney" |
| Field mappings | Field-by-field adjudication, with docketing staff in the room, before the caches combine |
| Deadline model | Reconcile the deadline keys, or run two models with honest labels |
| Document naming | One template. Consider search and duplicate detection before choosing. |
You don't need us to build this register. Put the two configurations side by side and the rows fill in fast. The hard part is getting each decision made, with a named owner, before someone starts configuring.
Two things about that register. First, the recommendations are starting positions. The working session is where they get pressure-tested by the people who'll live with them. Second, the point we keep coming back to on every engagement: these are data decisions, not configuration tasks. Deciding the canonical activity vocabulary isn't an IT setting. It gates every workflow rule, every report, and every reminder the combined firm will ever run.
One more thing the register protects you from. The default in most combinations is that one firm's setup becomes the standard by momentum, not by analysis. The architecture decision should be made on fit. More than once, the analysis has pointed somewhere other than the default, with the other side's routing logic rebuilt and tested rule by rule inside the chosen architecture, not lifted. The instinct to just absorb one operation into the other usually doesn't survive contact with the analysis. And if the combination has leadership weighing a full system swap instead, that's a different decision with its own math. We covered the real cost of switching docketing systems separately.
What does the team actually need on day one?
Ask leadership at any combining firm what they need from operations and you'll hear the same two sentences. Make it smooth, because attorneys have no spare time during a combination. And make sure we can work and bill on day one.
Day one is a lower bar than the end-state. Most integration plans miss that. You don't need the combined operation finished at close. You need both sides able to clear the docket, file, and bill without interruption while the real convergence work happens in phases behind it. Firms tell us plainly they'll trade bells and whistles for a simple, safe transition. They're right.
A few people realities deserve more respect than integration plans give them.
Quality control asymmetry is a workload question, not a checkbox. Extending one firm's QC step across the combined operation means new work for people who never had it. Phase it, train it, and say so out loud. Dropping it instead means removing a control from the side that's relied on it for years. Either way it's a decision about people's days, not a configuration toggle.
The docketing staffing model is a real fork. Central docketing review that distributes to case teams and direct-to-case-team routing produce different team structures, different skill demands, different failure modes. The combination forces the choice. Better to make it deliberately than inherit it from whichever configuration got merged last.
And the invisible plumbing needs an inventory. Custom docketing rules. Shared-inbox forwarding and copy rules. The routing logic that lives in one person's mailbox settings. None of it migrates by itself, and all of it fails quietly. In every assessment we run, the walk-through surfaces rules that nobody in the room knew existed.
Clients, for their part, care less about which systems the combined firm runs than about what those systems owe them. The team they trust still on their matters. Reporting in the format their outside-counsel guidelines require. The portal still working, the billing codes still right. Meet all of that and the operational bar is continuity of service, not visible transformation.
And the docket work sits inside a longer integration list this paper doesn't cover in depth. Cutover and parallel-run controls. Verification testing on the active docket before anyone certifies it. Correspondence addresses and powers of attorney, which carry their own transition work at the patent and trademark offices. Access controls and ethical walls for the combined user population. Each client's specific requirements. None of it is optional. The conflict register just has to come first, because most of that list depends on its answers.
What we've learned across combinations
Keep the crosswalks forever. The activity-name crosswalk, the role mapping, the numbering translation. These aren't migration scaffolding to throw away when the project closes. Historical records speak the old language permanently, and the first time someone runs a ten-year prosecution history report, the crosswalk is the only thing standing between them and a silently wrong answer.
Write down what you decided not to carry forward. Six months in, someone will ask where a workflow went. "We retired it deliberately, here's why" is a very different conversation from an archaeology dig through old configuration.
The silent failure is the one that gets you. A broken workflow announces itself. A report that runs clean while missing half the combined practice does not. That's why the register's worst-severity items are always the data-model ones, and why they get decided first.
Assessment before design. Design before build. Every time. The pressure in a combination is always to start configuring, because configuring looks like progress. Resist it. The combined-system problems we've been called in to fix trace back, again and again, to a decision that got made implicitly by whoever configured first.
Where we fit
This is work we do. Quartz IP has supported firm combinations, inbound group acquisitions, and IP team transitions for years: independent assessments of each operation, the comparison, the conflict register, and the roadmap the combined leadership actually signs off on. The firms involved keep their docketing systems. The work is making two operations into one while both dockets keep getting cleared.
If your firm is heading into a combination, the best time to look at the two operations is before the integration plan hardens. Talk to us early. LearnMore@quartzip.com.
Related reading: Should You Switch Docketing Systems? · When Your Docketing System Gets Acquired · What Is IP Operations?
---
Frequently asked questions
Both firms use the same docketing system. Doesn't that make the merger easy?
No. The software is the same. The operations aren't. Intake models, routing, review steps, naming, and data mappings diverge over years of configuration. In side-by-side comparisons we've run, activity-name overlap has been as low as one exact match in twenty, on the same system.
What breaks first when two IP dockets combine?
Usually nothing visible, and that's the problem. The early failures are silent: reports and workflow rules keyed on one firm's activity names that miss the other firm's matters, and deadline groupings computed differently for each firm's records. A report that runs clean while missing half the practice is the failure mode to plan for.
What should be decided before configuration work starts?
The canonical activity vocabulary and its crosswalk, the routing and review model, the QC standard, the role vocabulary, field-by-field data mappings, the deadline data model, and document naming. Each needs an owner and an explicit decision. They're data decisions, and they gate everything built afterward.
Does the larger firm's configuration become the standard?
It shouldn't by default. The combined operation should be built on the architecture that fits best, and the assessment decides which that is. It isn't always the presumptive one. Routing logic from the other side gets rebuilt in the chosen architecture rather than carried as-is.
What does the IP team need on the day the merger closes?
The ability to work and bill without interruption. Both sides keep clearing their dockets while convergence happens in phases. Day-one continuity comes first. The combined end-state comes after, in the order the conflict register sets.