Should You Modernise Your Apps? A Guide to Making the Right Choice 

So you’ve got some ageing applications running on IIS, sitting on a single server. Maybe it’s your internal mortgage processing system or a custom CRM built years ago (that only three people understand). They’ve been chugging along for years, and they work fine. Mostly. 

But “it works” isn’t good enough anymore. Not when your competitors are deploying changes multiple times a day while you’re scheduling weekend maintenance windows. And not when a single OS update could take down half your business functions because everything’s running on the same box. 

So when should you modernise them? And when should you just retire them altogether? These are the questions we tackled in our latest Experts in Polo Shirts podcast episode, where Synextra’s Principal Architect Elliott Leighton-Woodruff and Azure Consultant Matt Dyson had a frank discussion about app modernisation. 

You can watch the full video below for all the details, but if you want the key insights, read on. 

At its core, app modernisation means re-architecting your applications to be more scalable, resilient, and cost-efficient. It’s about moving from that monolithic style, where your front end, middleware, and SQL database all sit together, to a world where components are separated and optimised. 

Think of it like this: instead of having one massive server doing everything (and probably not doing any of it particularly efficiently), you split things out. Your web front end becomes a web app. Your worker processes become function apps, and your database moves to SQL PaaS. Each component can now scale independently, fail gracefully, and be updated without affecting the others. 

The benefits are pretty fantastic. No more taking down ten applications just to patch one. No more pre-Black Friday panic as infrastructure teams scramble to add capacity. With properly modernised apps, scaling becomes automatic. We’ve seen companies like ASOS investing heavily in modernisation specifically to reduce failed baskets and improve conversion rates. We’re talking millions in recovered revenue. 

And even for smaller companies it can certainly be worth the cost. 

Modernisation doesn’t mean everything needs to become a cutting-edge microservice, though. There’s a spectrum of options, and choosing the right one starts with asking the right questions. 

First stop: Can it be SaaS? As the guys pointed out in the podcast, Exchange Online is the perfect example. Nobody wants to manage email infrastructure anymore. If someone else can handle it better and cheaper, why not let them? 

Next: Can it be PaaS? This is where the real modernisation happens. Platform-as-a-Service offerings like Azure Web Apps, Function Apps, and SQL Managed Instance give you the benefits of the cloud without the overhead of managing infrastructure. Microsoft even provides assessment tools that can tell you if your IIS application can migrate straight to a web app. 

Last resort: VMs. If you’ve got that “crusty, horrible, old legal application that only works on Server 2008” (who doesn’t?), then fine, put it on a VM. But as Matt and Elliott stress, if you’re choosing VMs just because you’ve got virtual machine skills in house, you’re missing the point entirely. 

The technology is often the easy part. The real challenges? They’re human. 

There can be a pretty massive shift in skills required when you update things. IT pros that are comfortable with logging onto a Windows box and managing IIS might suddenly find themselves needing to understand Git, pipelines, and deployment slots. Developers who’ve been copying files to network shares for deployment suddenly need to embrace CI/CD pipelines and branching strategies. 

Then there’s the cultural resistance. “It works on my machine” doesn’t cut it when you’re deploying to multiple environments. The old way of doing things, where you could just log onto a VM and make a quick fix, seems faster in the moment. But as Elliott points out, some companies are now pushing multiple changes to production daily. Try doing that with manual VM updates. 

Perhaps the biggest trap is the “we’ll modernise it later” mentality. Companies facing data centre exits or end-of-life equipment often just lift and shift their VMs to Azure, promising to modernise afterwards. “That won’t work,” Elliott warns. “You’ve moved this VM, it’s costing you £400 a month… No one’s ever going to spend the money.” 

Poor design is probably the easiest mistake to make. The “we’ll fix it later” approach almost never works. Once something’s in production, nobody’s taking it offline for a redesign. 

The key is establishing patterns upfront. As Elliott suggests: “Come up with what your golden pattern is. We deliver this type of application on these services, and it looks like this.” When everyone agrees on secure, manageable, maintainable patterns, deploying application five, six, or seven becomes straightforward. 

