Migrate, Consolidate, or Layer: The Post-Acquisition System Decision

Introduction

A multi-branch roll-up spends most of its energy on getting the deal done, and then faces a quieter decision that decides whether the deal actually works: what to do with the systems it just bought. Every acquired branch arrives running its own software, and the instinct, usually, is to migrate all of it onto one platform as fast as possible so the group finally runs on a single system. That instinct is normally defended with a familiar pair of statistics about how often integrations fail. Neither statistic survives a careful read, and the industry’s largest big-bang consolidator has, in its own regulatory filings, evolved its approach toward a layer over the systems it already had. The post-acquisition system decision is best judged the way an operator judges any irreversible bet: by its base rate and its variance, not by how tidy the end state looks on a slide.

• The choice is a bet under uncertainty, not a certainty. Migrating every branch onto one platform is a single, large, hard-to-reverse move; layering a common data and intelligence layer over the systems you inherit is many small, reversible ones. Those two paths have very different risk profiles even when their intended end state is similar.
• The statistics used to justify big-bang migration do not hold up. The Standish CHAOS success rates count only whether a project matched its initial estimate, not whether it delivered value, and Standish itself calls its reports opinion; the oft-quoted claim that 70 to 90 percent of mergers fail is stated with no study cited.
• The flagship consolidator has moved toward a layer, on the record. Across its own SEC filings, Rentokil-Terminix paused its branch migration, withdrew its synergy scorecard as overly subjective, and set its course on an in-development business-intelligence tool that lets multiple systems be maintained over roughly thirty retained brands in North America.
• The lower-variance move is to converge deliberately, not all at once. We argue, from the base-rate logic rather than from any study that proves it, that layering first and converging systems gradually onto a spine you control turns one irreversible migration into a sequence of small, recoverable steps.

The decision every roll-up faces after the deal closes

Consolidation in field services is bought one book of branches at a time, and each book comes with its own operating software, its own service codes, and its own history. The day the deal closes, the acquirer owns not one business but several, glued together at the top and running on different rails underneath. What it does next is a genuine architectural choice, and there are really four of them. It can migrate, ripping out the acquired systems and moving every branch onto one platform in a planned cutover. It can consolidate gradually, standardizing onto a chosen system over years rather than in one move. It can federate, leaving each acquired unit on the stack it came with and coordinating loosely above it. Or it can layer, leaving the underlying systems in place and putting a common data and intelligence layer across them so the group can be run as one without every branch being moved first.

The reason this is hard is that the choice is not really about technology; it is about how much irreversible risk to take, and when. A migration promises the cleanest end state, one system, one set of definitions, one place to look, but it concentrates the risk into a single cutover that is expensive to undo if it goes wrong. A layer promises a messier picture underneath but spreads the risk across many small integrations that can each be paused, corrected, or reversed. The buyer that treats this as a foregone conclusion, migrate everything because one system is obviously better, has quietly assumed the migration will land. Whether that assumption is safe is exactly what the base rate is for, and the base rate is usually argued from two numbers that will not bear the weight.

The failure statistics that do not survive a second look

The first number is the software-project failure rate, and its source is the Standish Group’s CHAOS report, which announced in 1994 a shocking 16 percent project success rate, with another 53 percent challenged and 31 percent failed outright, on a sample of 365 respondents representing 8,380 applications. Those figures are among the most-cited in all of software, and they are also, on a close and peer-reviewed reading, not what they appear to be. In a 2010 IEEE Software analysis, Eveleens and Verhoef showed that Standish defines a successful project solely by adherence to an initial forecast of cost, time, and functionality: a project counts as a failure not because it delivered no value but because it deviated from its first estimate. Steer a team toward that definition and, as the authors document, forecasting quality actually gets worse, because managers pad their estimates to hit the target. Even a best-in-class organization with unbiased estimates scores only a 35 percentsuccess rate under the Standish definitions. When the authors put their critique to Standish, the group replied that all of its reports “should be considered Standish opinion and the reader bears all risk in the use of this opinion.” A statistic its own publisher calls opinion, and that measures estimate-adherence rather than delivered value, cannot carry an irreversible decision.

