Microsoft's November 2, 2026 update extends SQL Server migration in Azure Arc to Arc-registered instances without the Arc agent on the source server. The Azure portal can guide migration to Azure SQL Managed Instance, SQL Server on Azure VMs, or Azure SQL Database, including Hyperscale. Microsoft announcement.
For teams blocked on source-agent installation, this creates another migration route to evaluate. My planning review would begin with the selected target and the dependencies needed to reach it.
Match the Method to the Target
Microsoft maps SQL Managed Instance to Log Replay Service, SQL Server on Azure VMs to backup and restore, and Azure SQL Database to DMS with a self-hosted integration runtime. Managed Instance link is unavailable for these agentless registered instances. Supported migration methods.
I would record the chosen target, migration method, database owner, and required preparation together. That prevents a general approval to migrate from becoming an assumption that every method has been reviewed.
Build the rehearsal around a representative non-production database. Include the application connection and the operational process the team will use after the move.
Keep the source-agent restriction precise in the decision record. The rest of the migration architecture still needs an explicit review of its components, identities, and network paths.
Review the Azure SQL Database Preview Boundary
The current Microsoft Learn guide marks migration to Azure SQL Database as preview and offline only. Source changes after migration starts are not captured, and application downtime begins at that point. It requires a DMS-registered self-hosted integration runtime with source and target connectivity; an Azure Data Factory runtime cannot be reused. Current target requirements.
My proposed cutover plan would name who stops application writes and how the team verifies that the agreed stop has taken effect.
Use a known final test transaction in the rehearsal. Record its expected destination result before starting, then reconcile it with the migrated application state.
Agree on the point at which a failed attempt becomes a recovery decision. Give the service owner a concrete description of which system remains authoritative at every stage.
Establish Inventory and Readiness Evidence
Microsoft documents manual additions for stale inventory and an SSMS 22 assessment alternative to the agent-dependent portal assessment. Inventory and assessment options.
I would reconcile the planned database list with an owner-reviewed source inventory before selecting migration items. Mark the collection date and any subsequent changes.
Keep the actual readiness evidence with the migration record, including unresolved findings. A portal workflow that permits continuation should not silently close an unanswered compatibility question.
For an application spanning multiple databases, have the owner identify the complete transaction boundary. Review the proposed sequence against that application design before moving any production data.
Test the Business Operation After Migration
My acceptance plan would define a small set of reviewed application operations with known expected results. Include a write, a read of that write, and a representative scheduled operation where applicable.
Run those checks against the approved rehearsal target and preserve failures as well as successes. A successful data-movement status should be accompanied by evidence that the application can perform its intended work.
Ask the operations team to diagnose one deliberately failed connection during the rehearsal. Confirm that the planned evidence identifies the failure without requiring the migration engineer to reconstruct it verbally.
Leave a Complete Handover
I would record the final target settings, the application checks, remaining conditions, and the person responsible for each condition. Attach the tested recovery procedure and the observed timing.
Have the service owner accept that record before closing the move. It becomes the starting point for supporting the target and for planning the next database in the estate.
Practical Cloud Engineer Takeaway
Choose a supported method for the exact target.
Preserve the Azure SQL Database preview and downtime constraints.
Reconcile inventory and retain readiness evidence.
Test the application's operations on the rehearsal target.
Name cutover, recovery, and support owners.
Who Should Care?
SQL Server administrators, Azure migration engineers, and application owners whose source hosts cannot receive the Arc agent.
Bottom Line
The update removes a source-agent prerequisite for this migration experience. A successful move still depends on the chosen target's preparation and verified application behavior.
No SQL instance was registered, database assessed, integration runtime installed, backup uploaded, migration started, or source write stopped for this article.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments