“I’ve lived the rewrite-versus-refactor choice more than once. At the Federal Reserve I helped break the GTAS monolith into standalone Spring Boot services, and at Express Scripts we kept Express-Scripts.com alive while pulling capabilities into services around it. The real question is whether your business can survive the rewrite going dark for months or years.”
“I led an incremental migration from a monolith to microservices at Docler, and the parts we carved out first were the ones that moved independently: streaming, billing, user state. Everything else stayed put until it had a clear seam.”
“At Splunk, I watched a rewrite of a monolithic marketing platform eat eighteen months while the business kept asking for features we couldn't ship; the teams that won were the ones that carved off one bounded context at a time and ran it on Kubernetes next to the old stack. I would only rewrite if the monolith is actively blocking a business outcome that piecemeal work cannot unblock.”
“I’ve seen teams burn a year rewriting a monolith that was never the bottleneck, while the ones that won used the Strangler Fig pattern to peel off one bounded context at a time. The real question is which part, if it failed tomorrow, would hurt revenue or compliance first. Start there.”
“I would keep improving it piece by piece unless the monolith is actively blocking a measurable business outcome, like one module needing to scale independently or a team unable to ship without full redeploys. At RedCloud, we moved from a tightly coupled core to clearer module boundaries first, then extracted services only where the pain was real.”
“Engineers usually want to rewrite because fresh code feels cleaner, but I've spent a lot of my career cleaning up the mess from that risk. The complexity isn't in the easy features, it's in the edge cases and embedded requirements that already work in the monolith. I'd push hard to refactor piece by piece unless the business can clearly name the risk it's willing to take.”
“We don't refactor, we rebuild. Whop's $1.2B GMV runs on a Rails monolith with 20 engineers because we keep throwing out systems built on old assumptions and rewriting them with what we know now. Sunk cost is the real killer, not the rewrite.”
“I have watched teams burn six months on a rewrite while the monolith kept paying the bills. Unless the codebase is actively blocking the business, I would carve out one bounded context at a time and let the new shape prove itself before killing the old one.”
“I have seen teams burn eighteen months on a big-bang rewrite only to ship a slower, buggier copy of the monolith they already had. I would keep improving it piece by piece and only extract a service when one bounded context is clearly choking on its own deployment or data needs.”