But beware of over-fragmentation. You can end up with scenarios where developers create 40 different function apps that all call each other, actually making response times worse. The latency between all these services can kill performance. This is where tools like Application Insights become invaluable, showing you exactly where your bottlenecks are. 

Cost is another consideration that catches people out. A single VM might cost £120 per month. Split that into a web app (£35), SQL PaaS (£20), function apps (£40), add development and test environments, pipelines, and ADO agents, and suddenly you’re spending more than before. The key is to be smart about it: share databases where appropriate, use pooled agents across pipelines, and remember that the operational savings often offset the Azure costs. 

“Every business is a tech business,” as Elliott notes, and attracting the right talent matters. Try recruiting top developers by showing them your Server 2012 R2 box running IIS! Modern developers want to work with modern tools: container instances, API management gateways, React frontends, and so on. 

But it’s not just about recruitment. The shift from IT ops to DevOps requires everyone to level up. Infrastructure teams need to provide platforms, not just servers. And while developers shouldn’t have to shoulder all the responsibility for security and cost (not fair when they’re already juggling multiple programming languages and delivery pressures), they will need to embrace version control, automated testing, and continuous deployment. It involves shared responsibility, with platform teams handling security and cost optimisation while developers focus on delivering great code. 

Thankfully, this makes everyone’s job more interesting. Many IT professionals who’ve been managing VMs for years are eager to work with newer, more engaging technologies. The shift to cloud-native tools isn’t just about efficiency; it’s about keeping your team motivated and your skills relevant. 

Sometimes modernisation isn’t the answer. Retirement is. 

The guys mention a crucial insight about the “5 Rs” of migration, with “retire” and “repurchase” being seriously underconsidered options. How often have development teams spent months building a custom application when a £100-per-month SaaS alternative exists? 

“Internal cost always gets missed,” Elliott observes. Ten developers on £50k+ salaries working for a year? That’s half a million pounds. You could have hired specialists who’ve done it a hundred times before and had it done in a month. 

For applications that do need modernising, sometimes starting fresh is better than trying to retrofit old code. That PowerShell script with 20,000 lines running in a function app? Or the app still using .NET Framework 4.1? At some point, you need to accept that rewriting is faster and cheaper than modernising. 

How do you know if your modernisation has succeeded? It’s not just about whether you’ve matched the projected costs, though that is important. 

Look at deployment frequency. If your development team previously waited two weeks for a change window and now deploys in two days, that’s massive value, even if it’s hard to quantify exactly. 

Measure downtime. Can you now fail over to a second region seamlessly? Has your RTO gone from hours to seconds? With Traffic Manager now offering 100% SLA, true zero-downtime deployments are possible. 

For businesses with direct sales, the metrics are clearer. Has site responsiveness improved? Are fewer baskets being abandoned? Can you handle Black Friday traffic without manual intervention? 

Most importantly, what are the business outcomes? If you’re a mortgage processor, can you now handle more applications? If you’re in retail, have conversions improved? The technology should serve the business, not the other way round. 

Throughout the wide-ranging discussion, some clear themes emerge about app modernisation: 

Start with business outcomes, not technology. What does the service do? What do you need it to do? How available does it need to be? You don’t need the most expensive, best system in the world. Sometimes you need something that’s only used four days a week. 

Get the foundations right before migrating. How will you manage code? What’s your branching strategy? How will you handle deployments? Until you understand how you’ll run things day-to-day, don’t move anything. 

Consider your total cost, including internal time. That “free” internal development isn’t free when you factor in salaries. Sometimes buying off-the-shelf or hiring specialists is far more cost-effective. 

Accept that some apps should die. Not every legacy application deserves modernisation. Some should be retired, others replaced with SaaS alternatives. Be honest about what’s worth saving. 

While it would be nice if your modernisation was a five-week project, that’s probably a bit optimistic. You’re likely dealing with a fundamental shift in how you build, deploy, and maintain applications. It requires new skills, new processes, and often, new thinking. But for organisations willing to do it properly, the rewards in agility, reliability, and ultimately competitive advantage, are substantial. 

At Synextra, we’ve guided numerous organisations through their modernisation journeys. Whether you’re looking to modernise existing applications or need guidance on your cloud strategy, get in touch: we’re here to help.