1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Azure SQL - Designing and Implementing a Migration Plan

Migration Scenarios

Migration Scenarios
Overview
Difficulty
Intermediate
Duration
49m
Students
55
Ratings
5/5
starstarstarstarstar
Description

Once you've decided to take advantage of cloud technology, resources, and scale, and have set up an Azure infrastructure, there is the small matter of transferring your existing data to the cloud. A migration is successful when the target production system is up and running correctly with the minimum impact on the business' operation. Achieving this requires knowing what data issues you will have in the new environment and minimizing system downtime while the data is transferred. This course looks at strategies and tools to achieve an optimal migration.

Learning Objectives

  • Understand the underlying concepts of migrating relational databases to Azure
  • Explore the factors in determining the optimal migration scenario as well as those affecting the physical movement of data from on-premises to Azure
  • Learn the different tools and services to aid in discovery, assessment, and migration
  • Learn how to migrate an on-premises SQL Server DB to Azure SQL Managed Instance using the Data Migration Service
  • Use Data Migration Assistant to migrate on-Premises SQL Server databases to Azure SQL DB
  • Migrate MySQL to Azure MySQL using MySQL Workbench
  • Migrate a MySQL database to Azure SQL Server using SQL Server Migration Assistant

Intended Audience

This course is ideal for anyone looking to migrate their existing on-premise database environment to an Azure SQL database solution.

Prerequisites

To get the most out of this course, you should be familiar with general database and cloud concepts.

 

Transcript

Migration scenarios can be broadly categorized as rehosting or re-platforming. Rehosting, also referred to as "lift and shift," is most often associated with changing the underlying infrastructure, as in rehosting an on-premises database on an Azure virtual machine. A VM doesn't care what database engine it is running, so after configuring the relevant database server software, you can restore almost any on-premises database to the virtual machine. How you implement a "lift and shift" operation in this scenario is very flexible. There are several Microsoft and Azure tools that can assist, as well as the databases' native or third-party tools, to get the job done.

SQL Managed Instance is nearly 100 % compatible with SQL Server without the overhead of managing a virtual machine. While classified as platform as a service, if your on-premise databases are currently supported versions of SQL Server, migration can also be a lift and shift exercise.

SQL Server databases reliant on third-party or custom software libraries for extended functionality will be limited to rehosting unless alternative solutions compatible with the selected Azure target can be implemented.

Re-platforming encompasses all scenarios where you migrate from a database engine that isn't supported either as a managed instance, or you're migrating to Azure SQL, Azure MySql, or Azure PostgreSQL. Even under the most favorable circumstances, that is, your on-premise database is compatible with Azure SQL, it is not possible to do a backup and restore. The closest you can get to that is exporting the on-premise DB to a BACPAC file and then importing that file to an Azure SQL database.

I'm talking about a one-time migration in all of these scenarios, where databases are backed up in one environment and restored to Azure in a time-sequential operation. The elephant in the room is the overall system downtime. When a combination of data volume and a limited migration time window rules out the on-shot strategy, you have a couple of options depending on your situation. You could employ a staggered approach, migrating slow-changing data while the on-premise production databases continue to operate, leaving only frequently changing data to migrate during the downtime switch over. This strategy depends on data usage patterns and works best with transactional data where records are predominantly added instead of existing data edited. In the context of SQL Server, a variation to this approach is employing the disaster recovery technique of restoring a full backup, followed by an incremental backup and finally a transaction log backup. The online version of migrating to Azure SQL managed instance through the portal's Data Migration Service is an automated version of the SQL Server disaster recovery technique just described.

If you have no tolerance for downtime, no matter how brief the cut-over period, there are alternative migration scenarios based on the target database. When the source and target are SQL Server instances, you can use on-premise backups to get you most of the way, then set up failover clustering, as in the high availability solution, to synchronize remaining data in real-time. There is no Azure or Microsoft real-time solution for migrating from an on-premise non-SQL Server to the equivalent hosted on an Azure VM. In this case, you will need to investigate high availability or replication solutions offered by the database vendor. 

About the Author
Avatar
Hallam Webber
Software Architect
Students
15315
Courses
28
Learning Paths
3

Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a  Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.