Should we move our end of life (EOL) SQL Servers to Azure?

In-Depth Answer

The cost elements we often see considered when keeping an end of life (EOL) SQL Server “as-is” and on-premises include:

• Likelihood of a hack – for example, SQL Server 2012 has a single security update (3 patches) since going EOL
• Potential cost of re-buying licenses (with Software Assurance – aka SA) or subscriptions
• Cost of paying the “security patch tax” (called Extended Security Updates – aka ESU)
• Technology required to isolate and insulate the system behind the firewall(s)
• Impact to cyber insurance if a system is isolated and insulated but remains unpatched
• Team skills and availability to perform an upgrade, migration or establish security controls
• Availability and costs associated with upgrading or replacing the entire system

At the same time, moving and running a system in Azure has a separate set of cost elements to consider:

• Potential cost of re-buying licenses (with Software Assurance – aka SA) or subscriptions
• Azure cost measurements including storage, compute, egress and more
• Consulting or employee time to build an execute a migration plan
• More than just the SQL Server migrates – often one instance has 6-10 additional Windows servers
• Planning cost models for short-term (PAYG) vs. long-term (Savings Plan) subscription approaches
• Hosting the application with another cloud provider (e.g. AWS) and connecting to Azure
• Optimizing before, or shortly after, moving to Azure vs. taking on-premises resource allocations

In general, keeping systems on-premises has more risk, while moving to Azure brings more cost.

Remend recommends having a licensing plan that enables both models with an aim to keep costs contained.