4.1 Evaluating Migration Requirements and Strategies

Why Migration Planning Is a DP-300 Exam Pillar

The DP-300 exam weights Plan and implement data platform resources at 15-20%, and a large slice of that domain is migration strategy. Azure offers three broadly compatible SQL Server targets - Azure SQL Database (single database), Azure SQL Managed Instance (instance-scoped PaaS), and SQL Server on Azure VMs (IaaS lift-and-shift) - and a frequent exam pattern is matching a workload's feature surface to the right target. The planning phase is where that decision is made, and it rests on three activities: assess the source, choose the target by feature parity, and pick an offline or online path that respects the business's downtime tolerance.

Source and Target Assessment

Assessment begins with the Data Migration Assistant (DMA), a free Microsoft tool that scans a SQL Server source and produces a compatibility report. DMA answers two questions in one pass:

• Compatibility issues: features or behaviors that will break on the chosen target - for example, cross-database queries on Azure SQL Database, SQL Server Agent jobs on Azure SQL Database, or specific deprecated syntax.
• Feature parity / recommendations: which target SKU and tier the workload fits, plus partial or unsupported features that need a redesign (such as OPENROWSET with provider names, filestream, or T-SQL endpoints).

DMA classifies each finding by impact (Error, Warning, Information) and by migration blocker versus post-migration optimization. A migration blocker must be fixed before cutover; a warning can be remediated after. The exam often contrasts DMA with the Database Experimentation Assistant (DEA), which is workload-based, not static: DEA captures a trace of the production workload, replays it against the source and the target, and produces an A/B comparison report showing query-level performance regressions. The canonical two-tool pattern is DMA for static schema/config assessment, then DEA for behavioral validation under the real workload.

Target Selection by Feature Parity

The target choice is driven by which instance-level features the workload depends on. The exam's decision matrix looks like this:

The rule of thumb the exam tests: Azure SQL Database is the default when the workload is a self-contained application database with no instance-level dependencies. SQL Managed Instance is the answer when the workload needs instance scope (Agent, linked servers, cross-database queries, native Service Broker) but the team wants to retire OS and engine patching. SQL Server on Azure VM is the escape hatch when the workload depends on features that PaaS cannot provide - Windows authentication against a legacy domain, filestream, third-party services on the same box, or full control of tempdb placement and trace flags.

Compatibility Level and Version Targeting

Each database carries a compatibility level (for example, 130 for SQL Server 2016, 150 for SQL Server 2019, 160 for SQL Server 2022). Lowering the compatibility level preserves some legacy optimizer behaviors and can be a temporary migration aid, but it does not make an unsupported feature suddenly work. The exam trap is conflating compatibility level with feature parity: a database at compat level 130 still cannot use cross-database queries on Azure SQL Database. Keep the compatibility level at the source value at cutover to preserve behavior, raise it later in a controlled change after validating performance with Query Store.

Offline vs Online Migration Strategies

The downtime tolerance of the business drives the strategy. An offline migration takes the source database out of service for the entire copy window: applications are stopped, the full backup is restored to the target, and at cutover the source is decommissioned. Total downtime equals the size-of-data copy plus validation. This is the simplest, cheapest, and least risky path - and the right answer when the database is small, the maintenance window is long enough, or the application can tolerate hours of unavailability.

An online migration keeps the source in service while a continuous sync replicates changes to the target. The initial snapshot is loaded while the source stays live, then an ongoing delta - powered by change data capture (CDC), transactional replication, or the Managed Instance link - keeps the target current. Downtime shrinks to the final cutover (stop applications, let the final delta drain, point connection strings at the target). Online is the right answer when the database is large, the maintenance window is short, or the business cannot tolerate extended unavailability. The tradeoff is complexity: the replication channel must be monitored, the source must remain in a consistent state, and the cutover sequence must be rehearsed.

RPO and RTO of the Migration Itself

The exam tests whether you can express downtime tolerance as RPO and RTO for the migration, separate from the RPO/RTO of the normal production posture:

• RPO (Recovery Point Objective) is the maximum acceptable data loss measured in time. For an offline migration, RPO is effectively the time between the last backup and cutover - any transactions written during that window are lost unless captured manually. For an online migration with CDC, RPO is the replication latency, typically seconds.
• RTO (Recovery Time Objective) is the maximum acceptable downtime. For an offline migration, RTO is the size-of-data restore time. For an online migration, RTO is the cutover duration - the time to drain the final delta and re-point connections, typically minutes.

A scenario that states 'no more than 5 minutes of downtime and no more than 10 seconds of data loss' is pointing you at an online strategy with a low-latency replication channel. A scenario that says 'the application is internal and a 4-hour Sunday window is acceptable' is pointing you at an offline migration.

Sizing and Network Prerequisites

Sizing has two inputs: the DMA performance baseline (captured over a representative period) and a headroom buffer, typically 20-30% above peak observed usage to absorb post-migration workload growth and the overhead of telemetry. For a vCore target, translate the source's CPU/memory/IO profile into a starting SKU, then plan to tune with Query Store after cutover rather than oversizing blindly.

Network prerequisites decide whether the migration succeeds at all. For on-premises sources:

• ExpressRoute or a site-to-site VPN is required for DMS migrations; the bandwidth must cover the initial snapshot throughput plus the sustained delta rate. A rule of thumb: 1 TB over a 1 Gbps link with overhead is roughly 3-4 hours for the initial copy.
• Ports: DMS needs outbound 443 and 445 (SMB for backup file share) and the SQL Server port (1433 by default) between the DMS agent and the source. Managed Instance additionally requires the port range 5022 and 56000-65535 open between DMS and the managed instance's virtual network.
• Self-hosted Integration Runtime (for Azure Data Studio migration and Azure Data Factory-based paths) must be installed on a machine that can reach the source, and on a Windows server joined to the source domain for Windows-auth sources.

Assessment Workflow Summary

The full planning sequence the exam expects you to recite: (1) run DMA against each source database for the chosen target; (2) remediate migration blockers or pick a different target; (3) capture a production workload trace and replay it with DEA to surface performance regressions; (4) size the target SKU from the baseline plus headroom; (5) decide offline or online from the RPO/RTO; (6) validate network prerequisites and Identity/Runtime placement; (7) document the cutover runbook. Skipping the DEA replay on a performance-sensitive workload is the planning error the exam most often punishes.