Stream data in near real time from SQL to Azure Event Hubs - Public preview
If near-real time integration is something you are looking to implement and you were looking for a simpler way to get the data out of SQL, keep reading. SQL is making it easier to integrate and Change Event Streaming is a feature continuing this trend. Modern applications and analytics platforms increasingly rely on event-driven architectures and real-time data pipelines. As the businesses speed up, real time decisioning is becoming especially important. Traditionally, capturing changes from a relational database requires complex ETL jobs, periodic polling, or third-party tools. These approaches often consume significant cycles of the data source, introduce operational overhead, and pose challenges with scalability, especially if you need one data source to feed into multiple destinations. In this context, we are happy to release Change Event Streaming ("CES") feature into Public Preview for Azure SQL Database. This feature enables you to stream row-level changes - inserts, updates, and deletes - from your database directly to Azure Event Hubs and Fabric Eventstreams in near real time. Change Event Streaming addresses the above challenges by: Reducing latency: Changes are streamed (pushed by SQL) as they happen. This is in contrast with traditional CDC (change data capture) or CT (change tracking) based approaches, where an external component needs to poll SQL at regular intervals. Traditional approaches allow you to increase polling frequency, but it gets difficult to find a sweet spot between minimal latency and minimal overhead due to too frequent polls. Simplifying architecture: No need for Change Data Capture (CDC), Change Tracking, custom polling or external connectors - SQL streams directly to configured destination. This means simpler security profile (fewer authentication points), fewer failure points, easier monitoring, lower skill bar to deploy and run the service. No need to worry about cleanup jobs, etc. SQL keeps track of which changes are successfully received by the destination, handles the retry logic and releases log truncation point. Finally, with CES you have fewer components to procure and get approved for production use. Decoupling: The integration is done on the database level. This eliminates the problem of dual writes - the changes are streamed at transaction boundaries, once your source of truth (the database) has saved the changes. You do not need to modify your app workloads to get the data streamed - you tap right onto the data layer - this is useful if your apps are dated and do not possess real-time integration capabilities. In case of some 3rd party apps, you may not even have an option to do anything other than database level integration, and CES makes it simpler. Also, the publishing database does not concern itself with the final destination for the data - Stream the data once to the common message bus, and you can consume it by multiple downstream systems, irrespective of their number or capacity - the (number of) consumers does not affect publishing load on the SQL side. Serving consumers is handled by the message bus, Azure Event Hubs, which is purpose built for high throughput data transfers. Key Scenarios for CES Event-driven microservices: They need to exchange data, typically thru a common message bus. With CES, you can have automated data publishing from each of the microservices. This allows you to trigger business processes immediately when data changes. Real-time analytics: Stream operational data into platforms like Fabric Real Time Intelligence or Azure Stream Analytics for quick insights. Breaking down the monoliths: Typical monolithic systems with complex schemas, sitting on top of a single database can be broken down one piece at a time: create a new component (typically a microservice), set up the streaming from the relevant tables on the monolith database and tap into the stream by the new components. You can then test run the components, validate the results against the original monolith, and cutover when you build the confidence that the new component is stable. Cache and search index updates: Keep distributed caches and search indexes in sync without custom triggers. Data lake ingestion: Capture changes continuously into storage for incremental processing. Data availability: This is not a scenario per se, but the amount of data you can tap into for business process mining or intelligence in general goes up whenever you plug another database into the message bus. E.g. You plug in your eCommerce system to the message bus to integrate with Shipping providers, and consequently, the same data stream is immediately available for any other systems to tap into. How It Works CES uses transaction log-based capture to stream changes with minimal impact on your workload. Events are published in a structured JSON format following the CloudEvents standard, including operation type, primary key, and before/after values. You can configure CES to target Azure Event Hubs via AMQP or Kafka protocols. For details on configuration, message format, and FAQs, see the official documentation: Feature Overview CES: Frequently Asked Questions Get Started Public preview CES is available today in public preview for Azure SQL Database and as a preview feature in SQL Server 2025. [update 20-Mar-2026] Change Event Streaming is now in public preview for Azure SQL Managed instance. Read more here. [update 3-Aug-2026] Change Event Streaming is now also in public preview for Fabric SQL database. Read more here. We encourage you to try the feature out and start building real-time integrations on top of your existing data. We welcome your feedback—please share your experience through Azure Feedback portal or support channels. The comments below on this blog post will also be monitored, if you want to engage with us. Finally, CES team can be reached via email: sqlcesfeedback [at] microsoft [dot] com. Useful resources Free Azure SQL Database. Free Azure SQL Managed Instance.SQLCon is Back: 5 Reasons to Attend the European Microsoft Fabric + SQL Community Conference
5 Reasons to Attend the European Microsoft Fabric + SQL Community Conference This year the SQL community joins Fabric in Europe for the first time at the Microsoft Fabric + SQL Community Conference happening September 28th - October 1st in Barcelona, Spain. Hear the latest announcements and roadmap directly from Microsoft leaders. With a full week of deep technical sessions and workshops covering the topics you care about most across and see how we’re helping solve your most pressing data challenges, from strengthening data sovereignty to powering agentic AI and unlocking trusted, actionable intelligence. And while there’s no shortage of topics, here are a couple of things we’re the most excited about heading to Barcelona: Unify your data (conference) experience With one registration, this event doubles your opportunity to sharpen your skillset with 130+ expert led sessions, workshops, and keynotes coming together in one high- impact week. Mix and match sessions to best meet your learning goals while you move seamlessly across tracks, visit the shared expo, and connect with peers in the community hub, all under one roof. The ultimate SQL experience, like only Microsoft can deliver With more than 25 dedicated SQL sessions, whether you’re a DBA or, a developer building AI apps, you can create your custom agenda with the topics you care about most. Pre-day programming is for the builders; bring your laptop and start your week with any of our full- day SQL workshops for the demos, practical guidance, and repeatable patterns you can start using immediately. Tuesday kicks off the official event with our opening keynote, three corenotes, and general sessions focused on SQL Server 2025, Azure SQL, and SQL in Fabric. Learn the latest in performance, tuning and tools like SSMS and VS Code delivered directly from SQL experts, MVPs, and community leaders. Ready to start building your agenda? Try our new session planner to curate your schedule based on your interests. The backdrop: Barcelona This year’s conference takes place in the historic, vibrant city of Barcelona, set along the Mediterranean Sea, the ideal setting for the first European SQLCon. When you’re ready for a break, you’re only a 15-minute ride away from the city center, perfect for exploring Gaudí’s iconic architecture or enjoying some local bites. Don’t miss the wrap- up celebration taking place in Barcelona’s exclusive Sutton Club. Community Connection SQLCon is more than just sessions; we’re bringing together more than 4,000 of the most dedicated Microsoft community members together for a week of endless connection opportunities. The Community Hub will bring some of our most popular experiences to life, from in-person meetups and user group connections to hands-on learning and certification opportunities all designed to help you grow your skills and expand your network. Launching Soon: SQLCon TV Enjoyed catching all the behind-the-scenes action on FabCon TV? In Barcelona we’ll bring SQLCon TV to the stage, with the content, demos, and interviews every SQL fan will want to see. Save your spot today. The earlier you register, the more opportunities you have to take advantage of early pricing specials. See you in Barcelona!Azure Data Studio Retirement
We’re announcing the upcoming retirement of Azure Data Studio (ADS) on February 6, 2025, as we focus on delivering a modern, streamlined SQL development experience. ADS will remain supported until February 28, 2026, giving developers ample time to transition. This decision aligns with our commitment to simplifying SQL development by consolidating efforts on Visual Studio Code (VS Code) with the MSSQL extension, a powerful and versatile tool designed for modern developers. Why Retire Azure Data Studio? Azure Data Studio has been an essential tool for SQL developers, but evolving developer needs and the rise of more versatile platforms like VS Code have made it the right time to transition. Here’s why: Focus on innovation VS Code, widely adopted across the developer community, provides a robust platform for delivering advanced features like cutting-edge schema management and improved query execution. Streamlined tools Consolidating SQL development on VS Code eliminates duplication, reduces engineering maintenance overhead, and accelerates feature delivery, ensuring developers have access to the latest innovations. Why Transition to Visual Studio Code? VS Code is the #1 developer tool, trusted by millions worldwide. It is a modern, versatile platform that meets the evolving demands of SQL and application developers. By transitioning, you gain access to cutting-edge tools, seamless workflows, and an expansive ecosystem designed to enhance productivity and innovation. We’re committed to meeting developers where they are, providing a modern SQL development experience within VS Code. Here’s how: Modern development environment VS Code is a lightweight, extensible, and community-supported code editor trusted by millions of developers. It provides: Regular updates. An active extension marketplace. A seamless cross-platform experience for Windows, macOS, and Linux. Comprehensive SQL features With the MSSQL extension in VS Code, you can: Execute queries faster with filtering, sorting, and export options for JSON, Excel, and CSV. Manage schemas visually with Table Designer, Object Explorer, and support for keys, indexes, and constraints. Connect to SQL Server, Azure SQL (all offerings), and SQL database in Fabric using an improved Connection Dialog. Streamline development with scripting, object modifications, and a unified SQL experience. Optimize performance with an enhanced Query Results Pane and execution plans. Integrate with DevOps and CI/CD pipelines using SQL Database Projects. Stay tuned for upcoming features—we’re continuously building new experiences based on feedback from the community. Make sure to follow the MSSQL repository on GitHub to stay updated and contribute to the project! Streamlined workflow VS Code supports cloud-native development, real-time collaboration, and thousands of extensions to enhance your workflows. Transitioning to Visual Studio Code: What You Need to Know We understand that transitioning tools can raise concerns, but moving from Azure Data Studio (ADS) to Visual Studio Code (VS Code) with the MSSQL extension is designed to be straightforward and hassle-free. Here’s why you can feel confident about this transition: No Loss of Functionality If you use ADS to connect to Azure SQL databases, SQL Server, or SQL database in Fabric, you’ll find that the MSSQL extension supports these scenarios seamlessly. Your database projects, queries, and scripts created in ADS are fully compatible with VS Code and can be opened without additional migration steps. Familiar features, enhanced experience VS Code provides advanced tools like improved query execution, modern schema management, and CI/CD integration. Additionally, alternative tools and extensions are available to replace ADS capabilities like SQL Server Agent and Schema Compare. Cross-Platform and extensible Like ADS, VS Code runs on Windows, macOS, and Linux, ensuring a consistent experience across operating systems. Its extensibility allows you to adapt it to your workflow with thousands of extensions. If you have further questions or need detailed guidance, visit the ADS Retirement page. The page includes step-by-step instructions, recommended alternatives, and additional resources. Continued Support With the Azure Data Studio retirement, we’re committed to supporting you during this transition: Documentation: Find detailed guides, tutorials, and FAQs on the ADS Retirement page. Community Support: Engage with the active Visual Studio Code community for tips and solutions. You can also explore forums like Stack Overflow. GitHub Issues: If you encounter any issues, submit a request or report bugs on the MSSQL extension’s GitHub repository. Microsoft Support: For critical issues, reach out to Microsoft Support directly through your account. Transitioning to VS Code opens the door to a more modern and versatile SQL development experience. We encourage you to explore the new possibilities and start your journey today! Conclusion Azure Data Studio has served the SQL community well,but the Azure Data Studio retirement marks an opportunity to embrace the modern capabilities of Visual Studio Code. Transitioning now ensures you’re equipped with cutting-edge tools and a future-ready platform to enhance your SQL development experience. For a detailed guide on ADS retirement , visit aka.ms/ads-retirement. To get started with the MSSQL extension, check out the official documentation. We’re excited to see what you build with VS Code!License-free DR on Azure SQL Managed Instance for SQL Server
Hybrid failover rights is a new benefit for SQL Server customers using Software Assurance (SA) or Pay-as-you-go billing option, that provides a free license for Azure SQL Managed Instance when it is used as a passive secondary for Disaster Recovery (DR).Generally Available: SQL Migration to SQL Server on Azure Virtual Machines in Azure Architecture
One Migration Experience, More Flexibility Modernizing SQL Server estates is rarely a single-step journey. Organizations often operate across on-premises, hybrid, and cloud environments while balancing application dependencies, operational requirements, and modernization goals. SQL Server migration enabled by Azure Arc simplifies this process by bringing migration activities into a single experience in the Azure portal. With the July 2026 release, we are announcing General Availability of SQL Server on Azure Virtual Machines as a migration target in Azure Arc, allowing customers to have a greater flexibility to choose Azure destination that best aligns with to your needs without introducing additional tools or migration processes. Whether migrating to the fully managed Azure SQL Managed Instance service or to SQL Server running on Azure VMs, the experience remains consistent and familiar. Unified Migration Workflow A key benefit of SQL Server migration enabled by Azure Arc is that the entire migration lifecycle is managed from a single tool in Azure portal. After a SQL Server instance is enabled by Azure Arc, customers can: Assess migration readiness Select a migration target Configure migration settings Monitor migration progress Validate results Perform final cutover All of these activities are performed directly from the Azure portal using a guided workflow designed to simplify migration planning and execution. The prerequisite remains unchanged: source SQL Server instances must be enabled by Azure Arc before migration can begin. The result is a flexible, scalable, and consistent migration experience that supports hybrid realities, reduces operational overhead, and helps customers modernize SQL Server estates at their own pace. Consistent Experience Across Azure SQL Targets Migration to SQL Server on Azure Virtual Machines follows the same operational model already available for Azure SQL Managed Instance migration scenarios. Customers use the same migration dashboard, monitoring experience, and guided workflow regardless of the destination. This consistency reduces learning curves, simplifies operational processes, and enables teams to select the most appropriate Azure SQL platform without changing migration methodology. Online Migration Using Backup and Log Shipping Migration to SQL Server on Azure Virtual Machines uses backup and restore with log shipping to support online migration scenarios while minimizing downtime. The process begins with a full database backup that is restored to the target SQL Server instance running on an Azure Virtual Machine. Transaction log backups that are uploaded continuously by your workflows to Azure Blob Storage are continuously applied to the target database, keeping it closely synchronized with the source environment. Azure Blob Storage serves as the intermediary staging location between source and target systems. To support efficient data movement and restore operations, both the Azure Blob Storage account and the target SQL Server on Azure Virtual Machines must reside in the same Azure region. Within the Azure Arc migration experience, customers select the Azure Blob Storage container that stores the backup files. Azure Arc automatically restores the full backup and continuously applies transaction log backups as they become available. Customers are responsible for configuring and maintaining the continuous upload of transaction log backups to Azure Blob Storage. Customer-Controlled Cutover When the customer is ready to complete migration, upon customer initiated cutover, Azure Arc performs the final synchronization by applying the last uploaded backup and bringing the target database online. This approach gives organizations full control over the migration timeline and cutover window, allowing downtime to be planned according to business requirements while reducing operational complexity. Learn More To learn more about SQL Server migration enabled by Azure Arc, see: Migration Overview For information about migrating to SQL Server in Azure VM, see: Migrate to SQL Server in Azure VM
How does GitHub Copilot in SSMS 22 handle database context collection before generating a response?
Hello, I am trying to better understand the internal workflow of GitHub Copilot in SSMS 22, especially for database-specific questions. From the product descriptions, it seems that Copilot can use the context of the currently connected database, such as schema, tables, columns, and possibly other metadata, when answering questions or generating T-SQL. However, I could not find clear official documentation about the actual sequence of operations. My main questions are: Before generating a response, does Copilot first collect database context/metadata from the active connection and then send that context to the LLM as grounding information? Or does it first use the LLM to interpret the user’s request, decide what information is needed, and then retrieve database metadata before generating the final answer? In some explanations, I have seen the phrase "Core SQL Copilot Infrastructure", but I cannot find any official documentation for that term. Is this an official component name? If so, what does it specifically refer to in the SSMS Copilot architecture? When Copilot answers schema-related or data-related questions, what information is retrieved automatically from the connected database, and is any SQL executed as part of that process? Is there any official architectural documentation that explains: context collection, prompt grounding, LLM invocation order, and whether query execution can occur before the final response is generated? I am asking because I want to understand the feature from both an architecture and data governance/security perspective. Any clarification from the product team or documentation links would be greatly appreciated. Thank you.Unable to install SQL Server 2022 Express (installer glitch + SSMS error)
Hi, I recently purchased a new Lenovo laptop, and I am trying to install Microsoft SQL Server 2022 Express along with SSMS. SSMS installed successfully, but SQL Server installation fails, and sometimes the installer UI glitches or does not load properly. Because of this, I am getting connection errors in SSMS like "server not found" and "error 40". I am not very familiar with technical troubleshooting. Can someone guide me step-by-step in a simple way to install SQL Server correctly? Thank you.
Cannot connect Azure OpenAI Embeddings model to SQL Server 2025
On SQL Server 2025, I am trying to vectorize a table. To set up the ability for SQL Server 2025 to communicate with Azure OpenAI embeddings model, I first created a master key for encryption. CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Secret'; GO Then I set up a database scoped credential. CREATE DATABASE SCOPED CREDENTIAL [MyAzureOpenAICredential] WITH IDENTITY = 'HTTPEndpointHeaders', SECRET = '{"api-key":"secret"}'; Then I created an external model. CREATE EXTERNAL MODEL AzureOpenAIEmbeddingsModel WITH ( LOCATION = 'https://{secret}-eastus2.cognitiveservices.azure.com/openai/deployments/text-embedding-3-small/embeddings?api-version=2023-05-15', API_FORMAT = 'Azure OpenAI', MODEL_TYPE = EMBEDDINGS, MODEL = 'text-embedding-3-small', CREDENTIAL = [MyAzureOpenAICredential] ); However, when I run this simple script: DECLARE @text NVARCHAR(MAX) = N'SQL Server 2025 enables AI-powered applications'; DECLARE @embedding VECTOR(1536) = AI_GENERATE_EMBEDDINGS(@text USE MODEL AzureOpenAIEmbeddingsModel); I get this error. The database scoped credential 'MyAzureOpenAICredential' cannot be used to invoke an external rest endpoint. I have read through https://learn.microsoft.com/en-us/training/modules/build-ai-solutions-sql-server/4-integrate-ai-models pertaining to this task. As well as SQL Server 2025 docs for creating a model. I have also read SQL Server 2025 docs for creating https://learn.microsoft.com/en-us/sql/t-sql/statements/create-database-scoped-credential-transact-sql?view=sql-server-ver17. I have not found any answers.SQL Server 2016 Reaches End of Support: A Customer Engineer's Perspective on What's Next
Why This Day Matters July 14, 2026 marks the end of Extended Support for SQL Server 2016. After today, organizations running SQL Server 2016 will no longer receive security updates, non-security hotfixes, or product support unless they have a specific support strategy in place. As a Customer Engineer, I've spent years helping customers navigate technology lifecycle events. This one feels particularly significant because SQL Server 2016 remains heavily deployed across enterprise environments. For official lifecycle dates and milestones, see the Microsoft Lifecycle Policy for SQL Server 2016: Reference: https://learn.microsoft.com/lifecycle/products/sql-server-2016 Why SQL Server 2016 Feels Different SQL Server 2016 introduced capabilities that many organizations still rely on today, including: Query Store Always Encrypted Native JSON Support Stretch Database Enhanced security and performance capabilities For many businesses, SQL Server 2016 became the standard data platform supporting ERP systems, billing applications, healthcare workloads, manufacturing systems, and custom line-of-business applications. Ten years is a long time in IT. During that period, databases often evolve from "just another server" into business-critical infrastructure. Learn more about SQL Server 2016 features: Reference: https://learn.microsoft.com/sql/sql-server/what-s-new-in-sql-server-2016 What "End of Support" Really Means One of the most common misconceptions I hear is: "Will my SQL Server stop working tomorrow?" No. The server will continue running. Applications will continue connecting. What changes is your risk profile. Organizations will no longer receive: Security updates Product fixes Technical support Regulatory assurance associated with supported software Microsoft's official guidance on end-of-support considerations can be found here: Reference: https://learn.microsoft.com/sql/sql-server/end-of-support/sql-server-end-of-support-overview Option 1: Upgrade to a Supported SQL Server Version For many organizations, the most straightforward path is upgrading to SQL Server 2022 or SQL Server 2025. Benefits include: Continued support Latest security protections Performance improvements New AI and data platform capabilities Before upgrading, review compatibility considerations and perform application testing. Reference: https://learn.microsoft.com/sql/database-engine/install-windows/upgrade-sql-server Reference: https://learn.microsoft.com/sql/sql-server/sql-server-release-notes Option 2: Move to Azure SQL Managed Instance Azure SQL Managed Instance is often my recommendation when customers want to reduce operational overhead while maintaining high SQL Server compatibility. Advantages include: Automated patching Built-in high availability Automated backups Near full SQL Server compatibility Reduced infrastructure management Learn more: Reference: https://learn.microsoft.com/azure/azure-sql/managed-instance/sql-managed-instance-paas-overview Option 3: Lift and Shift to SQL Server on Azure Virtual Machines For organizations seeking minimal application changes, SQL Server on Azure Virtual Machines can provide a familiar environment while eliminating hardware refresh requirements. This option also enables customers to take advantage of Extended Security Updates through Azure while planning broader modernization initiatives. Reference: https://learn.microsoft.com/azure/azure-sql/virtual-machines/windows/sql-server-on-azure-vm-iaas-what-is-overview Option 4: Purchase Extended Security Updates (ESUs) If immediate migration is not possible, Extended Security Updates provide up to three additional years of Critical security updates. ESUs can be valuable when: Vendor certification delays upgrades Hardware refresh projects are underway Business priorities prevent immediate migration However, ESUs should be viewed as a temporary bridge rather than a long-term strategy. Reference: https://learn.microsoft.com/sql/sql-server/end-of-support/sql-server-extended-security-updates Don't Skip the Assessment Phase The most successful migration projects begin with discovery and assessment. Common issues identified include: Deprecated features Compatibility concerns Linked Server dependencies SQL Agent jobs CLR integrations Legacy SSIS and SSRS workloads Resources that can help: https://learn.microsoft.com/azure/migrate/migrate-services-overview https://learn.microsoft.com/sql/sql-server/azure-arc/overview https://learn.microsoft.com/sql/dma/dma-overview Migration Tools Worth Evaluating Different migration scenarios require different tools. Microsoft provides several options: Data Migration Assistant (DMA) SQLPackage Azure Database Migration Service Managed Instance Link Distributed Availability Groups Comprehensive migration guidance: https://techcommunity.microsoft.com/blog/microsoftdatamigration/microsoft-options-to-migrate-sql-server-databases/4407666 https://learn.microsoft.com/azure/dms/dms-overview https://learn.microsoft.com/sql/tools/sqlpackage/sqlpackage Lessons Learned from Customer Engagements After supporting numerous SQL Server modernization projects, several themes consistently emerge: The database is rarely the hardest part. Applications and dependencies drive complexity. Downtime requirements significantly influence migration strategy. Organizations that start 6–9 months early typically experience smoother transitions. ESUs buy time, but they do not replace a modernization plan. For migration planning best practices: https://learn.microsoft.com/azure/cloud-adoption-framework/migrate/ Final Thoughts If you're reading this on or shortly after July 14, 2026, and SQL Server 2016 is still running in your environment, you're not alone. Whether your path forward is: SQL Server 2025 Azure SQL Managed Instance SQL Server on Azure Virtual Machines Extended Security Updates the most important step is to begin with an assessment and establish a modernization plan. SQL Server 2016 served organizations exceptionally well for nearly a decade. The conversation now is not about the end of SQL Server 2016. It's about preparing your data platform for the next decade.Generally Available: SQL Migration to SQL Server on Azure Virtual Machines in Azure Architecture
One Migration Experience, More Flexibility Modernizing SQL Server estates is rarely a single-step journey. Organizations often operate across on-premises, hybrid, and cloud environments while balancing application dependencies, operational requirements, and modernization goals. SQL Server migration enabled by Azure Arc simplifies this process by bringing migration activities into a single experience in the Azure portal. With the July 2026 release, we are announcing General Availability of SQL Server on Azure Virtual Machines as a migration target in Azure Arc, allowing customers to have a greater flexibility to choose Azure destination that best aligns with to your needs without introducing additional tools or migration processes. Whether migrating to the fully managed Azure SQL Managed Instance service or to SQL Server running on Azure VMs, the experience remains consistent and familiar. Unified Migration Workflow A key benefit of SQL Server migration enabled by Azure Arc is that the entire migration lifecycle is managed from a single tool in Azure portal. After a SQL Server instance is enabled by Azure Arc, customers can: Assess migration readiness Select a migration target Configure migration settings Monitor migration progress Validate results Perform final cutover All of these activities are performed directly from the Azure portal using a guided workflow designed to simplify migration planning and execution. The prerequisite remains unchanged: source SQL Server instances must be enabled by Azure Arc before migration can begin. The result is a flexible, scalable, and consistent migration experience that supports hybrid realities, reduces operational overhead, and helps customers modernize SQL Server estates at their own pace. Consistent Experience Across Azure SQL Targets Migration to SQL Server on Azure Virtual Machines follows the same operational model already available for Azure SQL Managed Instance migration scenarios. Customers use the same migration dashboard, monitoring experience, and guided workflow regardless of the destination. This consistency reduces learning curves, simplifies operational processes, and enables teams to select the most appropriate Azure SQL platform without changing migration methodology. Online Migration Using Backup and Log Shipping Migration to SQL Server on Azure Virtual Machines uses backup and restore with log shipping to support online migration scenarios while minimizing downtime. The process begins with a full database backup that is restored to the target SQL Server instance running on an Azure Virtual Machine. Transaction log backups that are uploaded continuously by your workflows to Azure Blob Storage are continuously applied to the target database, keeping it closely synchronized with the source environment. Azure Blob Storage serves as the intermediary staging location between source and target systems. To support efficient data movement and restore operations, both the Azure Blob Storage account and the target SQL Server on Azure Virtual Machines must reside in the same Azure region. Within the Azure Arc migration experience, customers select the Azure Blob Storage container that stores the backup files. Azure Arc automatically restores the full backup and continuously applies transaction log backups as they become available. Customers are responsible for configuring and maintaining the continuous upload of transaction log backups to Azure Blob Storage. Customer-Controlled Cutover When the customer is ready to complete migration, upon customer initiated cutover, Azure Arc performs the final synchronization by applying the last uploaded backup and bringing the target database online. This approach gives organizations full control over the migration timeline and cutover window, allowing downtime to be planned according to business requirements while reducing operational complexity. Learn More To learn more about SQL Server migration enabled by Azure Arc, see: Migration Overview For information about migrating to SQL Server in Azure VM, see: Migrate to SQL Server in Azure VM
