Modernizing Microsoft SQL Server: Choosing the right path with Red Hat

Modernization is often presented as a destination: Move an application to containers, adopt Kubernetes, and become cloud-native. Reality and appetite are usually more nuanced than that. They start with existing infrastructure, business-critical databases, established processes and applications that cannot all be transformed at once. For Microsoft SQL Server customers, this means modernization is rarely a single technical decision. An organisation might choose to run SQL Server directly on Red Hat Enterprise Linux (RHEL), migrate its existing SQL Server virtual machines (VMs) to Red Hat OpenShift Virtualization, or deploy containerised SQL Server workloads on Red Hat OpenShift.

Each route solves a different problem. They do not have to be treated as competing or mutually exclusive choices. In other words, you don’t need to commit to a single option. Exploring one option doesn't lock you in forever, and you can iterate through them depending on where you are in the customer journey.

Path 1: Run SQL Server directly on Red Hat Enterprise Linux

For organisations that want to retain a traditional server-based deployment model while moving away from Windows Server, SQL Server can run directly on RHEL.

This is primarily an operating system modernization path. The SQL Server workload remains familiar, while RHEL provides a supported enterprise Linux foundation. Microsoft supports production SQL Server deployments on RHEL, with support options available for enterprise database environments. 

This approach may suit organisations that want to standardize more of their infrastructure on Linux without introducing a Kubernetes platform.

Path 2: Move existing SQL Server VMs to OpenShift Virtualization

Many organisations have substantial SQL Server estates running in VMs. These databases may be connected to legacy applications and availability requirements that have developed over the years.

OpenShift Virtualization allows organisations to create, deploy, and manage VMs through OpenShift while running alongside containerised applications on the same platform. This creates a practical first step for customers that want to modernize their infrastructure without immediately changing the way SQL Server itself is packaged and operated.

Once the VMs are running on OpenShift, the customer can decide how far they want to take the modernization process. Some databases may remain in VMs permanently. Others may later be suitable for migration to RHEL or containers.

The important point is that moving to OpenShift Virtualization does not force every workload through the same transformation at the same time.

Path 3: Run containerized SQL Server on OpenShift

For organizations ready to adopt a container-based operating model, SQL Server on Linux can also run in containers managed by OpenShift. This is the more cloud-native model. SQL Server runs in containers or pods, while OpenShift provides the underlying platform for deployment, security, and lifecycle management.

However, running a database in containers involves more than simply placing SQL Server inside a container image. Production database environments also need to address high availability, persistent data, configuration, networking, security, lifecycle management, and failover. This is where an operator can help translate database-specific operational requirements into Kube-native automation.

DH2i’s DxOperator is designed to automate the lifecycle of Microsoft SQL Server Always On Availability Groups in Kubernetes environments. It can deploy and configure SQL Server containers and their availability groups, while DxEnterprise provides the underlying clustering and high-availability capabilities. DxOperator is certified for OpenShift and is identified by Microsoft as the preferred SQL Server operator for Kubernetes deployments.

This route is therefore most relevant when the customer is not only moving SQL Server onto OpenShift, but specifically wants to operate SQL Server as a containerized workload with a Kubernetes-native deployment and availability model.

Modernize at the pace of the workload

The appropriate route depends on factors that include but are not limited to:

• Architecture and age of the application
• Size and complexity of the existing SQL Server estate
• High-availability and recovery requirements
• Current Linux, virtualisation, and Kubernetes skills
• Licensing and total cost considerations
• Organisation’s appetite for operational change
• Time available for migration

This is why virtualisation can be an important part of the modernization story rather than an alternative to it. By moving existing SQL Server VMs to OpenShift Virtualization, an organisation can begin consolidating workloads onto a common application platform without waiting for every application to be redesigned. Containerisation can then be evaluated workload by workload.

A platform for today’s workloads and tomorrow’s options

When people talk about running SQL Server on OpenShift, they often talk as though there is one obvious architecture and one obvious migration path. Modernizing SQL Server does not have to be an all-or-nothing transformation.

RHEL provides a supported Linux foundation for SQL Server. OpenShift Virtualization provides a route for migrating and managing existing SQL Server VMs. OpenShift and DH2i provide a supported path for organisations ready to operate highly available SQL Server workloads in containers. Together, these options allow customers to choose an appropriate starting point while retaining flexibility for the future.

Some organizations may move directly to containers. Others may begin with VMs and modernize selected workloads later. Some may decide that running SQL Server directly on RHEL is the right long-term architecture. A question for customers is less about how do we move SQL Server to containers, but “what is the customer running today, and what problem are they trying to solve?”

A customer looking to reduce dependence on Windows Server may be exploring SQL Server on RHEL.

Another customer facing an urgent virtualisation migration may need to move existing SQL Server VMs to OpenShift Virtualization while preserving the current database architecture.

Customers that are already operating applications through Kubernetes may be ready to deploy SQL Server containers on OpenShift and use DxOperator to automate availability group operations.

In each case, the technology should follow the customer’s requirements. Start those conversations with your customers today, explore the DH2i operator on the Red Hat Ecosystem Catalog, check out SQL Server on Red Hat ecosystem catalog, or reach out to your local Red Hat team to learn more about Red Hat Enterprise Linux and Red Hat OpenShift.