Rebuild or repair your backend?

The short answer

Most rebuild decisions are made without evidence, by whoever is most frustrated with the code that week. The decision should instead rest on three questions you can answer in about two weeks: can the system be changed safely, can it be run safely, and does it cost more than it earns? If the answer to all three is yes, keep it and fix what hurts. If one is a hard no, replace that part, behind a boundary, while the rest keeps running. A full rewrite is the right answer far less often than it is proposed, and when it is right, the evidence makes the case for you.

The rest of this page is how I get to that answer, drawn from a migration at KFC Thailand where the starting point was a PHP monolith on EC2 that could not survive a promotion, and the ending point was event-driven services handling 5M+ orders a month. The answer there was replace, but in slices, and the order of the slices mattered more than the architecture.

The three questions that settle it

1. Can it be changed safely? Look at the last ten changes. How many caused an incident, how long did each take from commit to production, and could any of them be rolled back? A system that takes a week to change and breaks one time in five is not a candidate for keep-as-is, but it may only need a deploy path and tests, not a rewrite.
2. Can it be run safely? When it fails, does anyone find out before a customer does, and can the team recover without the one person who understands it? If the honest answer is no, the first fix is observability and a runbook, which is weeks of work, not the months a rebuild costs.
3. Does it cost more than it earns? Put the AWS bill, the incident hours and the time lost to slow releases against what the system produces. A system that is ugly but cheap and stable is a keep. A system that eats the roadmap is not, whatever the code looks like.

Notice that none of these questions is about code quality. Code quality is an input to the first question, not a verdict on its own.

What to measure in two weeks

Two weeks is enough to replace opinion with a table. Map the surface of the system: every endpoint, job and integration, with its traffic and its failure rate. On the KFC Thailand monolith that was 47 API endpoints, and the mapping showed that 12 of them caused 80% of the latency. That single finding reframed the whole decision, because it meant the problem was not "the monolith" but a dozen hotspots that could be moved one at a time.

Alongside the map, collect the change history (the last ten releases and what happened), the incident history (what broke, how it was found, how long recovery took), the cost breakdown per component if tagging allows it, and the test reality for the two or three flows the business cannot lose. Then fill in the keep, fix or replace table component by component. Mark the unknowns as unknown. A table with honest gaps is worth more than a confident recommendation built on guesses.

When a rebuild really is right

Sometimes the table says replace, and the case is clear. The runtime is end of life and unpatched. The data model cannot express what the product now needs to do, and every feature is a workaround. The architecture cannot scale in the dimension the business is growing in, and you have measured that, not assumed it. Or the system is small enough that rebuilding it is genuinely faster than understanding it, which is rare for anything with paying customers.

Even then, "rebuild" should not mean "stop everything and start again". It means the replacement is decided, and the question moves to sequencing: which slice first, how traffic moves across, how you know the new slice is right, and how you get back if it is not. A rebuild with no rollback plan is the same one-way door as any other risky change, just a bigger one.

The usual middle answer: replace in slices

The pattern I reach for most is the Strangler Fig: put a routing layer in front of the old system, move one endpoint or one capability at a time onto new services, and let the old system shrink until what is left can be switched off. Traffic moves gradually, both versions run side by side, and every step can be reversed by changing a route.

On the KFC Thailand migration, the first slice was the order search API: low risk, high visibility, and a way to build team confidence before anyone touched checkout. Order lifecycle events then moved onto a Kafka event bus so the services stopped depending on synchronous calls into the monolith, and both systems ran in parallel for six weeks with response times and error rates compared side by side before the final cut-over. The result was P99 latency from 2.8 seconds to under 200 milliseconds, peak capacity from around 500 requests a second to more than 5,000, and a monthly infrastructure bill about 30% lower. The business kept selling throughout.

Scope the first repair to prove the decision

Whatever the table says, the first piece of work should be small enough to finish in a few weeks and shaped so that finishing it proves the decision was right. If the call is fix, the first repair is usually the deploy path and rollback, because everything after that gets safer. If the call is replace in slices, the first slice is the one with the best ratio of visibility to risk, not the one that hurts most. And every first repair needs a way back. On that migration, blue-green deploys meant one bad service release was rolled back in under 30 seconds with no customer impact, and that safety net is what made the team willing to keep moving.

The first repair also sets the working pattern for the rest: how changes are reviewed, how results are checked, and who on your team owns each piece afterwards. Get that right on something small and the large work inherits it.

What I will not promise

I will not tell you the answer before the two weeks of evidence, because I do not know it, and anyone who does is guessing. I will not promise that a rebuild lands on schedule, because rebuilds of systems with real users rarely do, and the honest plan is slices with a way back. And I will not recommend replacing something because the code is unfashionable; the table has to say so. What you get is a recommendation you can defend, the evidence behind it, and a first repair scoped to prove it.The project rescue review is where that starts.