Adopting Cloud? Don’t Lift and Shift, Build Smarter with PaaS

Like many organisations, your cloud journey may have started with a lift and shift. It’s the obvious choice: pick up your servers, drop them in Azure, job done. 

But this approach often leads to hidden costs. 

Your teams are still patching servers at weekends and dealing with the same bottlenecks. They’re still throwing more VMs at performance problems. You might also be managing unfamiliar Azure costs on top of existing operational challenges.  

The truth is, lift and shift is just the beginning, not the destination. And if you’re reading this while your team is tied up with infrastructure maintenance instead of delivering value, this article might be the one for you. 

For an in-depth discussion of these topics, watch the webinar below, where experts Matt and Ryan explain all you need to know about PaaS. 

And if you prefer to read, we’ve summarised their ideas in this article. 

We see it time and time again. Companies move to the cloud thinking they’ll realise all those promised benefits, like cost savings, agility, and innovation. Instead, they end up with what Ryan Tracey, our Head of Technical Operations, calls “picking up your estate and putting it into Azure”—complete with all the operational complexity they already had. 

The reasons for defaulting to lift and shift are understandable. As Matt Dyson, one of our consultants, points out in the webinar: “I think the big thing we see why people lift and shift is, I think, to do with time.” When you’ve got a SQL server running 20 applications and bigger projects coming in, moving that server straight into Azure seems like the sensible short-term solution. 

There’s also the legacy application problem. Some companies are running systems where the vendor has gone bust, leaving them with no support and no knowledge of how to repoint databases. Others are stuck with vendors who still don’t support Azure. In these cases, lift and shift might be the only option. 

But you’ve still inherited all your existing problems. Your teams are still patching servers every month. They’re managing backups, arranging monthly downtime windows, dealing with security vulnerabilities. As Ryan puts it: “You’ve got Infrastructure Engineers trying to now maintain modern app stacks that don’t really belong to them.” 

The hidden costs mount up quickly. We regularly see incorrect SKUs, misunderstood products, and (worryingly) absent or misconfigured backups. VM sprawl leads to cost uncertainty. Every time you need to grow, you need a new virtual machine that needs to be specced, built, onboarded, and maintained constantly going forward.

So, what’s the alternative? Platform as a Service fundamentally changes how you think about infrastructure. Instead of managing entire servers for simple functions, you take just the part you need—the database, the web application, or the script—and turn that into the entire function. 

Traditionally you’d need an entire server just to run a database, another server for your website, and maybe another for scheduled tasks. With PaaS, you can have just the database without managing the SQL Server underneath it. You can run websites without maintaining web servers. Your scheduled scripts can execute without a dedicated VM sitting idle 23 hours a day. You get the functionality without the infrastructure overhead. 

What this means technically 

With traditional IaaS, you’re responsible for everything from the storage and network, through the BIOS, up to the OS, the application, then the antivirus, the patching tools: everything. You might need teams to manage each layer. If you’re doing least privilege connectivity and locking down every port (as you should be in a modern workplace), that’s even more complexity. 

With Azure as your PaaS, Microsoft handles: 

• The operating system and its patches 
• The runtime environment 
• Scaling infrastructure 
• High availability and resilience 
• Security at the infrastructure level 
• Backup capabilities (often as simple as a tick box and destination) 

Your team focuses purely on the application and customer experience. You’re not paying for an OS to exist or teams to maintain it. As Ryan notes: “Whatever the resource is now you can just have the relevant team that actually uses it operationally to look after it. You only have the DBAs interacting with the database, for example.” 

The technical benefits in practice 

Almost all PaaS services can scale up and down easily—often just by dragging a slider. There’s no OS patching or backup scripts to write. Security is inherent (though you can still benefit from tenant-wide options like Azure Defender for Cloud). 

Crucially, because it’s not a Windows VM, it’s inherently a high-availability service. It doesn’t need to be taken offline every month for patching. And if you need more compute or storage for year-end reporting that’d swamp your server for the entire day, you can scale up temporarily without planning a weekend infrastructure upgrade. 

Here’s where it gets interesting. An independent study on Azure PaaS found that companies who moved applications to PaaS achieved a 228% ROI over 15 months. That’s massive. 

But here’s the crucial point that often gets missed. As Ryan notes: “The cost of the resource almost looks the same… They may be about the same, but that isn’t where the saving comes from.” The direct Azure costs might be similar, but the total cost of ownership transforms completely. 

The study found: 

• 50% increase in application development speed 
• 40% reduction in dev-related infrastructure costs 
• Improved uptime due to inherent resiliency 

We’ve seen this ourselves. One customer saved over 20 hours of dev time weekly by switching from IaaS to PaaS: “the equivalent of giving half a developer back to the business overnight.” Another unlocked new revenue streams simply through the ability to scale up and down. 

The soft benefits are harder to calculate but equally real: fewer outages mean more revenue, and dev teams are happier and more productive when they’re not stuck patching servers or chasing log files. 

Matt brings up what we think is the perfect example of why scalability matters: Black Friday. It’s a story that plays out every year across the retail sector. 

In the traditional IaaS world, IT teams have to get servers built weeks before, getting them all connected and set up. You’re essentially building infrastructure for one day of peak traffic, which then sits underutilised for the rest of the year. You’re paying for that capacity whether you need it or not. 

