An Azure SQL migration can remove hardware responsibilities and provide useful managed capabilities, but it does not make database architecture disappear. The difficult decisions move upward: selecting the right service model, adapting unsupported dependencies, designing identity and network paths, predicting cost, and proving that the application behaves correctly under production load.
Choose among different services, not one generic cloud database
Azure SQL Database, Azure SQL Managed Instance, and SQL Server on Azure Virtual Machines provide different levels of instance compatibility and administrative control. SQL Database suits applications that fit a database-scoped managed model. Managed Instance preserves more instance-level behavior. A virtual machine offers the most familiar SQL Server surface while leaving more operating-system, patching, backup, and availability responsibility with the customer.
Make the choice from requirements. Inventory cross-database queries, SQL Agent work, linked servers, CLR, file access, distributed transactions, third-party agents, authentication, and recovery needs. Do not use database size as a proxy for compatibility. Document any feature that must be redesigned and assign that work to an application owner.
Assess the application path end to end
A database assessment can report unsupported engine features yet miss a connection string hidden in a scheduled task, an old driver that lacks current encryption support, or a report server that relies on Windows delegation. Search source, deployment configuration, integration servers, desktop clients, and job definitions. Observe actual connections across a full business cycle.
Test connection pooling, transient fault handling, command timeouts, retry boundaries, and transaction behavior. A retry must encompass the complete safe unit of work; blindly retrying one statement can duplicate business actions or leave a multi-step transaction inconsistent.
Network latency becomes part of query design
An application that sits next to its database can conceal a chatty access pattern. Move the database to Azure while leaving the application elsewhere, and hundreds of small round trips become visible to users. Measure from the intended application location, through the planned private or public network controls, name resolution, firewalls, and gateways.
Reduce unnecessary round trips, return only needed columns and rows, and keep application and database tiers appropriately close. Validate large transfers and reporting extracts separately from transactional calls. A fast query inside the database can still produce a slow user experience if the application fetches and processes an excessive result set.
Design identity before cutover
Decide whether applications and people will use Microsoft Entra identities, managed identities, contained database users, or another supported approach. Prefer identities that avoid embedded long-lived passwords and grant only required permissions. Include deployment tools, monitoring, data pipelines, and emergency administration in the design.
Test token acquisition and renewal, group membership propagation, failover behavior, and access from automation. Maintain a controlled emergency path, but do not turn it into a shared daily administrator account. Log and review privileged changes.
Size with workload evidence
On-premises CPU count and memory do not translate directly into a cloud service tier. Capture CPU, data and log I/O, storage size and growth, memory behavior, concurrency, tempdb use, log generation, and important query latency. Include month-end and seasonal peaks. Then run representative load tests on the proposed target.
Managed-service limits and governance matter as much as headline capacity. Review maximum database size, log throughput, worker and session behavior, maintenance effects, backup retention, zone support, and scaling time for the selected option and region. Use current platform documentation during design because service capabilities change.
Rehearse movement and cutover
Online migration services can reduce downtime, but they do not eliminate a final synchronization and ownership change. Rehearse with production-like volume and change rate. Measure initial load, ongoing replication lag, final catch-up, application deployment, DNS or configuration change, and validation.
- Define the write freeze or final synchronization boundary.
- Verify target logins, permissions, schema, and configuration.
- Reconcile critical counts, totals, and recent transactions.
- Run user workflows and scheduled operations.
- Observe performance and platform health before acceptance.
- Keep a time-bounded rollback decision with explicit data handling.
Understand the new operating contract
Azure may automate backups, patching, and parts of high availability depending on the service, but the customer still owns data correctness, access, query performance, retention choices, monitoring, application resilience, and recovery validation. Test point-in-time restore and, where required, regional recovery. Confirm who receives alerts and who can act on them.
Build dashboards around business symptoms as well as platform metrics. A database can remain within service limits while one critical query regresses. Preserve Query Store history, configure useful alerts, and establish a review process for expensive or variable statements.
Control cost through architecture and observation
Estimate compute, storage, backup retention, network transfer, replicas, licensing benefits, and nonproduction environments. Then compare the estimate with actual bills and workload metrics after migration. Scaling up may be appropriate, but first determine whether poor queries, oversized indexes, or an avoidable data-transfer pattern is driving consumption.
The strongest Azure SQL migration plan describes not only where the database will run, but how the application will connect, recover, perform, and be operated there.
Allow time after cutover for tuning and handoff. Close temporary access, update recovery procedures, validate cost alerts, and document service limits and escalation paths. A managed platform reduces certain maintenance tasks; it rewards teams that are precise about the responsibilities that remain.