Migrating to Azure, Stage 3: Migrating and testing

Extended support for SQL Server 2008 and SQL Server 2008 R2 ends on July 9, 2019.

After that, Microsoft will no longer provide free security updates on premises, non-security updates, free support options, and online technical content updates.

If you’re still using SQL Server 2008 and SQL Server 2008 R2, you can either update to the latest on-premises version, or you can migrate your workloads to Azure.

In a four-part series, we’re guiding you through the latter path toward Azure migration.

We already covered the first two steps: assessing your environment, where you evaluate your workloads, gather performance statistics, and measure important data to uncover your best migration options; and developing a migration strategy, where you plan for your migration by applying all the information you gathered during the assessment phase to ensure you have the smoothest migration plan possible.

Once you’ve assessed your environment and developed a migration strategy, it’s time to move on to the third stage of Azure migration: migrating and testing. Here’s how to get started.

Remediation of any migration block

In Stage 2, you planned for any potential roadblocks, including how to remediate them. Now, it’s time to address them.

Whether you do it yourself or rely on a partner depends in part on who developed the application. If it’s an internally developed application, you will have access to change the code as needed. If it’s a packaged application – an external third-party-supported application – you’ll only have the ability to lift and shift the application to the cloud.

Set a reasonable timeline for remediation and stick to it.

Perform (at least) one dry run of the migration

Once you complete the remediation, it’s time for a dry run. Perform a complete non-production migration of all of the resources and then a dry cutover. This should be an exact duplicate of how the actual migration will go.

The dry run helps you understand the following:

• The amount of time it will take to perform the migration
• Any potential issues that weren’t previously identified
• The best way(s) to adjust your timelines and expectations based on any lessons learned

The point of the dry run is to uncover any unknown issues you may have missed before you encounter those problems in a live production environment.

Perform functional and performance testing

Once you’ve made the dry run migration and cutover, put the applications through their paces for both functionality and performance.

A functional test or even a smoke test will make sure the application works at a surface level, then dive deeper into testing both the application layer and the data layer, as well as the new infrastructure the server is running on (in this case, the Azure cloud).

Performance testing will unveil whether you need more or fewer resources on your infrastructure to properly run the application – you might need to fine tune the machine configuration to support the workloads.

This testing will take the longest of the steps in Stage 3, but because you’ve done so much work up front in Stages 1 and 2, dry runs and testing should go well.

Update the plan with new insights and lessons learned

If you discover any issues during testing, and there are additional elements that need to be factored into the migration plan, add them. Take that new plan and perform another dry run to ensure everything works as expected.

For example, a dry run might help you discover additional databases in scope that weren’t realized. Or maybe you uncover application incompatibilities that you didn’t know existed that need to be remediated.

The dry runs, testing, and lessons learned are a cyclical process. For a smaller organization, one dry run might be enough. For an enterprise with more complex systems, it might take several rounds.

Finalize the cutover steps, date, and rollback plan

The cutover mimics your migration plan and your dry run. But there are some other areas you need to worry about.

Think about how to manage the downtime for the existing application and how users will learn how to access the new application if that process is different than before. You can do your best to model performance, but you won’t know for sure whether an application can handle the real world load until users gain access.

If you migrate over the weekend, make sure you have all hands on deck on Monday morning when everyone comes back to work in case you need to stop the application and roll back. Know the tolerance for rollback versus troubleshooting in place.

The goal of Stage 3

Stage 3 is obviously an important stage, but it’s also the most straightforward.

You’re out of the “unknowns,” you’re into the “knowns,” and you’re letting the experts do the testing. As long as you’ve got strong test and migration plans, you’ve greatly increased your chances for success.

Once you’ve completed migrating and testing, you’ll be ready to move into Stage 4: first day of support.

We’ll save that for the next – and final – post in our series.

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.