Three posts of managed databases raise the obvious question: how does the data get there? Database migration is nine parts discipline and one part tooling, but the tooling has gotten genuinely good, and knowing which tool fits which scenario is most of the technical decision.

Offline or Online: The Only Strategic Question

Offline migration is backup, transfer, restore: simple, testable, and it costs a downtime window equal to the whole process. If your database restores in two hours and the business tolerates a Saturday night window, offline is the right answer, stop overengineering. Online migration establishes continuous replication from source to target, lets the target catch up while the source keeps serving, and shrinks cutover to minutes of switching connection strings. Everything between those poles, the size of the database, the tolerance for downtime, the change rate, just selects a point on the line. The specialized paths from earlier in the series slot in here: the Managed Instance link for SQL Server is the premium online experience, and replica promotion for PostgreSQL and MySQL (stand up an Azure replica of the on premises primary, let it sync, promote at cutover) is often the simplest online path for the open source engines.

The Toolbox

Assessment comes first and is non negotiable: Azure Migrate for the estate wide view, and the Data Migration Assistant or the Azure SQL migration extension in Azure Data Studio for SQL Server compatibility findings (deprecated features, cross database dependencies, the CLR surprise). For execution, Azure Database Migration Service (DMS) handles the mainstream paths: SQL Server to Azure SQL flavors, PostgreSQL to Flexible Server, MySQL to Flexible Server, with both offline and online modes depending on the pair. It runs as a service inside your VNet, reading the source over your ExpressRoute or VPN, so the network posts from this series are literally the migration path. For heterogeneous migrations, Oracle to PostgreSQL being the classic, the work is schema and code conversion more than data movement: conversion tooling gets you the bulk translation, and the remaining percent of packages, triggers, and cursor heavy logic is where the project actually lives. Budget for it honestly; the data moves in a weekend, the PL/SQL takes the quarter.

The Cutover Runbook

Every successful cutover I have run followed the same skeleton. Before: replication healthy with lag near zero, target validated by the application test suite against a recent copy, performance baseline compared (managed targets have different characteristics, find the regression before your users do), rollback path defined and tested, and connection strings already externalized behind DNS or App Configuration so the switch is one change, not forty deployments. During: freeze writes on the source, confirm final lag is zero, run the smoke tests against the target, flip the configuration, watch error rates and latency dashboards with the whole team on the call, and keep the source in read only rather than off. After: the source stays available but untouched for an agreed period (a week is typical), replication reversed if the platform supports it for a true rollback option, and a decommission date in the calendar so the old server does not become permanent by inertia.

The failure pattern to design against is the trickle cutover: half the applications moved, half not, cross database queries spanning the gap over a network link, performance mysteries everywhere. Move dependent applications as a unit, and if the dependency graph is too tangled to unit ize, untangle it first, because migration is the forcing function that finally justifies that work.

Cheers
Osama