A couple months ago, Microsoft pulled the support plug on SQL 2008 – the database version that brought us enhanced data mirroring, transact-SQL debugging and multi-server query capabilities. For many organizations, SQL 2008 has been the workhorse under a multitude of applications, warehouses, and reports. These assets are critical to both ongoing operations of the business as well as for future insights and data mining. Continuing to run on 2008 is not an option due to security and compliance concerns and upgrading is risky and costly due to the amount of testing and refactoring that must occur at the application level.
So, what is one to do?
Fortunately, you have options that can address the specific needs and constraints of your current SQL estate, dependent applications portfolios and the data stored in those databases. Regardless of your target infrastructure of choice (Microsoft Azure and Azure Stack Cloud, Dell Azure Stack HCI, the Dell Ready Solutions for Microsoft SQL, your existing cloud or physical Infrastructure) for SQL 2008, Microsoft has provided four pathways forward.
Pathway 1: Migrate to Azure
Microsoft’s first option is to migrate your SQL workloads and dependent applications to Azure Public Cloud. In Azure, you can migrate your workloads or database to a 2008 Azure SQL service or a SQL 2008 instance running on an Azure IaaS virtual machine(s). In both cases your data will reside in the public cloud. In Azure, Microsoft will extend your support of SQL 2008 instance for 3 more years.
Pathway 2: Migrate to Azure Stack
Microsoft’s second option is to migrate your SQL workloads and dependent applications to an on-premises SQL service running on Azure Stack Cloud. With this option, your data continues to reside in your existing datacenter. Like migration to Azure, Microsoft will extend your support of SQL 2008 instance for 3 more years. With Azure Stack combined with Azure, organizations can take advantage of a true hybrid cloud. (See my colleague Matt Liebowitz’s blog about Dell Cloud for Microsoft Azure Stack for more information.)
Pathway 3: Migrate to a Supported Version On-Prem Using Compatibility Mode
Like previous E.O.S. announcement, Microsoft is continuing to support running a 2008 SQL database in compatibility mode on a supported version of SQL (like 2016 or 2019). In this option, you migrate just the databases and schemas to a supported SQL instance. Compatibility mode enables organizations to run back-rev version of SQL on a modern platform.
Pathway 4: Modernize/Upgrade to a Supported Version
As always, many organizations take advantage of the E.O.S. event to modernize their SQL estate. In this option, the databases are upgraded to the new version so that they can leverage all the new features and capabilities of the modern platform.
There is rarely one option that is suitable for all workloads and applications running in your data center. Concerns regarding data gravity, compliance, cloud-first initiatives, and data center modernization efforts are all factors that contribute to the complexity of a migration. Additionally, these requirements can dictate the best (or only) pathway forward. Moreover, and before making investments in migrating and/or modernizing your SQL estate, organizations should understand the application portfolio, dependencies, and the lifecycle stage of each application being migrated. This data helps prevents wasted efforts migrating and modernizing SQL workloads and dependent applications.
Migration Approach Option 1: As-a-Workload
Now that you’ve determined what to move and where to move it to, you need to consider your migration approach. There are two migration approaches to consider, namely as-a-workload and as-a-database. As-a-workload is the simpler approach. In this approach, a server or cluster of servers is the atomic migration unit. During a migration, the server(s), all database instances, and all databases are migrated as a single unit, or workload. Configurations, schemas, and version are all migrated like-for-like minimizing risk of configuration and integration issues in the new target. For example, a single cluster may house multiple database instances and each instance hosting multiple databases. In an as-a-workload migration, all the instances and databases are moved as a single package. This approach works very well when migrating SQL 2008 databases to either Azure or Azure Stack as outlined above.
Migration Approach Option 2: As-a-Database
In the second approach, or as-a-database, the databases and database instances are the atomic migration unit. In this model you can consolidate and/or split workloads as part of the migration. Migration planning is based on applications and their known dependencies. For example, an application may have 3 databases instances running to support base application data as well as integration and reporting services, during the migration, you can move the application data separately from the reporting and integration services. You can also split at the database level spreading an application’s data across two or more instances if needed for performance.
Summary
Which migration approach will you choose to modernize your SQL estate?
As mentioned above, both technical approaches are also needed during the modernization of the SQL estate. Dell Technologies has created a portfolio of ProConsult services specifically packaged to help our customers address their SQL 2008 (and Windows Server 2008) E.O.S challenges and accelerate time-to-value of their new public or on-premises SQL cloud investments.
To learn more about modernizing SQL Server, check out Rob Sonder’s InFocus blog series here.
To learn more about an Azure Hybrid Cloud Infrastructure, I invite you to watch this brief video which provides an overview of how Dell Technologies Consulting Services can help you build your Azure Hybrid Cloud for both Microsoft and VMware workloads.
