If you’re moving SQL Server to the cloud, you’ll be pushed fairly hard toward a platform as a service. It’s the modern answer, it’s less work, and it’s genuinely a good option for a lot of workloads.
It’s also not right for everything, and the reasons why tend not to appear in the marketing material.
What platform as a services actually give you
Azure SQL Database and AWS RDS both hand the infrastructure layer to the provider. They manage the servers, they do the patching, they handle availability, they give you some performance recommendations. You look after what’s in the database.
The reduction in work is real. If your team is small, or you have no DBA at all, that matters.
The constraints worth knowing before you commit
An Azure SQL Database tops out at four terabytes. If you need more, Hyperscale takes you to a hundred terabytes, which is a lot of data by any measure. So size is usually solvable.
The constraints that actually decide it are the other ones.
An Azure SQL Database has no SQL Agent jobs. If your environment depends on scheduled jobs, and most established environments do, that’s a significant piece of rework.
You also can’t do cross-database querying. If your application queries across databases, and plenty of applications built over years quietly do, this one decision point can rule out the platform on its own.
Neither of these is a flaw. They’re consequences of how the product is built. But you want to know about them at the design stage, not three weeks into a migration.
Managed Instance, for the middle ground
Azure SQL Managed Instance exists more or less to address that gap. It’s the closest thing in the cloud to your on-premises box: multiple databases, SQL Agent jobs, cross-database querying, all still there, while Microsoft manages the infrastructure and patching underneath.
For most organisations moving off on-premises without wanting to rewrite an application that works perfectly well, this is the practical landing spot. It doesn’t get talked about as much as it should.
Infrastructure as a service is not a failure
Then there’s the straight lift and shift. You take the machine you have and you put it on a VM: an Azure VM, or an EC2 instance in AWS, with SQL Server installed on it. For most practical purposes it behaves as it did on-premises, with some networking differences.
People sometimes treat this as the option you settle for. It isn’t. Storage capacity on VMs is enormous, you keep full control of the instance, and for certain workloads and performance requirements it remains the correct answer.
Not everything belongs on a platform service. Not everything has to stay on infrastructure. Anyone who tells you otherwise is describing their preference rather than your requirements.
How to actually decide
Start with the workload, not the platform. What does the application do, how does it use the database, what does it depend on, and what are you trying to achieve by moving?
There’s always a compromise between control, cost and how much of the maintenance you want to carry. Work out which of those matters most to you and the platform choice usually becomes obvious.
And if the answer turns out to be that you should stay where you are for now, that’s a legitimate outcome too.
—
Warwick Rudd is a Microsoft Certified Master and Data Platform MVP, and the founder of SQL Masters Consulting. We manage SQL Server across Azure, AWS, GCP and on-premises: Cloud-Agnostic Database Management
Leave a Reply