Application Modernization Case Studies: What 8 Real Projects Got Right

Most application modernization case studies you find online are useless to you. They describe "a major financial institution" or "a global retailer," give you a tidy before-and-after, and never name anyone. Every one is a win, because the company publishing it did the work. And not one of them tells you the part you actually need: what would have made it fail, and what you should copy.

I have run modernizations myself, going back to one of my first real projects in 2002, and Full Scale staffs the engineers who do this work for other companies every day. So I want to do these differently. Below are eight modernizations. Four I lived through or my company ran. Four are famous and well documented, including one that everyone copies for the wrong reasons and one that turned into a public disaster. Each one comes with the takeaway I'd give you if we were talking it through.

The thread running through almost all of them is simple, and it's the most reliable rule I know in this entire subject.

The modernizations that work go piece by piece. The ones that blow up try to flip everything at once.

If you want the full decision framework behind that, the R's and when not to modernize at all, read our guide to legacy application modernization. This piece is the proof.

1. Replacing a million-dollar lab system, one module at a time

Back in 2002, on one of my first big projects, I worked at a medical lab that was paying Cerner around a million dollars a year for an aging laboratory information system running on an AS/400. Our IT manager, Dan Spragle, was bold enough to believe we could build our own replacement in .NET and stop writing that check. We did, and it took about two years.

The reason it worked had nothing to do with how ambitious it was. We never tried to switch the whole thing on in a single weekend. We stood the new system up next to the running one and pulled the lab's work across in pieces, one workflow at a time, with both halves talking to each other the whole way. The hard calls were never the code. They were judgment: deciding how much to hand to the new system and take away from the old one each step, without breaking the lab in between. By the time we reached the final switch, so little was left running on the AS/400 that flipping it off was a non-event.

Matt's takeaway: The win was the method, not the nerve. A two-year replacement of a core system only survives if you shrink the final cutover down to almost nothing. We didn't have a name for it then. It's the Strangler pattern, and it's still the safest way to replace something you can't afford to break.

2. Netflix: the case everyone copies for the wrong reasons

Netflix is the most cited modernization story in software, and most people take exactly the wrong lesson from it. After a database corruption caused a multi-day outage in 2008, Netflix moved off its own data centers and onto AWS, and re-architected its monolith into microservices. By 2012 it was running hundreds of microservices handling more than a billion API calls a day. The full move took the better part of eight years (see a brief history of scaling Netflix).

Here's what gets lost. Teams read "Netflix uses microservices" and decide they need microservices too. They copy the destination and skip the road. Netflix got there gradually, over years, at a scale almost no other company will ever reach, and they built the tooling and the org to support it as they went. Copy the architecture without the scale or the path and you've bought yourself a pile of distributed-systems complexity you didn't need.

Matt's takeaway: The reproducible lesson from Netflix isn't "go microservices." It's that they moved one component at a time and let the new system grow around the old one, which is something that works at any size. Their hundreds of services are a consequence of their scale, not a template for yours.

3. Stackify: modernizing a live system that never stopped

At Stackify I modernized a large .NET Framework application off WCF and onto new .NET Core Web API services, the .NET Framework to .NET Core migration a lot of teams are still facing. This wasn't a side project running quietly in a corner. The APIs were taking in billions of data points a day on Azure, and we were moving them off the Windows-only world and onto Linux running in Kubernetes. The whole thing kept serving customers the entire time.

We did it service by service, old and new side by side, and we only routed real production traffic to a new service once it had proven it could handle the load. Nothing about that system could go dark while we worked, so the only sane option was to replace it in slices small enough that any single slice failing was a contained problem instead of a company-wide outage. It was a massive upgrade and it worked.

Matt's takeaway: The mechanic that makes this safe is letting each new service earn its traffic before it gets any. You shadow it, you watch it, and you cut over only the piece that's proven. Do that and you can modernize a system taking in billions of events a day without it ever going down.

4. Twitter: replace the hottest path first

Around 2011, Twitter started moving off Ruby on Rails and onto services written in Scala and Java on the JVM. They didn't rewrite the whole product. They went after the parts where the old stack hurt the most. When they replaced the Rails search front end with a new Java service they called Blender, search latency dropped by roughly three times, and the JVM move is widely credited with helping Twitter survive the traffic spike of the 2012 US election (InfoQ, The Register).

What stands out is the order of operations. They started where the payoff was biggest and the pain was sharpest, proved the new stack there, and moved on. They didn't declare a company-wide rewrite and disappear for a year.

Matt's takeaway: When you do migrate, sequence it by value. Find the hottest, most expensive path, modernize that first, and let the early win fund and justify the rest. A modernization that delivers something in month two is one people keep believing in.

5. AMC Theatres: modernization that stays modern

AMC Theatres runs a serious .NET stack behind its ticketing, mobile apps, and loyalty programs, and Full Scale engineers work inside those teams. Their CIO, Derrick Leggett, describes it this way: "It's a fully integrated team. It's just some of the people happen to be living in the Philippines." When something huge hits, like a Taylor Swift on-sale, that team scales up fast because it already knows the system from the inside.

The modernization angle here is the one nobody puts in a case study, because it shows up later. Modernizing a system is only half the job. Somebody has to own the result for years afterward. When the people who did the work were never part of your company, the knowledge walks out the door the day the project ends. AMC's team doesn't have that problem, because the engineers who modernize the code are the same ones who keep living in it. You can read the full AMC case study for the details.

Matt's takeaway: The best modernization is the one that doesn't decay back into legacy the moment the project wraps. That depends less on the tech and more on whether the people who did it are still on your team.

6. Etsy: when the pipeline is the modernization

