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.
In this demonstration, I want to show you how to use the data migration assistant application to migrate databases from on-premise to an Azure VM running SQL Server. The data migration app is a free download from Microsoft.com. The first thing we need to do is create a new migration project, which I'll do by clicking the plus button. This will be a migration project as opposed to an assessment, and I'll call the project VM migration. The source server type is SQL Server, and the target or destination is SQL Server running on an Azure virtual machine. Clicking create will open up a wizard-type UI where we fill in the server and database details. I'm connecting from my on-premise PC to Azure using a point-to-site VPN.
There are no domain controllers at either end of the connection, and I'm not using Azure Active Directory logins. That being the case, I'll use localhost for the source server as the data migration assistant is running locally, and Azure doesn't know about my PC. For the target server, I'll use the fully qualified virtual machine name. I'll be logging in with the sa account for both source and target servers, and I'll be telling the migration assistant to trust both servers' certificates and use an encrypted connection. Next, I'll select four databases to migrate and specify a shared folder on my local PC that the databases can be backed up to. I'm specifying the source server location using the IP address as it appears to the VPN connection. Because the source and target servers don't share a domain and essentially have nothing in common, I'll take database backups to a different location that the target server can read and restore from. Copying the backups from one location to another will add to the time of the overall operation. I've set up a shared folder called backups on the Azure VM, and I'll specify the server with its private IP address within the VPN's virtual network. The data and log file restore locations are the default ones specified in the target instance. Clicking next verifies those settings and takes me to the next screen to select logins that I would also like to migrate. I'll select the top two logins and start the migration. Here we can see the migration progress, and I'll quickly flick over to the virtual machine where I have two file explorer windows open corresponding to the shared folders on the source and target servers. The left-hand window shows the database backups on the local machine, and the right-hand window is the shared folder on the VM. We can see those backups being copied across to the virtual machine, and if I flick back to the migration assistant, we can now see the restore process has begun and is very quickly over. Going back to the VM, we are just in time to see the data migration assistant delete the last backup file. Opening up SQL Server management studio on the virtual machine and refreshing the databases node, we can see the newly migrated databases sitting there.
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.