The system everyone routes around
Every large enterprise has one: a CRM that has run the business for fifteen or twenty years. It holds every customer, every case, every contract. It is, in the truest sense, the system of record.
And almost everyone routes around it.
Sales keeps the real pipeline in a spreadsheet. Service agents keep personal cheat sheets for which fields actually matter. Managers export to Excel before every review, because the report they need exists only as tribal knowledge. The system that records the business is no longer the system where the business thinks.
This series is about that gap and about a different way to close it. Not another migration. A reboot: keeping the record you trust and rebuilding the layers around it, largely with open-source building blocks you own. But before the playbook, it is worth being honest about how we got here.
How a record becomes a resistance
Nobody sets out to build a resistant system. It happens through two decades of individually reasonable decisions.
A customization for the 2009 reorganisation. A mandatory field added for a compliance push. An integration written for a product line that no longer exists, still running because nobody is certain what would break. Fields repurposed - everyone knows "Region 7" actually means the strategic accounts team, except the new joiners, who learn it the hard way.
Each change made sense. Together they compound into something else: a data model that reads like archaeology, workflows only veterans can navigate, and a system where the safest answer to "can we change this?" is no. The workarounds hardened into muscle memory, and the muscle memory quietly became the real process.
This is not a failure of the product or the people. It is the entropy of success. Systems that matter accumulate complexity precisely because the business kept asking them to do more.
Anatomy of a system of resistance
The double cost of lock-in
The visible cost of staying put is the license and support bill - the line the CFO sees, and the one every vendor negotiation is fought over.
The larger cost is quieter: inertia priced in someone else’s currency. Every new capability arrives on the vendor’s roadmap, at the vendor’s pace, at the vendor’s price. Every integration becomes a project. Every experiment waits for an upgrade cycle. When the AI wave arrived, the question most CRM owners could ask was not "what could we build?" but "what will we be sold, and when?"
That is the real lock-in: not the contract, but the loss of the ability to move independently. And it reframes the modernization question. It is not "which vendor should we migrate to?" - that trades one landlord for another. The sharper question, and the one this series pursues, is: how much of the stack around our record do we want to own?
The double cost of lock-in
Why rip-and-replace keeps failing
The standard answer to a resistant CRM is the big migration. The business case writes itself: modern platform, clean data, fresh start. Three years and many millions later, the familiar pattern: scope cut, timelines doubled, and users rebuilding on day one the same workarounds they had before, because the workarounds were never the system’s quirk. They were the undocumented process.
A migration faces an impossible choice with twenty years of accumulated complexity: faithfully recreate it on the new platform (expensive, and you have moved the mess), or rationalize it in flight (and discover how much of the "mess" was load-bearing). Either way, one truth survives the project: a migration does not retire your complexity. It re-platforms it.
Meanwhile, the migration freezes everything else. For three years, the answer to every improvement is "after go-live." The resistant system wins again, this time by holding the future hostage.
The contrarian case: start where the workflow lives
Here is what the first series taught us about enterprise AI: it succeeds when it is embedded in the workflow people already have and fails in standalone portals. Now ask: where does your customer-facing workflow actually live?
In the resistant old CRM. That is where the agent’s case screen is open all day, where the history sits, where the record of truth, for all its archaeology actually resides. The system everyone complains about is also the single highest-leverage place to put modern capability.
And this is the reboot thesis: the record is not the problem. The rigidity around it is. You do not need to replace the system of record to modernize the experience of using it, you need to open the layers around it: where it runs, how its data flows, what its screens look like, and what intelligence sits beside them. Each of those layers, today, can be rebuilt on open foundations - Containers and Kubernetes for the hosting, open data pipelines for the flow, modern open UI frameworks for the screens, open models for the intelligence -infrastructure you own, at costs you control.
Keep the core. Free everything around it.
Replace vs. reboot
The reboot map and the next article
Over this series we will walk the playbook layer by layer: how to move a twenty-year-old CRM into containers without changing what users see; how to stream its records into open data infrastructure the rest of the enterprise can finally build on; how to put a modern face on old screens; and how to add AI where the work happens - all without a migration, and mostly without asking a vendor’s permission.
The next article starts at the foundation: Modernize Without Migrating - what it takes to lift a legacy CRM into the container world, and why that single unglamorous move unlocks every layer above it.