Database migration to Azure (2022-11-08 18:48 by willjoe #92403)
Step 1: explore database compatibility
Before you begin a database migration to Azure, you will need to ensure your current on-premise database is compatible with the Azure database and plan how you are going to navigate any issues that do arise.
Compatibility issues occur when features that exist in an on-premise database – such as linked servers, trace flags or filestreams – are not available in the cloud. You can check for compatibility issues using Microsoft’s Data Migration Assistant.
If you do come across any issue with compatibility that can’t be resolved, then you may need to consider migrating to an SQL Instance on an Azure Virtual Machine or using an Azure Managed Instance.
Step 2: select the right Azure service model
The overall pricing, service tier, storage and performance of the Azure relies upon the service model you choose, so choosing the correct one in the first instance will save you time further down the line.
The database will need deploying as either an individual Azure SQL database, within an Elastic Pool, and Azure SQL Managed Instance, or within an Azure Virtual Machine.
Step 3: choose your Azure service tier
Selecting the correct service tier is important to achieve optimal performance and manage costs of the Azure database. Opting for a service level that is too high can result in wasted budget, while a service level that is too high will cause reduced function.
Although Azure allows the database to be scaled up or down to suit your changing requirements, choosing the correct service tier ahead of your migration is easy with Microsoft’s Azure SSQL Database DTU Calculator – an advisory tool based on CPU, IOPS and LOG utilisation of your existing on-prem database.
Step 4: identify your required disaster recovery level
Azure offer various levels of disaster recovery protection, including high availability and geo-replication across global data centres. What level of disaster recovery you select should be based on your organisation recovery point objective (RPO) and recovery time objective (RTO).
RPO is the acceptable amount of data loss measured in time, while RTO is the maximum acceptable amount of time that your database can be down. How much of each of these that you need will determine the level of disaster recovery that you require.
Step 5: devise a migration strategy
Before you migrate your on-premise database to Azure, you need to plan your migration strategy. The types of things you should consider include, choosing and online or offline strategy by establishing if database downtime required for the move is a possibility, and which migration tool you’re going to use.