The second number is the merger failure rate itself. It is quoted everywhere, and its most prominent home is a Harvard Business Review cover article, which states plainly that study after study puts the failure rate of mergers and acquisitions somewhere between 70 percent and 90 percent, and then names no study at all. That is not to say the truth is comforting; it is to say the headline figure is folklore in the place it is most often cited from. The defensible academic anchor is quieter and more useful. A widely cited meta-analysis of post-acquisition performance by King, Dalton, Daily and Covinfinds that, on average and across the most commonly studied variables, an acquiring firm’s performance “does not positively change as a function of their acquisition activity, and is negatively affected to a modest extent,” and, more importantly, that unidentified variables may explain significant variance in how acquisitions turn out. The honest reading of the evidence is not that integration reliably fails. It is that acquisition outcomes are, on average, no better than flat and highly variable, which is precisely the condition under which you should prefer the option that keeps your mistakes small.

A consolidator’s own record, in its own filings

The most useful evidence on the migrate-versus-layer question is not a survey; it is what the industry’s largest big-bang consolidator has told its own investors, filing by filing. In its October 2024 trading update, Rentokil-Terminix said a review of its integration programme would push 2025 synergies out by approximately 2 to 3 months and that, during the first quarter of 2025, it would review its “optimal branch network footprint.” Revenue and margin guidance for the year were left unchanged, so this was a change of plan, not a profit warning; North America organic revenue growth was running at about 1.4 percent at the time. A few months later, in its 2024 final results, the company went further on the integration itself: it would “not report separately on net synergy delivery” any more, because disaggregating investment and inflation from synergy savings had become, in its words, “overly subjective,” and the full branch integration process was “planned to restart in early H2 2025.” A migration that is paused and restarted, and whose synergy savings the company judged too entangled with investment and inflation to report cleanly, is a migration whose difficulty is at least consistent with the base rate.

The destination of that review became explicit a year later. In its 2025 preliminary results, Rentokil described an “evolved strategy” whose centrepiece is “an in-development BI (Business Intelligence) tool allowing multiple systems to be maintained, significantly reducing the operational impact of branch integrations,” supporting a “simplified approach to deliver c.800 branches and c.30 retained brands in North America.” The company frames this in its own terms, as a plan that “mitigates further risk of disruption,” and reports 25 million dollars of savings delivered in 2025 against a 100 million dollar cost-reduction target for 2027 that it calls itself on track to hit. It is not this essay’s place to say the consolidator conceded anything or vindicated anyone; the company’s own language is that it evolved its approach. But the shape of the move is unmistakable and it is on the public record: the flagship consolidator chose to maintain multiple systems behind a common tool rather than finish migrating them all onto one, which is, whatever it is called, a layer over retained systems.

One more fact sits in the same file drawer and is easy to over-read, so it is worth stating precisely. In September 2024, Rentokil appointed Brian Baldwin, the head of research at Trian Fund Management, as a Non-Executive Director; Trian disclosed that it manages investment vehicles owning approximately 57.1 million shares, approximately 2.26 percent of the shares outstanding. That is a constructive board seat and a holding below 3 percent, not a control stake; it was an agreed appointment, and nothing here casts it as a hostile move or credits it with driving the systems decision. Baldwin’s stated thesis was about “leveraging its strong brands and market leading positions, particularly in the US.” The seat is context, coincident with the strategy shift; it is noted only because the alignment between an investor who prizes the group’s brands and a strategy that now keeps roughly thirty of them is the kind of thing a careful reader should see acknowledged rather than buried.

The contrast that corrects the thesis

It is tempting to draw the tidy conclusion that one operator migrates and fails while another layers and wins, and the tidy conclusion is wrong on the facts. The instructive contrast is Rollins, and its own 10-Kdoes not describe a company that layers over heterogeneous systems. It describes the opposite discipline on the systems axis: “the majority of our business runs on our proprietary Branch Operating Support System,” which it calls BOSS, and the company says it has “made investments to evolve and modernize BOSS capabilities to standardize for efficiency.” What Rollins keeps distinct is the brand, not the stack. It runs a “family of leading brands” under “one reportable segment,” keeping the customer-facing identities distinct while converging the operating system beneath them onto a spine it owns and controls. It even lists, as a plain risk factor, that it “may also experience difficulties, costs or delays in migrating acquired businesses to our systems, processes, and technologies.”