Etsy is a useful counterweight to everyone who thinks modernizing means rewriting. For years Etsy ran a large PHP application, and the most important thing they modernized wasn't the language. It was how they shipped. They moved to continuous deployment, automated their testing, and got to a point where they were pushing 50 or more changes to production a day (InfoQ, Etsy's own engineering blog).

That's modernization, even though almost no end-user-facing feature changed in the doing of it. The system became dramatically cheaper and safer to change, which is the thing most legacy systems actually lack. A codebase you're terrified to deploy is a legacy codebase no matter how new the framework is, and bolting a new framework on top of a scary release process just gives you scarier releases.

Matt's takeaway: Before you decide the stack is your problem, ask whether the real problem is that you can't ship small changes safely and often. Fixing the pipeline is sometimes the whole job.

7. SOTA Cloud: where AI actually earns its place

SOTA Cloud is a cloud-native dental imaging company we staff, and they came out of decades of on-premise dental software. That means a lot of legacy: old data to convert, patient records to bridge, and hardware-specific imaging workflows to support. On one piece of that work, an engineer on the team hit a proprietary dental file format that had no documentation at all, and used AI to read the format and work out its structure, the kind of problem that used to stall a project for months.

I'm careful about where I trust AI in modernization, and this is the spot where it's genuinely good. The hardest part of modernizing old software is understanding what the old software actually does, especially when nobody who wrote it is still around. AI is very good at reading, mapping, and explaining legacy code. I trust it far less to go rewrite that code on its own. The SOTA Cloud case study has more on how that team works.

Matt's takeaway: The mature use of AI in a modernization is comprehension, not autopilot. Let it help your engineers understand the old system fast. Don't hand it the keys to rebuild the system while you watch.

8. TSB Bank: the big-bang that cost £330 million

Every rule needs the example that proves it from the wrong side. In April 2018, TSB Bank, then owned by Sabadell, moved around five million customers from Lloyds' platform onto a brand-new core banking system in a single big-bang cutover. The data migration itself technically completed. Almost everything after it did not. Roughly 1.9 million customers were locked out of their accounts, online and phone banking failed for days, payments broke, and some customers could even see other people's accounts.

TSB's own 2018 annual report booked about £330 million in post-migration costs, covering customer redress, fraud, lost income, and the scramble to fix it (Computing), and regulators later fined the bank £48.65 million. The official findings are worth reading for anyone about to attempt something similar: the investigation faulted the decision to do a big-bang migration without fully understanding the risk, and the failure to assess the IT provider running it as rigorously as they would have assessed an outside firm, because it was a sister company (Computer Weekly on the fine, on the provider).

Matt's takeaway: This is the whole thesis in reverse. They flipped a core system overnight instead of carving it down first, and what failed wasn't a piece of code, it was the strategy. There's a second lesson in the findings too. Who's accountable for the work, and whether they're genuinely independent of you, is part of your modernization risk, not a side detail.

The pattern across all eight

Read all eight modernizations back to back and the line is hard to miss. The ones that replaced a system, mine included, Netflix, Twitter, moved incrementally and kept the old system running the whole way. The one that turned into a disaster, TSB, tried to switch everything on at once. The others carry their own lessons, that ownership has to stay in-house, that sometimes the pipeline is the real work, that AI's job is understanding the old code and not rewriting it, but even those sit on top of the same instinct: change a working system in small, reversible steps.

I'll be honest about the cost of doing it this way, because most case studies aren't. Running the old and new systems side by side is more expensive and slower on the calendar than a clean cutover would be, if the clean cutover worked. It usually doesn't, which is the whole point. You pay the premium of double-running to buy down the risk of a TSB. That's a trade worth making on anything you can't afford to break.

None of this is really about the technology. It's about the decisions you make before anyone writes a line of code: whether you go piece by piece or all at once, whether you understand the system you're replacing, and whether the people doing the work are going to stick around to own the result. For the failure modes specifically, we wrote up the most common reasons modernization projects fail, the deeper engineering version of the rebuild question is in software re-engineering, and for the rewrite-versus-refactor call underneath all of it, see refactor vs rewrite.

If you want a team that modernizes the way these case studies say to, incrementally, embedded in your own engineering org so the knowledge stays with you, that's what our legacy modernization services are built around.

Frequently asked questions

What are the best examples of application modernization?

The most instructive examples aren't always the most famous. Netflix moving from a monolith to microservices and Twitter shifting from Ruby on Rails to the JVM are the well-known ones, but Etsy's move to continuous deployment on an existing PHP app is just as much a modernization, and a smaller-scale one like replacing an aging core system module by module is closer to what most companies actually face. The common factor in the successful ones is an incremental approach, not a specific technology.

What makes an application modernization project succeed?

Almost every successful modernization shares the same trait: it happens incrementally, replacing one piece at a time while the existing system keeps running, rather than in a single all-at-once cutover. The teams that succeed also decide up front which parts to replace and which to leave alone, understand the business the system supports, and keep the engineers who did the work close enough to own the result afterward.

What is the most expensive application modernization failure?

One of the most documented is TSB Bank's 2018 core banking migration, which attempted a big-bang switch of around five million customer accounts and locked roughly 1.9 million of them out. It cost the bank about £330 million and led to a £48.65 million regulatory fine. The investigation pointed at the big-bang strategy and weak oversight of the provider, not a single technical bug.

Does modernization always mean rewriting the application?

No, and assuming it does is a common and expensive mistake. Modernization ranges from rehosting on new infrastructure to refactoring code to modernizing the deployment pipeline, as Etsy did, all the way up to rebuilding a component from scratch. Rewrite versus refactor isn't a whole-system, all-or-nothing choice. The strongest move is usually to blend them, rewriting the specific piece that genuinely needs it and stitching it into the existing system with the Strangler pattern, so you get the clean rebuild where it counts without betting the whole company on a single cutover.