Oracle Technical Track

Introduction to Azure Database Migration Service - SQL on the edge episode 19

2 min read

Apr 11, 2019 12:00:00 AM

Azure has a rich set of offerings in terms of database platform services. We have the full family of SQL Server-based databases (single, pool, managed instance, data warehouse), open source first-party Database-as-a-Service for MySQL, MariaDb and PostgreSQL and the NoSQL Cosmos DB. One gap that still existed, though, was the lack of an integrated tool to migrate your on-premises databases to any of these services. There are many ways to do it, of course, but none that were easy to implement and cloud-native. This is where Azure Database Migration Service (ADMS) comes in. The service is not just for migrating SQL Server to Azure, as some folks might think. It also has support for migrating open-source workloads, as well as Oracle workloads, into the services offered by Azure. Say you are migrating Oracle data to PostgreSQL. Well, you can actually do this with ADMS! And because it is a managed service, you don't have to worry about managing infrastructure, monitoring or the actual mechanics of the data movement. And because it's a cloud service, once your migration is complete, you can simply stop using the service and stop getting billed.

Service Model

The service currently offers two tiers:

Standard: 1-2-4 cores, allows for offline migrations, free
Premium: 4 cores, allows for online migrations, charged per hour (first 6 months free)

Currently, Microsoft has an offer where the first 6 months of your Premium ADMS service is free. This is a great offer for people who have an aggressive migration timeline because you can use the tool and the infrastructure to do your database migrations with no cost.

Offline or Online

Premium tier is the only option for online migrations. Now, this is not exactly "online" but I would call it a "low downtime" option. So instead of just moving the data one time, the service will set up a data replication stream between source and target, and continually apply changes to keep the target up to date. Once you are ready for your cutover to the cloud, you can stop the application, make sure all the sync operations are complete and then re-point your application to the cloud copy. Depending on your application and how much logic you want to build into it, this could be done in a few seconds without much of an impact to the end users. Making a choice here is, of course, dependent on your SLA with your users. If your RTO is higher, then you can just use the Standard tier to take some more prolonged downtime, move all the data at once and pay nothing for your use of the ADMS.

Tooling

As useful as ADMS is, it will most likely not be the only tool you will use for your migration. ADMS will not alert over compatibility issues, convert schemas or database code. Other tools such as the Data Migration Assistant, SQL Server Migration Assistant or third party database conversion tools must be used to make sure that any compatibility issues between source and target are resolved. Necessary modifications to the schema or code are also outside of what ADMS does; you need that schema already created for ADMS to do its job. Once this is done and you are at the phase that only data needs to move, then ADMS is a good option to go over this last mile.