The move nobody notices
Part 1 made the case: your legacy CRM became a system of resistance through the entropy of success, rip-and-replace re-platforms the mess rather than retiring it, and the smarter question is not "which vendor next?" but "how much of the stack around our record do we want to own?"
This article is the start of the answer - the reboot playbook, layer by layer. And it begins with the least glamorous move in enterprise IT, one your users will never notice: changing where the system runs.
That invisibility is the point. The reboot’s first principle is stability for the record, freedom for everything else. Every step in this playbook leaves the core untouched and the users undisturbed, while quietly removing the constraints that made the system resistant in the first place.
First, put the record in a container
A twenty-year-old CRM typically runs the way it was installed: on dedicated servers, in one data centre, in a configuration nobody dares touch, with an upgrade process that takes a quarter and a test environment that takes a committee.
The first reboot move is lifting that estate into containers - Kubernetes and the open toolchain around it. This is not a rewrite. The application is the same application; what changes is the packaging: application tiers built as images, configuration extracted into code, state pushed to where it belongs. We have done this with CRM estates old enough to vote. It is careful work, but it is weeks-to-months work, not migration years.
What it buys is out of all proportion to its glamour. The record now runs where you choose: your data centre, any cloud, or both. A full test environment spins up in minutes instead of a quarter, which means you can finally rehearse changes instead of fearing them. Upgrades become rolling and reversible. And a conversation quietly changes: the infrastructure under your most critical system no longer belongs to anyone’s roadmap but yours.
The reboot stack
Then, set the data free
Here is the tax every resistant CRM collects: it is the only place the data lives, so every report, every integration, every experiment must queue at its door. Nightly batch exports. Integration projects. A BI team that spends its life negotiating with a twenty-year-old schema.
The second layer of the reboot ends this with one of the most useful patterns in open-source data engineering: change data capture. An open CDC pipeline, the Debezium-and-Kafka pattern, watches the CRM’s database log and streams every change, as it happens, into open infrastructure beside it: PostgreSQL for relational workloads, OpenSearch for search and analytics.
The result is a continuously fresh, read-only replica of the record, on open technology, in your schema of choice, that the whole enterprise can build against without ever touching the core. Reporting moves off the CRM. Integrations read from the replica. The data science team stops filing tickets. The CRM keeps doing the one thing it is genuinely good at, being the record and stops being the bottleneck for everything else.
And note what this layer quietly becomes: curated, current, streaming data on infrastructure you own. Readers of our first series will recognize the shape, this is AI-ready data being built as a by-product of modernization.
Set the data free
Then, give the screens a second life
With the record containerized and the data flowing, the third layer is the one users finally see: the screens.
The pattern here is a modern open-framework UI - React, Angular, Oracle JET and their peers, built in front of the old application for the workflows that matter most. Not every screen: the case screen the service team lives in, the account view sales open fifty times a day. The new UI reads from the fast replica, writes through the record’s own APIs, and inherits every rule the record enforces. The transaction is still the system of records. The experience stops being 2004’s.
This is deliberately the third move, not the first. A new face on a frozen estate is a coat of paint; a new face on a containerized, data-freed estate is a front end with a future.
Why this is not a migration in disguise
It is fair to ask whether the reboot is just a migration in instalments. It is not, and the difference is structural.
Nothing moves permanently. The record stays the record; the replica is a copy; the new UI is a layer, not a cutover. Every step is independently valuable, the container layer pays for itself in environments and upgrade safety, the data layer in retired batch jobs and unblocked teams, the UI layer in handling time and every step is reversible. There is no day on which everything must go right.
That is the deepest difference: a migration bets everything on one day. A reboot pays out every month.
The order matters, too. Hosting first, because safe environments are what make the rest low risk. Data second, because the replica unblocks every team downstream. Screens third, because a visible win lands best on a foundation that can support it. And all of it run the way the first series argued production AI should be run as an owned product with a roadmap, not a project with an end date.
Two risk curves
The layer that changes everything and the next article
There is one layer left, and it is the one the whole reboot has been quietly preparing for. A containerized record with a streaming, open, current replica of its data is precisely what enterprise AI has been waiting for.
The next article puts intelligence inside the CRM: agent assist in the case screen, powered by an open retrieval stack, running on open models, where the data lives - answering from your governed record, at a cost per query you control, with no per-seat AI tax. The quiet wins of our first series, delivered through the system everyone already has open.