Migrating to Azure, Stage 2: Developing your migration strategy

Here’s a friendly reminder: The end of extended support for SQL Server 2008 and SQL Server 2008 R2 is rapidly approaching.

After July 9, 2019, Microsoft will cease to provide free security updates on-premises, non-security updates, free support options, and online technical content updates. For Microsoft customers still using SQL Server 2008 and SQL Server 2008 R2, you have a couple options.

You can either update to the latest on-premises version, or you can migrate your workloads to Azure cloud.

In a four-part series, we’re guiding you through the latter path toward Azure migration. We already covered the first step, assessing your environment, where you evaluate your workloads, gather performance statistics, and measure important data to uncover your best migration options.

Once you’ve assessed your environment, it’s time to move on to the second part of Azure migration: developing your migration strategy. Here’s how to get started.

Build out a customized migration plan

The first step is developing a customized migration plan using an application-centric approach. This will allow you to understand each application’s individual and unique requirements, and help you determine what to prioritize. You see, moving data is easy. The hard part is making applications work after the move.

For example, after performing the assessment phase for one of our customers, we found a lot of features and workload characteristics that would impede migration into Azure SQL Database. The level of effort required to re-write that portion of code would be too great.

However, those features were compatible with migrating into an Azure SQL Managed Instance. So we changed our strategy. Instead of moving that code into Azure SQL Database, we chose to migrate to Azure SQL Managed Instance, which allowed the customer to migrate over with no downtime.

There are certain workload characteristics – needing to query multiple databases, for example – that might prevent you from moving into Azure SQL Database because some feature sets either aren’t supported or only work part of the time.

You need to determine what makes the most sense for your organization. Do you want to invest the time to remediate the code so you can proceed with your original plan, or are you better off looking at an alternative migration option? Building out a customized migration plan allows you to determine how you want to go ahead and what migration components to prioritize.

Build out a reference end-state architecture

Once you have the migration plan in place, you need to map out a blueprint of the end state of the migration.

This reference end-state architecture takes everything you learned from the assessment phase and applies it to your future architecture. Some of the things you need to factor in include:

• Network design
• Access controls and requirements
• Unique high availability disaster recovery (HADR)
• Backup strategies

While our four-stage migration infographic refers to this step as a “diagram,” it is much more in depth than just drawing lines. The end-state reference architecture reflects your unique application and instance requirements in a complete architecture.

Plan for any migration blocks and add remediation efforts

Unfortunately, creating a customized end-state architecture doesn’t guarantee everything’s going to go as planned.

Common migration blocks include:

• Lack of an adequate test plan
• Lack of access to necessary internal resources
• Lack of access to application SMEs
• Limited uptime – lack of available maintenance windows for applications
• Level of effort – some organizations aren’t willing to take the time to do the job right (e.g., if it takes six months to rewrite a certain portion of code, stakeholders might not sign off on it)

You need to plan for any migration blocks and add remediation efforts to the migration phase to prepare for any potential mishaps.

For example, let’s say you have deprecated data types that don’t work in the new version of SQL Server syntax. As part of the migration strategy, you’ll have to employ some level of remediation to modernize, even if it means revisiting many of your stored procedures and making changes to avoid future performance issues.

Create required objects

Once you’ve defined the end state and taken steps to mitigate potential migration blocks, it’s time to stand up the infrastructure needed to support your cloud migration.

Whether it’s VMs or a managed instance or Azure SQL Database, building what you need in the cloud is the final step in this stage.

The goal of the second stage

While the assessment stage is arguably the most important step, the second stage – planning – is the second most important.

Developing a migration strategy is about applying all the information you gathered during the assessment to ensure you have as smooth a migration plan as possible.

Once you’ve completed your strategy, you’ll be ready to move into Stage 3: migrate and test.

We’ll save that for the next post.

In the meantime, take a look at the full migration plan in our infographic to understand where you should be in the migration process and what our next post will cover.

If you have any questions about migrating to the Azure cloud, contact your SHI account executive.