So the real distinction is not layer versus migrate in the abstract; it is what you converge onto, and whether you own it. Rollins converges gradually onto a proprietary system it has built and can bend to its own book. The harder, higher-variance version of the same instinct is to force acquired branches onto a third-party platform on a fixed cutover schedule, which is the move that runs straight into the base rate. Read together, the two companies do not show that layering beats migrating. They show that the durable pattern is to keep the customer-facing brands distinct, converge the systems deliberately rather than all at once, and, wherever possible, converge onto a spine you actually control.

Why layering is the lower-variance bet

Here is the argument this essay is willing to make, stated as an argument and not as a proven law. A big-bang migration is a single high-variance bet whose success, under the very definitions the industry cites, is often measured as hitting an original budget and timeline, and whose failure is expensive to reverse once the old systems are gone. Layering first converts that one large irreversible move into many small reversible ones: each acquired system is left running while a common data layer is placed over it, and branches are moved onto a shared spine one at a time, only when the move is safe, with the old path still there to fall back to. This is an argument about variance and optionality, not an empirical finding; no cited study proves that layering beats consolidating, and this essay does not claim one does.

The pattern is not novel, which is part of why it is defensible. Incremental, reversible migration is an established idea in software architecture, most cleanly captured by Martin Fowler’s strangler fig pattern: rather than replace a running system in one cutover, you build the new capability around the edges of the old one and let it take over gradually, so the old system keeps working until the new one has genuinely earned its job. The economic case is the same one a careful operator would make about any irreversible expense. When outcomes are, on the best academic evidence, no better than flat on average and highly variable, the rational preference is for the path that caps the downside of any single mistake. Layering does that; a forced migration onto a platform you do not control does the opposite.

What this means for the buyer, and its limits

It is worth being exact about what this evidence supports. It shows, from primary sources anyone can read, that the two statistics most often used to justify a big-bang migration do not survive scrutiny, that a serious meta-analysis finds acquisition outcomes flat on average and highly variable, and that the largest consolidator in the industry has publicly moved toward maintaining multiple systems behind a common tool. It does not show, and this essay does not claim, that consolidation caused any company’s results, or that layering would have produced better ones; the filings are a record of a decision and its stated rationale, which is coincidence and disclosure, not proof of cause. The honest conclusion is narrower and more useful than a verdict: the post-acquisition system decision should be judged as a variance bet, and the base-rate logic favours the reversible path.

That is also the boundary a vendor has to state plainly. Software does not choose the strategy, and a layer is not a magic wand; the decision to converge gradually rather than all at once is the operator’s, and the work of standardizing definitions and joining records is real either way. What a data and intelligence layer can do is make the reversible path workable in the first place, letting a group be run as one, with common definitions and one place to look, while the underlying systems stay in place and are converged deliberately. Ardenus sits on top of the systems an operator already runs and is built for exactly that layer, but no result, saving, or forecast is attributed to Ardenus here; the case above is made entirely on the public record, and no client or first-party data appears anywhere in this essay.

The reason this reaches the boardroom is that the system decision is where a roll-up either compounds or stalls. Whether the combined book can be priced as one durable business, rather than a stack of separately-run acquisitions, is the subject of our essay on why valuation follows revenue quality, not revenue. The retention economics that a botched cutover puts at risk are the theme of why churn is a distribution, not a number; the density economics of actually serving the combined footprint are covered in why route cost follows density, not scale; and the reason the systems are worth unifying at all, that their records are the asset being bought, is the argument of the negative effects of dirty data. The through-line is the one this essay began with: judge the system decision by its variance, and keep your mistakes small. You can read more of our research on the Ardenus articles hub, or see the platform itself on the technology page.