Platform consolidation — choosing the surviving system.

Platform consolidation is where two agencies become one operationally, and the first decision is also the most consequential: which management system survives? Get it right and the migration is a defined project; get it wrong — most often by running both systems indefinitely because no one made the call — and the agency lives in a permanent parallel-operations limbo that drains money and never fully commits the staff to either platform. The choice has a logic, and so does the transition that follows it.

§ 01 · The three scenariosWhich system survives.

There are three migration scenarios. Migrate the acquired agency to the buyer's system is the most common — the buyer's incumbent platform absorbs the seller's data. Migrate to the seller's system is rare and strategic, justified only when the seller's platform is demonstrably superior or the seller's book is materially larger than the buyer's. And the same-system match isn't a migration at all — it's a database merge, the lowest-cost integration there is, which is why a target already running the buyer's platform can justify a higher acquisition premium when you're evaluating deals. The decision rule for the reverse case is concrete: the reverse-migration rule of thumb says that when the acquired book is roughly 4× the buyer's operation (a $500K buyer acquiring a $2M seller), the math favors migrating onto the seller's platform — because moving the smaller book is cheaper and less risky than moving the larger one. Name the scenario first; everything downstream depends on it. The operational-pillar overview of this migration is in tech-stack integration.

§ 02 · The parallel-operations window3–6 months, not indefinite.

Running both systems is necessary for a while and dangerous for long. The parallel-operations window is 3–6 months: beyond that, dual licensing costs and double-data-entry risks compound, and — the subtler failure — the staff never fully commit to the new platform while the old one remains a fallback. Two budget facts follow. The two-system license budget runs $15K–$40K during the 3–6 month parallel period, depending on book size, and it has to be reserved in the integration budget at deal close, not discovered later. And the legacy license often overhangs ~12 months post-close — old-system contracts frequently run a full year past the operational cutover, separate from the parallel window, which matters for both budget and (as the next piece covers) liability access. Treating the parallel window as a hard 3–6 month bridge with a planned cutover at the end is what keeps consolidation from becoming permanent limbo. The data-integrity risk inside this window is the subject of the data-migration E&O minefield.

§ 03 · The swivel-chair disciplineLook-only on the legacy system.

The single rule that makes the parallel window work is the swivel-chair "look-only" discipline: acquired staff get read-only access to the legacy system for historical reference, but all new business, renewals, and policy changes go directly into the surviving system from day one. The discipline matters because the most common consolidation failure is staff continuing to work in the familiar old system "just for now," which creates two live systems of record, double data entry, and a reconciliation nightmare — the very limbo the window is supposed to prevent. Read-only access satisfies the legitimate need (looking up historical records) without permitting the dangerous behavior (writing new work to the legacy system). It's a small policy with an outsized effect: it forces the commitment to the new platform that a soft transition never achieves, while preserving the historical lookup the staff genuinely need. Enforced from day one, look-only is what turns "we're migrating" into "we've migrated." The change-management that gets staff over the learning curve is in staff training and change management.

§ 04 · When to skip the swivel chairThe fast-cutover case.

The swivel-chair approach is the default, but it's not universal — for small, simple books, the parallel-operations overhead isn't worth it. The fast-cutover threshold: a smaller acquisition (around 200 clients, mono-line, a straightforward book) may favor a day-1-style cutover over the swivel chair, moving everything at once to avoid the cost and complexity of running two systems for months. The trade-off is risk concentration — a fast cutover puts all the migration risk on a single day rather than spreading it across a managed window — which is acceptable for a small clean book and reckless for a large complex one. So the consolidation decision is really two decisions: which system survives (the three scenarios, with the 4× reverse rule), and how to transition (swivel-chair for anything substantial, fast cutover only for small mono-line books). Make both deliberately — reserve the $15K–$40K, enforce look-only, plan the cutover at the end of the 3–6 month window — and platform consolidation becomes a project with an end date rather than a permanent parallel-systems tax. The standardization that rides alongside the platform choice is in workflow harmonization.

◆