With PaaS, you can scale your resources up by 10x for that single day of peak traffic, then scale back down immediately afterwards. The effort behind this compared to traditional scaling is minimal. No weekend work building new servers, no complex load balancer configurations, no bringing in additional teams. 

You sometimes see websites on a Black Friday or other sale day that just don’t work. If you have auto-scale on, surely more customers = more money? Yet we still see major retailers’ sites crashing on their most important shopping days of the year. We’re talking about billion pound companies who haven’t managed to prepare the right infrastructure. 

Ryan shared another example: a customer recently needed more compute because everyone was going to be online running heavy CPU tasks. The solution? “We just reduced the amount of people per box and gave more boxes overnight. 25% that was it. It was within 30 minutes of clicking go, and the boxes were ready.” 

“But our developers don’t know PaaS” 

This is one of the more common objections, and it’s understandable. Yes, it’s new technology. Yes, there’s a learning curve. Your developers might be comfortable with their current setup, even if it means logging onto servers and manually deploying code. 

But as Matt points out, once developers get around it and realise it opens the door to all these “nice, new, shiny things”, they tend to get on board quickly. We’re talking about modern deployment pipelines, automated scaling, and the ability to focus on code rather than infrastructure. 

Modernising your platform can even increase staff retention. People want to progress, to feel like they’re doing something new. Few dream of spending their career patching servers or logging in at 9pm to test in production because there’s no proper dev environment. 

Organisations that settle for lift and shift often struggle with change in general. If a company resists modernisation from day one of their cloud journey, that resistance tends to persist. So moving to PaaS is an operational and organisational change as much as a technical one. 

“What about our legacy applications?” 

This is a real challenge. Some vendors still don’t support Azure (yes, really, in 2025). Some applications come from companies that no longer exist, leaving you with no documentation and no idea how to repoint connection strings. 

There are some situations where there’s nothing else you can do. If you’ve got 500 staff using a business-critical application and moving away is a three-year project, lift and shift might be your only option for now. 

But these edge cases shouldn’t hold back the rest of your estate. For everything else, you can run readiness tools to see what’s compatible. You might find that database you thought was too complex to move actually transitions smoothly to Azure SQL Database, for example. 

Matt also raises an important point about timing: when operating systems or apps reach end-of-life, companies do mandatory migration work anyway. Rather than simply moving to a newer version of the same setup, this presents a perfect opportunity to modernise. If you’re going to do the work anyway, why not move to PaaS and gain all the benefits? 

The beauty of PaaS is you don’t need to go all the way up-front. As Ryan emphasises: “You don’t have to go all in to get the value. PaaS works brilliantly alongside existing IaaS workloads.” 

So start with the easy wins: 

1. Web apps – One of the easiest to just move. If you’re running a standard web app on IIS with a SQL backend, moving to Azure App Service is often straightforward. You can potentially just copy your code over without changing anything. 
2. SQL databases – Run readiness tools to find compatible databases. Azure SQL comes in many flavours, from the fully abstracted Azure SQL Database to Managed Instance (which Ryan notes is “still technically PaaS” but “is a Windows server running SQL”—giving you more compatibility for legacy features). 
3. Scheduled jobs – Replace that server where a user logs in every day at 9am to run a specific task with Azure Functions or Logic Apps. These tiny, abstracted services can run your scripts without the overhead of an entire server. 

Matt suggests an even simpler starting point: Azure Files to replace traditional file servers. It’s built on premium SSD disks with excellent performance; a nice, simple move to get familiar with PaaS concepts. 

The key is starting small. You can make the tiniest, smallest database with the tiniest amount of compute and storage that you need to just prove the concept. Once your team sees the benefits (no more patching, automatic backups, easy scaling) they’ll want to move more. 

Consider starting with development databases. Get your developers familiar with the platform where the stakes are lower. Once people get one or two up and running, it gives them the confidence to look at moving the entire workloads over. 

PaaS isn’t just a tech shift, it’s an operating model shift. 

Yes, you do save money and reduce patching windows. But you also get to free your teams to deliver more, faster, with less operational drag. You move from owning everything to consuming cloud-native services. It’s about enabling platform engineering, automation, and DevOps best practices. 

It’s well-explained with the Pets versus cattle analogy. Your legacy servers are pets—you have to look after them with expert care, take them to the vet every month (patching), and worry about their individual health. But in a PaaS world, your infrastructure is cattle. Resources spin up when needed, do their job, and spin down. If one has issues, you replace it. No emotional attachment, no manual intervention. 

The companies with websites crashing on Black Friday haven’t made the shift yet. But PaaS is about to overtake IaaS spend in the cloud for the first time. The momentum is building. 

If you’ve already lifted and shifted, don’t despair. The best time to start optimising your cloud strategy is before you begin migrating to the cloud. But the second-best time to start modernising is now. 

Start small. Pick one web app, one database, one scheduled job. Build momentum. Show the value. Get the right partner who’s done this before: this might be your first time, but for the right cloud partner, it’s a once-a-month task. 

Because lift and shift might get you to the cloud, but PaaS gets you the benefits everyone’s been promising. The 228% ROI and 50% faster development. The ability to scale for big events without breaking a sweat. And the teams who can focus on innovation instead of infrastructure. 

Ready to explore how PaaS could transform your Azure environment? The Synextra team can help you identify the quick wins in your estate. Get in touch to start the conversation.