Decoupling a monolith without a rewrite

Every few years somebody proposes the rewrite. The old system is slow, nobody wants to touch the ordering module, and a clean build sounds like relief. I have sat in that meeting a lot of times, on both sides of it, and the rewrite almost never survives contact with the business.

The reason is simple. A rewrite asks the company to pay for two systems and get value from one, for however long it takes. Nobody knows how long it takes. Meanwhile the legacy system keeps taking orders, because that is its job.

The thing that has actually worked for me, at gen.video and again at Dell EMC, is less satisfying and much cheaper: pick one seam, do it properly, and let the pattern spread.

Pick the seam by blast radius, not by pain

The instinct is to start with whatever hurts most. That is usually the wrong first move, because the thing that hurts most is normally the thing everything else touches. You will spend six weeks in there and have nothing anybody can point at.

Better to pick something with a real boundary already: a piece of the system with its own data, few callers, and an obvious contract. Search is often a good candidate. So is anything that talks to a third party. You are not trying to fix the worst part yet. You are trying to prove the pattern in a place where being wrong is survivable.

Build the bridge before the service

The mistake I see most is a new service that quietly assumes the legacy system will be gone soon. It will not be. It will be there for years, and the new service has to talk to it the whole time.

At gen.video that meant an SDK: one deliberate way for a new service to reach into the legacy platform over REST, instead of every service growing its own private opinion about the old database. It sounds like overhead on day one. By the fourth service it is the only reason the migration is still moving.

If the legacy shape leaks into every new caller, you have not decoupled anything. You have just added network latency.

Make the swap boring in advance

The warehousing rewrite I did in healthcare is the clearest example I have of this paying off. The interesting event, from the outside, was migrating off NetSuite onto Stratix, and how little of it anybody noticed. But that was not a clever migration. It was a decision taken years earlier not to let the ERP’s shape reach the callers.

When the vendor changed, the code that had to change was the code that talks to the vendor. That is the whole trick. It is not sophisticated, it just requires believing on day one that the vendor will eventually change, and paying a small tax for it every day until you are right.

Write down why, not what

Six months later nobody remembers why the boundary was drawn where it was, and the next engineer moves it because it was inconvenient on a Tuesday. An ADR is fifteen minutes and it survives the person who wrote it. That is the cheapest thing on this list and the one most often skipped.

What this actually buys you

Not elegance. You will have a system with a modern half and a legacy half and a bridge between them, and it will look like that for a long time. What you get instead is the ability to keep shipping features while it happens, which is the thing the rewrite cannot promise.

The monolith does not have to die on a schedule. It just has to stop being the only place work can happen.

If any of this sounds like the system you are sitting on, email me.