Specialized local systems stay in place while their unit makes the case, with real documented costs, that migrating them to the company platform is riskier and more expensive than the center assumes.
Borderline: whether this move is justified depends on the situation, and only the person in it can judge.
An example
When a national insurer bought a regional carrier known for farm and ranch policies, its chief information officer set twelve months to move everything onto the company's policy platform. The regional operations head believed the deadline would break things: her pricing rules, agent hierarchy, and reinsurance treaties ran on a homegrown system built over fifteen years. She had her team document the schema in eight weeks and hired an outside firm to price the migration. The estimate came to nine million dollars, against four in the plan, most of it for rebuilding regulatory filings and commission statements. At the steering meeting she presented both the schema and the estimate and proposed a phased move tied to the reinsurance renewal two years out. The chief information officer accepted the phasing, and the regional system ran through the renewal, its documentation now shared with the central team.
Why it works
Keeping a working system is the low-disruption path, so doing nothing looks easy, and the center's promised savings look worse once real migration costs and risks are set against them. Migration becomes costly in the open, as a capital-and-risk decision with numbers attached. A specialized system genuinely holds years of business logic, and a documented, independently priced case makes that value visible. It depends on outputs the business truly relies on, costs that are real and checkable, and a center that has to weigh the integration bill against its timetable.
The thinking behind it
Oliver E. Williamson Williamson's The Economic Institutions of Capitalism (1985) explains that investments specialized to one relationship, such as knowledge of one firm's systems, lose much of their value outside it and leave both parties exposed to each other. A homegrown system holding fifteen years of pricing logic is that kind of asset, so migration carries real costs. Documenting it reduces the specificity a unit could exploit, which is what makes its cost case believable.
William Samuelson Samuelson and Zeckhauser's Status Quo Bias in Decision Making (1988) found that people choose an option disproportionately often when it is framed as the status quo, and attributed this to transition costs, loss aversion, and commitment to past choices, among other causes. A unit defending its own system benefits from the bias, and part of its case, the transition cost, is real. Independent pricing separates the real cost from the bias.
When it fits
Units whose specialized systems encode real business logic, facing a consolidation whose timetable or budget looks wrong, can use it. The requirements are credible knowledge of your system, the means to document it and have the migration priced independently, and outputs the business depends on, such as regulatory filings or customer reports.
How to use it well
Document the system first, its schemas, business rules, and dependencies, and hand the documentation over. That removes any suspicion of hoarding and makes your numbers believable. Get the migration priced by someone independent. Lay out the risks with dates: which filings, reports, and customer processes depend on what. Then propose an alternative the center can accept, a phased move, a later date tied to a real event, or a parallel run, and say what you will do to make it succeed. Accept the decision when it comes, and help carry it out.
What it costs and where it backfires
Holding out marks you as an obstacle to a sponsor who will remember it, and a center that loses patience may simply build a parallel platform and let your system starve. Your documentation also makes you easier to replace. The evidence is the boundary: withholding documentation, inflating the estimate, or letting reports fail to prove a point turns a cost case into a hold-up, and once that is found out, every later estimate from your unit will be discounted.
When it is used on you
Budget the integration openly and ask the unit for documentation and an independently priced estimate. If both arrive and hold up, the case deserves a real answer, often phasing. If documentation keeps slipping while estimates grow, set dates for it, tie the migration to a mandate, or consider a parallel platform.