When companies start discussing SQL Server workload placement, the conversation often begins with the platform. Should the workload move to Azure? Would Azure SQL Managed Instance be a better fit? Should the database stay on-premises for another few years, or would that simply postpone an inevitable migration?
Those are reasonable questions, but in my experience they often come too early.
Before I can say anything useful about the target platform, I first need to understand the workload itself. What does the application depend on? How is it operated today? Where does the data need to be located? Which availability and recovery requirements exist? And, perhaps most importantly, what problem is the company actually trying to solve by changing the platform?
Moving a SQL Server workload to the cloud is not modernization by itself. At the same time, keeping it on-premises does not automatically mean that an environment is outdated. The useful discussion starts somewhere else: with the workload, its dependencies and the operating model around it.
SQL Server workload placement starts with the reason for change
A migration project is much easier to evaluate when there is a clear reason behind it. Maybe the existing hardware is approaching end of life, the infrastructure team wants to reduce the amount of hardware it operates itself, or the current platform no longer provides the flexibility or availability the business needs. Those are concrete problems a team can measure and discuss.
The situation becomes much harder when the starting point is simply that an existing SQL Server runs on-premises and therefore appears to require modernization. If the current operating model is stable, understood and economically reasonable, moving the workload somewhere else does not automatically make it better.
This is also why discussions about cloud adoption sometimes become more complicated than expected. Microsoft recently asked partners what keeps customers from migrating SQL Server workloads to Azure. There are many possible answers to that question, but from my perspective there is an even more useful one to ask first: would migration solve a problem that actually matters to this customer?
Without that context, technical feasibility only tells part of the story. Microsoft maintains a useful overview of the different Azure SQL deployment options, but choosing between them only becomes meaningful once the workload requirements are clear.
A SQL Server database rarely exists on its own
Looking only at the database engine can make a migration appear simpler than it really is. The instance may use supported features, its size may be manageable, and an assessment may show no major blockers for Azure SQL Managed Instance, Azure SQL Database or a SQL Server virtual machine.
That is useful information, but the database is usually only one part of the workload.
Applications may depend on other systems in the same network. Jobs may access local file shares. Reporting systems may read from several nearby data sources. Third-party software may require a particular SQL Server version, authentication model or operating system configuration. Monitoring, backup, administrative tooling and support processes may have grown around the current environment over many years.
None of these dependencies automatically prevents a migration. They simply change the question. Instead of asking only whether the database can be moved, I want to understand what happens to everything around it if we do. Sometimes that leads to the conclusion that the database and the surrounding application stack should move together. In other cases it exposes dependencies that make a staged or hybrid approach more sensible.
This is also why I treat migration planning as an architectural and operational exercise rather than only a database move. The same principle is part of my SQL Server migration and platform consulting: the target platform should fit the workload, its dependencies and the way the environment will operate afterwards.
Latency and data movement can change the decision
Latency and data movement are good examples. An application and its SQL Server database may work perfectly well when both are located in the same data center. If only the database moves to Azure while the application and several dependent systems remain on-premises, that relationship changes.
For some workloads this barely matters. Others perform a large number of small synchronous database calls and react badly to additional network latency. Large or frequent data transfers can create another dependency on the network architecture, especially if systems continue to exchange substantial amounts of data between on-premises infrastructure and Azure.
The point is not that these workloads should not move. The point is that the database cannot be evaluated in isolation.
Availability and recovery still need to be designed
Cloud platforms can make some availability scenarios considerably easier to implement and operate. Managed database services can also remove infrastructure responsibilities that would otherwise remain with an internal team.
That can be a very real benefit, but it does not remove the need to understand the actual requirement. How much downtime can the business tolerate? How much data can it afford to lose? What happens when an entire region becomes unavailable? How does the application reconnect after a failure, and who is responsible for testing the recovery process?
These questions exist regardless of whether SQL Server runs in a local data center, in an Azure virtual machine or on a managed database platform. The available technical options change, but the business requirement does not disappear.
The same is true for backup and recovery. Automated backups and managed infrastructure reduce operational work, but the organization still needs to know what it has to restore, how quickly the service needs to be available again and whether the selected platform can actually meet that requirement.
A platform can simplify the implementation. It cannot define the requirement for you.
The operating model matters in SQL Server workload placement
One of the strongest arguments for moving a workload to a managed service is not that the database will run in Azure. It is that the responsibility model changes.
With a traditional SQL Server installation, someone has to operate the operating system, storage, patching, backups, monitoring, SQL Server configuration and the infrastructure underneath it. Depending on the architecture, high availability and disaster recovery add another layer of work.
A managed service can remove part of that responsibility. Azure SQL Database moves much more of the infrastructure and platform operation to Microsoft. Azure SQL Managed Instance keeps more SQL Server compatibility while still reducing a substantial amount of platform administration. A SQL Server running in an Azure virtual machine, on the other hand, leaves many of the familiar responsibilities with the customer.
That distinction is far more useful than simply comparing “cloud” with “on-premises”. If an organization is struggling because it no longer wants to maintain database infrastructure, then reducing operational responsibility can be a very good reason to move. If the same organization takes an existing SQL Server virtual machine and recreates almost the same architecture in Azure, the operating model may change much less than expected.
That does not make the migration wrong. It just means the benefit has to come from somewhere else.
Existing skills and operational capacity matter
The existing team also matters. A company with experienced infrastructure and SQL Server staff may already have mature processes for patching, monitoring, backup, recovery and high availability. In that environment, keeping certain workloads on-premises can remain predictable and economically reasonable.
Another company may be in the opposite situation. Hardware maintenance, Windows patching and SQL Server administration may depend on a very small team that is already overloaded. There, reducing the amount of infrastructure the organization has to operate can be far more valuable than preserving an existing architecture.
The same workload can therefore lead to different platform decisions in different organizations. This is also why monitoring alone is not enough to judge whether an environment needs a platform change. I discussed that distinction in more detail in SQL Server Monitoring Is Not Diagnosis.
Governance and cost need the same level of detail
Data sovereignty, compliance and governance are frequently mentioned in cloud discussions, but they are only useful decision criteria when they are made specific. Which data is affected? Which regulation, contract or internal policy applies? Where may the organization store the data? Who may administer the platform? Which audit evidence does the organization need?
Once the organization answers those questions, it can evaluate the available options properly. For many workloads, Azure can meet demanding compliance and governance requirements. In other cases, contractual obligations, internal policies or dependencies on other systems still influence where the workload can reasonably run.
“Compliance” should therefore neither be used as a vague argument against cloud adoption nor dismissed as simple resistance to change. It is a requirement that needs the same level of clarification as any other.
Cost needs to reflect the actual operating model
Cost deserves the same treatment. A simple comparison between server hardware and a monthly Azure estimate is rarely sufficient.
An on-premises SQL Server has hardware, storage, licensing, backup, power, cooling, lifecycle and operational costs. Azure has compute, storage, backup, networking and service costs, and the licensing model depends heavily on the chosen architecture and on existing entitlements.
The difficulty is that some costs are highly visible while others already sit inside existing infrastructure and teams. A company with available virtualization capacity, experienced staff and established processes will calculate very differently from an organization facing a large hardware refresh and lacking the people to operate the platform properly.
That is why generic statements about one model always being cheaper than the other are rarely useful. A meaningful comparison has to describe the actual environment before the change and the operating model that will exist afterwards.
Hybrid can be a deliberate workload placement decision
Another assumption I would question is that a hybrid architecture is always an intermediate state. Sometimes it is. A company may move workloads in stages and gradually reduce its local infrastructure.
But there are also environments where different workloads simply have different requirements. A relatively independent application might be an excellent candidate for Azure SQL Database. Another workload may fit Azure SQL Managed Instance because it still depends on SQL Server features that make Azure SQL Database impractical. A third system may remain on-premises because it has strong local dependencies or because moving it currently produces no meaningful operational benefit.
That is not necessarily an unfinished migration. It can simply be the result of treating workloads individually instead of forcing every database into the same target architecture.
Microsoft’s SQL Server migration documentation reflects that broader range of options as well, covering both on-premises SQL Server targets and Azure SQL destinations rather than treating migration as a single predefined path.
For me, that is usually the more useful way to think about modernization.
I do not consider the physical location of SQL Server to be a meaningful measure of how modern an environment is. I have seen well-operated on-premises systems with clear responsibilities, tested recovery procedures, appropriate monitoring and sensible lifecycle management. And an environment does not become well designed simply because the same problems now run on infrastructure hosted somewhere else.
A modernization project should improve something that matters. It may reduce operational responsibility, improve recovery capabilities, remove aging infrastructure, make scaling easier or allow the application architecture to evolve. Azure SQL can be a very good answer to those requirements.
In other situations, modernizing the existing SQL Server platform on-premises may be the more sensible next step. Quite often, the answer will be a combination of both.
The platform decision becomes much easier once the order of the questions is right.
Understand the workload, its dependencies and the operating model first. Then decide where it should run.
Foto von Alexander auf Unsplash
