By common industry estimates, somewhere between 60 and 80 percent of a typical corporate IT budget goes not to building anything new but to keeping alive systems that already exist. That number is the entire software modernization market in one statistic: an enormous, permanent spend on not-falling-over. And into that spend walks a category of vendor — modernization services — whose core pitch is that the spend exists because your technology is old, and that the cure is to replace it. That diagnosis is wrong often enough that it should be the default suspicion, not the default purchase.
The consensus take, and why it's lazy
The standard modernization narrative is clean and easy to sell. Your stack is old. Old is risk. So you scope a transformation: lift the monolith to the cloud, break it into microservices, swap the old framework for the current one, and emerge cloud-native and future-proof. The slide deck has a before column and an after column, and the after column is all the words that test well this year. It is a tidy story, and it sells engagements because it is legible to the people signing the check. It is also a story about technology, when the actual problem is almost never technology.
Here is the thing the deck never says out loud: 'legacy' is not a measure of age. A ten-year-old codebase that the original team still runs, still understands, and still ships to every week is not legacy — it's mature. A three-year-old codebase whose authors have all left, whose deploy process lives in one person's head, and whose test suite was never written is legacy on day one of the handover. Legacy is the gap between a system and the people who understand it. When that gap is wide enough, the software might as well be a black box bolted to your revenue.
What actually rots: the knowledge, not the code
Code does not decay in the box. The bits are exactly what they were the day they shipped. What decays is everything around them: the engineer who knew why the payment retry logic has that weird three-second delay, the context for why a 'redundant' table is load-bearing, the unwritten reason the batch job runs at 2 a.m. and not 3. That knowledge leaves with people, and in an industry where annual turnover routinely sits north of 20 percent, it leaves constantly. A 'modernization' problem is very often just an accumulated-departure problem with a technical accent.
This is why the most dangerous legacy systems are not the COBOL ones. The COBOL mainframes that still clear a huge share of the world's banking transactions are well-documented, heavily-tested, and tended by people who treat them with respect precisely because everyone knows they're irreplaceable. The genuinely terrifying systems are the five-year-old web apps written fast, by a team that has since dispersed, in a framework version nobody remembers choosing. Age is not the threat. Abandonment is.
The rewrite is the trap, and it's the one being sold
The single most reliable way to fail at modernization is the one modernization vendors most love to sell: throw the old system away and build a new one from scratch. The reasons it gets sold are not mysterious. Greenfield is fun to staff and easy to scope. A clean rewrite is legible — fixed deliverable, fixed timeline, fresh repo — in a way that 'we will carefully untangle the thing you already have' is not. And a from-scratch build bills more hours than a surgical one. The incentives of a services firm point straight at the rewrite almost regardless of whether the client needs it.
The argument against the big-bang rewrite is old and keeps being right. The version most engineers know is Joel Spolsky's, from 2000: rewriting from scratch is the single worst strategic mistake a software company can make, because you throw away every bug that the old code had quietly learned to handle and you spend years rebuilding to parity while a competitor — or your own backlog — runs past you. The famous casualty was Netscape, which rewrote its browser, lost years, and handed the market to Internet Explorer. Two and a half decades later the dynamic hasn't changed; only the framework names on the slides have.
The rewrite's hidden cost is parity. The old system does a thousand things, and maybe forty of them are written down. The other 960 are edge cases discovered in production over years — the malformed input some integration sends every Tuesday, the tax rule for one jurisdiction, the customer whose account predates a schema change. A rewrite doesn't get to skip those; it gets to rediscover every one of them, in production, with angry users, while the old system you were going to switch off has to keep running anyway. You don't get a clean cut. You get two systems to maintain and a migration that slips for a year.
The boring discipline that actually modernizes
Real modernization is unglamorous and it does not photograph well. It starts with reading — actually reading the system, instrumenting it, finding out what it does before touching what it is. Then it proceeds incrementally: wrap the old system, route one capability at a time to new code, verify behavior against the live system, and let the old thing shrink until there's nothing load-bearing left to switch off. The pattern has a name — the strangler fig — and the reason it works is that you are never more than one small, reversible step away from a system that still runs. There is no Big Day. There is no all-or-nothing cutover that has to go perfectly at midnight.
This is the lens we cut every modernization conversation with at EltexSoft, because we've been on the receiving end of the alternative. When we picked up Meal4U, the prior team had failed to deliver and the instinct in the room was to start over. Instead we spent a week deconstructing scope and re-estimated the work something like ten times, cutting 30 to 50 percent each pass until we found the smallest thing that could actually ship. That is what modernization discipline looks like in practice: not a heroic rebuild, but a relentless argument about what does not need to be rebuilt. With Nautical Commerce we did the same with an existing codebase — took over a one-year-old system and delivered against a 90-day go-live rather than insisting on a clean slate. The boring path is the fast path. The clean slate is the slow one wearing a nicer outfit.
Cloud-native is not a synonym for modern
A large share of modernization spend is re-architecture for its own sake: a monolith that worked fine gets shattered into microservices because microservices are what modern is supposed to look like, and a team that struggled to operate one deployable now gets to operate forty, plus the network between them. Moving an app to the cloud unchanged — lift and shift — modernizes nothing; it relocates the same system to a more expensive zip code and sends you a bigger bill. None of these are wrong as tools. They are wrong as goals. Microservices solve an organizational scaling problem; if you don't have that problem, they're just distributed-systems failure modes you bought on purpose.
The honest test for any modernization move is brutally simple: what specific risk or cost does this remove, and how will you know it worked? 'It'll be on the current stack' is not an answer. 'The deploy that takes a day and needs the one person who understands it will take ten minutes and need nobody special' is an answer. 'The fraud rule we can't currently change without fear will be covered by tests so we can change it weekly' is an answer. Modernization that can't name the risk it retires is just spending dressed as strategy.
The part nobody puts in the SOW: who holds the system afterward
Say the rewrite even works. Say the migration lands. You now have a shiny modern system — and if the people who built it roll off to the next engagement the week it ships, you have just manufactured your next legacy system at considerable expense. You've reset the clock on the only thing that actually rots: the gap between the code and the people who understand it. A modernization engagement that ends with a knowledge handoff to nobody is not modernization. It's a deferred repeat purchase, and the vendor knows it.
This is the part of the pitch where our own numbers do the arguing, because they're unusual enough to be the point. Our engineer turnover runs under 5 percent a year against an industry norm well above 20; our average engineer tenure is around eight years and our average client engagement around four. We've been MyFlyRight's engineering partner since 2016 — the same team, building and maintaining the same platform, for the better part of a decade. The reason that matters for modernization specifically is that continuity is the actual deliverable. The strangler-fig approach only stays cheap if the people doing the strangling are still there next quarter to finish it, and the system stays modern only as long as someone who understands it is still in the room. Body-shopped teams that rotate every few months can't deliver that no matter how good the individual engineers are.
How to tell a modernization partner from a rewrite shop
The tell is what they do in the first two weeks. A rewrite shop wants to talk about the target architecture immediately — the new stack, the new diagram, the after column. A modernization partner wants to read your system first and will tell you, sometimes annoyingly, how much of it should not be touched. Ask any candidate vendor what they would refuse to rewrite and why. If everything is on the table for replacement, you're buying a greenfield project with a modernization label, and you should price it as one — full rebuilds of a serious platform land in the same six-figure-and-up bands as any from-scratch SaaS or marketplace build, not the cost of a careful retrofit.
Ask, too, how change gets made and reviewed, because incremental modernization lives or dies on discipline. On our side every pull request is reviewed by at least one other senior engineer before it merges — not because it's a nice habit, but because that's the mechanism that stops a careful incremental migration from quietly becoming an undocumented rewrite one merge at a time. The process is the product. A modernization service without an enforced review discipline is just two juniors and an LLM editing your production system on trust.
If the model itself is still fuzzy, start with our full breakdown of when staff augmentation is worth it. And when you want to see how we structure engagements around retention, our staffing services lay it out.
The position, stated plainly
Software modernization is not a service you buy. It's a discipline you stopped practicing — continuous ownership of a system by people who understand it — and most modernization services are selling you a one-time rewrite to cover for the fact that the discipline lapsed. The rewrite will feel like progress because it produces a new thing. The new thing will rot exactly as fast as the old one if no one stays to tend it. Buy the discipline, not the rebuild: a team that reads before it touches, replaces in small reversible steps, names the risk every change retires, and is still there a year later. Everything else is the spend that put you here, sold back to you with better slides.