Microsoft Data Migration Blog articles

Azure SQL Migration Starts in SSMS—All in One Flow

neelball — Wed, 15 Apr 2026 12:26:12 GMT

Migrate SQL Server Using SQL Server Management Studio (SSMS)

Migrating SQL Server workloads to Azure doesn’t have to be complex or fragmented. SQL Server Management Studio (SSMS) provides a guided, end-to-end migration experience that works seamlessly for both Azure Arc–enabled and standalone SQL Server instances.

In this blog, we’ll walk through how SSMS helps you assess, choose, and migrate your SQL Server workloads using the right Azure target and migration method.

One Tool, Multiple Migration Paths

SSMS acts as the central starting point for SQL Server migration:

Run readiness and compatibility assessments
Discover recommended Azure targets
Launch guided migrations using the right method for your scenario
Seamlessly connect to the Azure portal when needed

The experience adapts based on whether your SQL Server is Azure Arc–enabled or not.

Migrating Non‑Arc SQL Server (Local or On‑Premises)

If your SQL Server is not Arc-enabled, SSMS still gives you everything you need—starting locally and moving to Azure when appropriate.

Step 1: Run SQL Server Assessment in SSMS

SSMS performs a local assessment to:

- Evaluate database readiness
- Identify potential blocking issues
- Recommend supported Azure targets

Step 2: Provision the Target via Azure SQL Hub

From SSMS, you’re guided to Azure SQL Hub in the Azure portal to:

- Configure your migration target
- Select the right Azure SQL deployment option

Step 3: Choose the Right Migration Method

SSMS then walks you through guided migration experiences, tailored to your target:

🟦 Azure SQL Managed Instance

- MI Link – Near real-time migration with minimal downtime
- Backup & Restore – Simple, deterministic migrations

🟦 Azure SQL Database / Azure SQL VM / Other Targets

- Azure Database Migration Service (DMS)
  A guided, end-to-end migration experience supporting multiple Azure targets

SSMS helps ensure you’re choosing the right migration method for the right workload, without needing to switch tools manually.

Migrating Azure Arc–Enabled SQL Server

If your SQL Server is connected to Azure via Azure Arc, SSMS provides a streamlined experience that bridges on-premises management and Azure services.

What happens in SSMS?

When you start migration from SSMS for an Arc-enabled SQL Server:

- SSMS detects the Arc connection
- You’re redirected to the Azure portal for the migration flow
- Azure provides a centralized, cloud-based migration experience with deeper integration

This model is ideal if your organization is already using Azure Arc for governance, inventory, and centralized management.

Upgrade Readiness and Compatibility Checks

Planning to upgrade SQL Server or ensure compatibility with newer versions and Azure targets?

SSMS includes Upgrade Assessment, which helps you:

- Identify deprecated or breaking changes
- Understand feature compatibility
- Reduce risks before upgrading or migrating

This is especially useful when modernizing older SQL Server versions or preparing for cloud migration.

Putting It All Together

With SSMS, SQL Server migration becomes:

- Guided – No guesswork on tools or methods

- Flexible – Supports Arc and non‑Arc environments
- Integrated – Local assessment + Azure portal workflows
- Modern – Designed for hybrid and cloud-first strategies

Whether you’re migrating a single database or planning a large-scale modernization, SSMS provides a unified starting point to get you there with confidence.

What’s Next?

Start with Assessment in SSMS
Choose your Azure target
Migrate using MI Link, Backup/Restore, or DMS
Validate compatibility using Upgrade Assessment

SSMS isn’t just a management tool anymore—it’s your launchpad for SQL Server modernization.

Learn More - Migrate SQL Server to Azure SQL | Microsoft Learn

Expanding Azure Arc SQL Migration with a New Target: SQL Server on Azure Virtual Machines

danimir — Fri, 03 Apr 2026 22:55:58 GMT

Modernizing a SQL Server estate is rarely a single-step effort. It typically involves multiple phases, from discovery and assessment to migration and optimization, often spanning on-premises, hybrid, and cloud environments. SQL Server enabled by Azure Arc simplifies this process by bringing all migration steps into a single, cohesive experience in the Azure portal.

With the March 2026 release, this integrated experience is extended by adding SQL Server on Azure Virtual Machines as a new migration target in Azure Arc. Arc-enabled SQL Server instances can now be migrated not only to Azure SQL Managed Instance, but also to SQL Server running on Azure infrastructure, using the same unified workflow.

Expanding Choice Without Adding Complexity

By introducing SQL Server on Azure Virtual Machines as a migration target, Azure Arc now supports a broader range of migration strategies while preserving a single operational model. It becomes possible to choose between Azure SQL Managed Instance and SQL Server on Azure VMs without fragmenting migration tooling or processes.

The result is a flexible, scalable, and consistent migration experience that supports hybrid environments, reduces operational overhead, and enables modernization at a controlled and predictable pace.

One Integrated Migration Journey

A core value of SQL Server migration in Azure Arc is that the entire migration lifecycle is managed from one place. Once a SQL Server instance is enabled by Azure Arc, readiness can be assessed, a migration target selected, a migration method chosen, progress monitored, and cutover completed directly in the Azure portal.

This approach removes the need for disconnected tools or custom orchestration. The only prerequisite remains unchanged: the source SQL Server needs to be enabled by Azure Arc. From there, migration is fully integrated into the Azure Arc SQL experience.

A Consistent Experience Across Migration Targets

The migration experience for SQL Server on Azure Virtual Machines follows the same model already available for Azure SQL Managed Instance migrations in Azure Arc. The same guided workflow, migration dashboard, and monitoring capabilities are used regardless of the selected target.

This consistency is intentional. It allows teams to choose the destination that best fits their technical, operational, or regulatory requirements without having to learn a new migration process. Whether migrating to a fully managed PaaS service or to SQL Server on Azure infrastructure, the experience remains predictable and familiar.

Backup Log Shipping Migration to SQL Server in Azure VM

Migration to SQL Server on Azure Virtual Machines is based on backup and restore, specifically using log shipping mechanism. This is a well-established approach for online migrations that minimizes downtime while maintaining control over the cutover window.

In this model, database backups need to be uploaded from the source SQL Server to Azure Blob Storage. The migration engine will restore the initial full backup followed by ongoing transaction log and diff. backups. Azure Blob Storage acts as the intermediary staging location between the source and the target.

The Azure Blob Storage account and the target SQL Server running on an Azure Virtual Machine must be co-located in the same Azure region. This regional alignment is required to ensure efficient data transfer, reliable restore operations, and predictable migration performance.

Within the Azure Arc migration experience, a simple and guided UX is used to select the Azure Blob Storage container that holds the backup files. Both the selected storage account and the Azure VM hosting SQL Server must reside in the same Azure region.

Once the migration job is started, Azure Arc automatically restores the backup files to SQL Server on the Azure VM. As new log backups are uploaded to Blob Storage, they are continuously detected and applied to the target database, keeping it closely synchronized with the source.

Controlled Cutover on Your Terms

This automated restore process continues until the final cutover is initiated. When the cutover command is issued, Azure Arc applies the final backup to the target SQL Server on the Azure Virtual Machine and completes the migration.

The target database is then brought online, and applications can be redirected to the new environment. This controlled cutover model allows downtime to be planned precisely, rather than being dictated by long-running restore operations.

Getting started

To get started, Arc enable you SQL Server. Then, in the Azure portal, navigate to your Arc enabled SQL Server and select Database migration under the Migration menu on the left. For more information, see the SQL Server migration in Azure Arc documentation.

Azure Database Migration Service Expands to New Azure Regions

abku14 — Wed, 25 Feb 2026 06:49:37 GMT

As organizations continue to modernize their data estates and migrate to Azure, regional availability plays a critical role in meeting data residency, compliance, and performance requirements. We’re excited to announce the expanded regional availability of Azure Database Migration Service (DMS), making it easier for customers to migrate their databases to Azure closer to where their applications and users reside.

Newly Available Regions for DMS

Azure Database Migration Service is now generally available in the following Azure regions as part of our latest regional expansion:

Indonesia Central
Mexico Central
Poland Central
Spain Central
Taiwan North

With this expansion, customers can run their SQL Server migration from more geographies while continuing to benefit from Azure’s enterprise-grade security, reliability, and compliance offerings.

Refer: Product Availability by Region

What This Means for Customers

The expanded availability of Azure Database Migration Service enables customers to:

Accelerate cloud adoption for SQL Server and other supported database workloads

Standardize migrations at scale using a fully managed Azure-native service - DMS

Whether you’re planning a lift-and-shift, modernization, or phased migration strategy, DMS helps simplify and automate database migrations to Azure with minimal downtime.

Supported Migration Scenarios

In these newly available regions, Azure Database Migration Service supports key migration scenarios, including migrations:

To SQL Server on Azure VM (Online and offline)

To Azure SQL Managed Instance (Online and offline)

To Azure SQL Database (Offline)

To learn more about supported scenarios and prerequisites, visit the official documentation: 👉 https://learn.microsoft.com/azure/dms

What’s Next

We continue to expand Azure Database Migration Service to additional regions as Azure platform dependencies become available, ensuring more customers worldwide can migrate with confidence. Stay tuned for future region announcements as part of our ongoing investment in global migration readiness.

Release Announcement of SQL Server Migration Assistant (SSMA) v10.5

subhojitbasak — Thu, 12 Feb 2026 17:30:08 GMT

We’re pleased to announce the release of SQL Server Migration Assistant (SSMA) v10.5, delivering meaningful improvements across multiple flavours of SSMA to further simplify and de‑risk database modernization to Azure SQL and SQL Server.

This release focuses on expanding AI-assisted code conversion, improving conversion quality and reliability, and addressing key customer feedback from real-world large-scale modernization projects.

Here is a high-level overview of the features shipped as part of SSMA:

Introducing AI‑assisted Code Conversion with Microsoft Copilot in SSMA for SAP ASE

(SSMA for SAP ASE)

SSMA v10.5 introduces AI-assisted code conversion powered by Microsoft Copilot for SAP ASE (Sybase)—bringing the same modern Copilot experience already available in SSMA for Oracle to Sybase migrations.

With this capability, customers can now use Copilot to accelerate conversion of complex Sybase T‑SQL objects like procedures, functions, triggers, and other database objects to SQL Server and Azure SQL–compatible code.

Key highlights

AI-assisted modernization: Copilot helps generate higher-quality converted code, reducing manual remediation effort. The conversion efficiency improves by ~30% using Copilot.
Designed for complex workloads: Particularly useful for large, business-critical Sybase ASE applications. During migration, these complex workloads often face a huge number of errors which can be dealt using Copilot.
Consistent Copilot experience: The Sybase Copilot workflow mirrors the Oracle-to-SQL Copilot experience, ensuring a familiar and intuitive user flow.

Please find a link to the detailed blog covering supported scenarios, and best practices for using SSMA Sybase Copilot.

Improved Code Conversion Quality for Oracle with Support for Larger Source Scripts

(SSMA for Oracle)

In SSMA v10.5, the Oracle PL/SQL to T‑SQL Code Conversion Copilot has been enhanced to support larger source scripts, enabling customers to convert more complex and sizable PL/SQL packages with improved reliability. We have doubled the size of the input tokens to accommodate larger code. We have also significantly increased the limit of output tokens for accurate explanations.

These enhancements help reduce the need to manually split large scripts and improve end-to-end conversion efficiency for enterprise-scale Oracle workloads.

Improved Reliability of Oracle PL/SQL Conversions on Azure SQL Managed Instance

(SSMA for Oracle)

SSMA 10.5 improves the reliability of running Oracle PL/SQL–to–T‑SQL converted procedures on Azure SQL Managed Instance by updating the SSMA for Oracle extension components used to support Oracle compatibility behaviors (for example, autonomous transaction patterns).

These updates strengthen connection handling to align with newer security and encryption defaults in the target environment, helping reduce runtime connection interruptions during procedure execution.

The improvements are included as part of SSMA 10.5, so customers can benefit without requiring manual workarounds or additional configuration changes.

Additional Fixes and Improvements

SSMA v10.5 also includes several smaller but impactful fixes across flavors:

SSMA for Access: Improved reliability of Windows login resolution during migrations.
General stability and usability improvements across assessment and conversion workflows.

Download SSMA v10.5

Get the latest versions of SQL Server Migration Assistant v10.5:

SSMA Copilot for SAP ASE (Sybase)

subhojitbasak — Thu, 12 Feb 2026 08:01:30 GMT

Introduction

SAP ASE (formerly Sybase) continues to power mission‑critical workloads across financial services, telecom, and large-scale enterprise applications. However, as modernization accelerates, more customers are actively seeking reliable and automated paths to migrate Sybase workloads to Microsoft SQL Server and Azure SQL Targets.

While Sybase’s T-SQL dialect shares several similarities with Microsoft SQL Server, its procedural code contains deep complexities—extended syntax, non-standard constructs, legacy system tables, and database‑scoped behaviors that often break traditional rule-based converters. These nuances make stored procedures, triggers, and packages some of the hardest assets to migrate.

To address these challenges, the SQL Migration team is expanding Copilot-based code conversion capabilities to SSMA SAP ASE, following the same intuitive user flow as the Oracle-to-SQL Copilot released earlier. This new AI-assisted experience dramatically reduces manual fix-up effort, boosts conversion accuracy, and empowers users to modernize complex Sybase assets with confidence.

Why We Built This

SSMA’s rule engine already auto-converts a significant portion of Sybase code—typically around 70% for standard workloads. But rule-based systems hit limitations when faced with:

Proprietary Sybase syntax variations
Conditional logic or cursors expressed in non-standard forms
System-level commands not supported in SQL Server
Ambiguous constructs requiring contextual interpretation

These gaps often force users into tedious manual rewriting.

By bringing agentic AI into the equation, Copilot attempts to fill the missing 30%—providing syntactically correct, context-aware, and fully explained code conversions. Instead of relying solely on static rules, Copilot understands intent, identifies root-causes of failures, and generates SQL Server-compatible alternatives with transparent reasoning.

This combination of deterministic rule engine + adaptive AI unlocks a far more complete, scalable, and user-friendly migration experience.

Authentication Methods

SSMA for SAP ASE offers two simple ways to authenticate with Copilot, giving customers flexibility based on their security and infrastructure needs.

Option 1: Bring Your Own Key (Azure OpenAI)
Connect SSMA to your own Azure OpenAI resource using your deployment details and key. This option is ideal for organizations that already manage Azure OpenAI or require strict control over their AI environment.

Option 2: Microsoft‑Managed Endpoint (Preview)
A new, seamless experience where no API key is needed. Users simply sign in with Microsoft Entra ID, and SSMA handles authentication through a secure browser-based flow.

For detailed setup steps and prerequisites for both authentication options, refer to the SSMA Copilot Learn documentation.

What Copilot Offers

When the “Fix with Copilot” button is triggered, SSMA opens a structured tri-pane experience designed for clarity and trust:

1. Errors to Fix

Shows issues that the rule engine could not convert—whether due to unsupported syntax, parse failures, or ambiguous constructs.
This helps users quickly understand where the rule engine struggled.

2. Explanation

Provides a detailed, human-readable breakdown of:

Why the conversion failed
What the Copilot-generated fix means
How the logic differs from Sybase to SQL Server

This section builds trust, making AI-generated code fully interpretable.

3. Code Review Window

Displays a side-by-side diff:

Left: SSMA-generated output
Right: Copilot-converted SQL code

Changes are highlighted so users can validate improvements, understand transformations, and decide whether to apply the Copilot output.

From an implementation and architecture point of view, this is similar to SSMA Oracle to SQL Code Conversion Copilot. To know more about how the AI model has been trained, refer to this blog.

Sample Use Case (as illustrated in the GIF)

In the example shown in the blog GIF, a Sybase stored procedure fails conversion because:

It uses set switch on drop_system_tables with override, no_info—a Sybase-only command unsupported in SQL Server.
The procedure definition contains create or replace procedure, which is not valid T‑SQL syntax.
The rule engine cannot parse the affected block, causing SSMA to output the original Sybase procedure as a commented fallback.

When Copilot is invoked:

It identifies the unsupported keywords
Suggests correct SQL Server equivalents (e.g., translating create or replace into IF EXISTS ... DROP + CREATE PROCEDURE)
Generates a complete, runnable T‑SQL procedure
Explains why each fix was made

This allows users to resolve previously conversion‑blocking issues instantly.

To learn more, Copilot in SSMA

Real‑World Impact

With SSMA’s SAP ASE Copilot, teams can migrate Sybase workloads with significantly less manual effort. Developers, DBAs, and architects gain:

Faster conversion cycles
Higher code accuracy
Clear explanations that improve learning and long-term maintainability
Independence from long, multi-step manual rewrite processes

This Copilot experience transforms complex procedural conversions into guided, high-confidence workflows—making modernization more accessible for organizations of all sizes.

Alternatives After the Deprecation of the Azure SQL Migration Extension in Azure Data Studio

abku14 — Tue, 03 Feb 2026 08:18:54 GMT

The Azure SQL Migration extension for Azure Data Studio is being deprecated and will be retired by February 28, 2026. As part of our unified and streamlined migration strategy for Azure SQL, we are consolidating all migration experiences into a consistent, scalable platform.

If you are currently using the Azure SQL Migration extension, this blog will guide you through recommended replacement options for every phase of migration, whether you are moving to Azure SQL Managed Instance, SQL Server on Azure Virtual Machines, or Azure SQL Database.

What is happening to the Azure SQL Migration extension in ADS?

As you already know, Azure data studio will officially retire on February 28, 2026. The Azure SQL Migration extension in Azure Data Studio will also retire along with Azure Data Studio on February 28, 2026. The Azure SQL Migration extension will no longer be available in the marketplace of Azure Data Studio.

What should you use instead?

Below is the updated guidance for the migration tool categorized by migration phase and target.

1) Pre‑Migration: Discovery & Assessments

Prior to migration, it is advisable to evaluate the SQL Server environment for readiness and to determine the right-sized Azure SQL SKU. Below are the recommended options:

A) SQL Server enabled by Azure Arc

Use the SQL Server migration experience in the Azure Arc portal for:

1. Instance discovery at scale
2. Migration assessments at scale, including:

- - Readiness assessment for all Azure SQL targets.
  - Performance-based, right-sized target recommendations.
  - Projected Azure costs with the recommended target configuration.

Reference:

Steps to get started with the Azure Arc assessments-

1. Deploy Azure Arc on your servers.
2. SQL Server instances on Arc-enabled servers are automatically connected to Azure Arc. See options to optimize this.

B) Automated assessments at scale using Azure DMS PowerShell and Azure CLI

The Azure DataMigration modules in Azure PowerShell and Azure CLI can be used to automate assessments at scale. Learn more about how to do this.

Here are the sample templates to automate the assessment workflow:

1. Azure PowerShell DataMigration cmdlets
2. DMS Azure CLI commands

C) Azure Migrate

For scenarios where assessments are required at data center level including different types of workloads like Applications, VM Servers and databases, use Azure Migrate to perform discovery and assessments at scale. Learn more about Azure Migrate.

References:

2) Migrations

Based on the migration targets, here are the recommended tools you can use to carry out the migration:

A. To Azure SQL Managed Instance

The following options are available for migrating data to Azure SQL Managed Instance:

1. SQL Migration experience in Azure Arc

For migrations to Azure SQL MI, leverage the streamlined SQL Migration experience in Azure Arc which lets you complete the end-to-end migration journey in a single experience.

This experience provides:

- - Evergreen assessments and right-fit Azure SQL target recommendation.
  - Inline Azure SQL Target creation.
  - Free Azure SQL MI Next generation General Purpose service that lets you experience the power of Azure SQL MI for free for 12 months.
  - Near zero downtime migration using Managed Instance link powered by Distributed Availability Group technology.
  - Secure connectivity.

Reference blog: SQL Server migration in Azure Arc

2. Automated migration at scale using Azure DMS PowerShell and Azure CLI

To Orchestrate migrations to Azure SQL MI at scale programmatically, use:

- - DMS PowerShell cmdlets
  - DMS Azure CLI commands

Learn more about how to do this.

B. To SQL Server on Azure Virtual Machines

To migrate to SQL Server on Azure Virtual Machines, use:

1. Azure Database Migration Service (DMS)

DMS supports migrating to SQL Server on Azure Virtual Machines using both online and offline methods. Your SQL Server backups can be in Azure Blob Storage or on a network SMB file share. For details on each option, see:

- - Backups stored in Azure Blob Storage
  - Backups maintained on network SMB file shares

Note: The migration experience from SQL Server on-premises to SQL Server on Azure VM will soon be available in SQL Server enabled by Azure Arc.

2. Automated migration at scale using Azure DMS PowerShell and Azure CLI

For programmatic migrations to Azure SQL Virtual Machines:

- - DMS PowerShell cmdlets
  - DMS Azure CLI commands

Learn more about how to do this.

3. SSMS option: SQL Server Management Studio (SSMS) migration component

If you can connect to both SQL Server on-premises and SQL Server running on Azure VM using SQL Server Management Studio, the migration component in SSMS can help you to migrate to SQL Server on Azure VM.

For details, see SSMS Migration component.

C. To Azure SQL Database

Migrating a SQL Server database to Azure SQL Database typically involves migrating schema and data separately. Here are the options to perform offline and online migration to Azure SQL Database:

1. Offline migration to Azure SQL Database

a. Azure Database Migration Service (DMS) portal experience

Use Azure DMS portal to migrate both schema and data. Azure DMS uses Azure Data Factory and leverages the Self-hosted Integration Runtime (SHIR). Installation steps are here.

b. Automated migration at scale using Azure DMS PowerShell and Azure CLI

Use Azure DMS PowerShell and Azure CLI command line to orchestrate the schema and data migration to Azure SQL Database at scale:

- - DMS PowerShell cmdlets
  - DMS Azure CLI commands

Learn more about how to do this.

2. Online migration to Azure SQL Database

Using Striim

To enable online migration of your mission critical databases to Azure SQL Database leverage Striim. Microsoft and Striim have entered a strategic partnership to enable continuous data replication from off-Azure SQL Servers to Azure SQL Database with near-zero downtime.

For more details, refer to:

- - Zero downtime migration from SQL Server to Azure SQL Database | Microsoft Community Hub
  - Removing barriers to migrating databases to Azure with Striim’s Unlimited Database Migration program...

To leverage the Striim program for migrations, please reach out to your Microsoft contact or submit the below feedback to get started.

Summary

The table below provides a summary of the available alternatives for each migration scenario.

Migration Scenario	Guided experience	Automation experience
Pre-Migration (Discovery + Assessment)	SQL Migration experience in Azure Arc / Azure Migrate	DMS PowerShell / Azure CLI
To Azure SQL Managed Instance	SQL Migration experience in Azure Arc	DMS PowerShell / Azure CLI
To SQL Server on Azure Virtual Machine	DMS Azure Portal / SSMS migration component	DMS PowerShell / Azure CLI
To Azure SQL Database	DMS Azure portal (offline & schema migration) / Striim (online migration)	DMS PowerShell / Azure CLI (offline & schema migration)

Final Thoughts

Simplify your SQL migration journey and improve migration velocity to all Azure SQL targets, leverage the connected migration experiences in SQL Server enabled by Azure Arc, DMS, and SSMS.

For SSMS, as a first step we brought the capabilities to perform assessment and migration to higher versions of SQL Server including to SQL Server on Azure Virtual Machines. As a next step, we are bringing cloud migration capabilities as well into SSMS.

Feedback

We love hearing from our customers. If you have feedback or suggestions for the product group, please use the following form:

Feedback form

As you begin your migration to Azure, we welcome your feedback. If you do not see suitable alternatives for any migration phases, use the feedback form to let us know so we can update the options accordingly.

Deep dive into the SSMA Code Conversion Copilot Architecture

subhojitbasak — Mon, 19 Jan 2026 10:53:13 GMT

The Problem We Set Out to Solve

Migrating from Oracle PL/SQL to SQL Server T‑SQL is notoriously complex. While SSMA’s rule engine covers hundreds of conversion rules, edge cases, custom logic, and nuanced syntax but it often slips through. Developers end up spending hours manually fixing scripts, validating correctness, and worrying about regressions.

The Copilot was built to tackle this pain point: augment SSMA’s rule engine with large language models (LLMs) that can reason about tricky conversions, explain their logic, and accelerate the migration process. But building trust in AI‑generated code meant we had to design an architecture that was controllable, reliable, and secure.

SSMA Code Conversion Copilot was released back in the month of May and some of the use cases are elaborated here. This blog talks about the inner working of Copilot.

⚙️ Semantic Kernel for Skill / Plugin Management

At the heart of SSMA Copilot lies Semantic Kernel, Microsoft’s open‑source framework for integrating LLMs. It offers two big capabilities:

Prompt management — defining prompts as reusable “skills” with parameters like model, temperature, and token count.
Agentic orchestration — automating workflows by chaining tools and prompts together.

For Copilot, we deliberately chose only prompt management at this point. We have also added native skills such as checking the correctness of syntax and semantics but have not used agentic orchestration for the current implementation.

❌ Why Not Agentic Features?

Agentic orchestration can be powerful, but in practice it wasn’t reliable enough for production migrations. Tool selection logic sometimes failed, leading to incorrect validations or spurious edits. Moreover, we saw an issue with latency. Instead, we implemented a deterministic workflow that gave us full control.

✅ Manual Orchestration Workflow

Our workflow looks like this (please refer to the diagram):

Partial Migration: SSMA generates a baseline conversion.
Copilot Authentication: The Copilot is authenticated using the inputs provided by the user. This is where the model is also decided. Alternately, the user can use the managed endpoint that is controlled by Microsoft.
LLM Completion: Copilot fills in gaps. Moreover, it explains the solution, points out the error that it is trying to resolve in simple language.
Parsing & Compilation: A target‑dialect parser checks syntax. This catches unsupported constructs or binding issues far more reliably than prompt tuning.
Spurious Edit Detection: LLMs are instructed to only enhance flagged portions of code. Any edits to “correct” blocks incur penalties, with a strict threshold of zero spurious edits allowed.
Query Execution & Data Generation: Where possible, we generate minimal synthetic data (two rows per table) to validate equivalence between source and target queries.
Semantic Equivalence Checks: For cases where execution isn’t feasible, we use LLM‑based scoring to judge logical fidelity.

This loop repeats until syntactic and semantic correctness is achieved. By using this workflow, we avoided regression spirals and ensured predictable outcomes across dialects. This workflow was tested using our built-in evaluation framework which has leveraged the rich test cases of SSMA.

🔑 Feature Comparison

Managed Endpoint Authentication was released with SSMA 10.4 in November 2025.

	Managed Endpoint	BYOK
Provisioning OpenAI Endpoint	No	Yes
LLM Model Selection	Automatic	Manual
Authentication	Mandatory Entra ID	OpenAI Endpoint and Key
Private Endpoint Support	No	Yes
Cross Tenant Dependency*	Yes	No
Pricing	Free	Consumption in actuals

*Cross Tenant Dependency: The endpoint is hosted in Microsoft tenant while the authentication happens in the user tenant.

🔒 Privacy and Data Handling

A critical point: we don’t store your data. The scripts you provide are used only for generating the migration output. Once the process completes, the data is flushed. No proprietary code or schema information is retained.

This design ensures:

Security: We run OpenAI in Microsoft tenant following all security protocols.
Trust: Copilot is a tool, not a repository.
Compliance: Aligns with enterprise privacy expectations.

🌟 Why This Matters

By combining Semantic Kernel framework, SSMA Copilot delivers reliable migrations without sacrificing flexibility. And with the managed endpoint, it’s now easier and safer than ever to adopt — no keys, no storage, no friction.

This isn’t just about faster migrations. It’s about building trust in AI‑assisted workflows, ensuring correctness, and giving enterprises confidence that their data is secure.

Get started with your Copilot based migration journey using SSMA for Oracle

Zero downtime migration from Oracle to Azure SQL

Sudhir_Raparla — Tue, 13 Jan 2026 20:02:19 GMT

Modernizing mission-critical Oracle applications often involves moving underlying Oracle databases into a fully managed cloud service with near zero downtime. For many organizations, Azure SQL provides the reliability, scale, and operational simplicity needed to support modern application architectures while also unlocking tighter integration with Azure analytics, security, and AI services.

The hard part was getting there. Oracle databases tend to be large, complex, with demanding high availability business SLAs, making it difficult to migrate them to Azure SQL without planned downtime, risk of data drift, or operational disruption.

To remove these barriers, Microsoft and Striim partnered together to offer a real-time migration solution built on log-based Change Data Capture (CDC). As part of the Microsoft Unlimited Database Migration Program, this solution empowers enterprises to modernize to Azure faster, with confidence, while paving the way for AI-ready architectures and long-term innovation.

This tutorial walks through the architecture, deployment steps, and best practices for Oracle to Azure SQL migrations using Striim.

Microsoft + Striim for seamless migration

The strategic partnership between Microsoft and Striim enables continuous data replication from existing databases into Azure in real time, enabling online migrations with zero downtime. Through this Unlimited Database Migration Program, customers gain unlimited Striim licenses to migrate as many databases as they need at no additional cost.

Program highlights include:

Zero-downtime, zero-data-loss migrations across SQL Server, Oracle, MySQL, PostgreSQL, Azure SQL and more.
Support for migration of heterogeneous, mission-critical workloads across relational and non-relational systems.

With Striim, data moves continuously via log-based CDC, reading directly from Oracle transaction logs and replicating every insert, update, and delete to Azure in real time. This minimizes impact on production systems while maintaining full data consistency during migration.

Architecture Overview

The jointly recommended architecture consists of:

Source: an existing Oracle instance (on-premises or hosted in another environment).
Processing Layer: Striim, deployed in Azure for low-latency, secure data movement.
Target: Azure Database for SQL (Flexible Server or Single Server)

Connectivity is established over standard Oracle (1521) and SQL (1433) ports and can also utilize other configured ports. This solution also offers Private Link support, VNets, and other native Azure networking controls to secure traffic throughout migration.

Step 1: Preparing the Oracle Source

Before replication can begin, configure Oracle so that redo logs are accessible and a CDC user can be used by Striim.

Striim supports multiple CDC methods for Oracle:

Oracle Reader (LogMiner): Uses Oracle’s LogMiner API to read from redo logs. This is the default method.
OJet: A high-performance CDC method, typically used for Oracle 21c or very high-volume workloads that generate large amounts of redo logs.
GoldenGate trail files: If Oracle GoldenGate is already present, Striim can read from existing GoldenGate trail files rather than attaching another CDC process directly to the source database.

All options are log-based, ensuring CDC overhead is typically in the low single-digit percentage range.

Once chosen, ensure Striim can connect to Oracle over the JDBC listener port (default 1521). If Oracle is on-premises, this typically involves VPN/ExpressRoute or an SSH tunnel/jump host from Striim to the Oracle network before you can create a CDC user in Striim.

Creating a CDC user (example)

As an Oracle user, create a dedicated account for Striim and grant the required privileges for redo log access (exact grants may vary by version and CDC method). Please reference Striim’s Oracle CDC docs for the latest instructions:

CREATE USER striim_user IDENTIFIED BY "StrongPassword!"; GRANT CONNECT, RESOURCE TO striim_user; -- Example privileges for redo/log views (adjust per security and Striim docs) GRANT SELECT ANY TRANSACTION TO striim_user; GRANT SELECT ON V_$LOG TO striim_user; GRANT SELECT ON V_$LOGFILE TO striim_user; GRANT SELECT ON V_$ARCHIVED_LOG TO striim_user; GRANT SELECT ON V_$DATABASE TO striim_user;

Once the user is created and networking is in place, Striim can be configured to connect to Oracle using a JDBC URL such as:

jdbc:oracle:thin:@//<oracle-host>:1521/<service_name>

Step 2: Preparing Azure SQL

On the target side, you must provision the right Azure SQL target and ensure schema, networking, and permissions are in place before starting data movement.

Schema creation

Prior to starting the data movement pipelines, create tables in Azure SQL corresponding to those in the Oracle source. This can be done with:

SQL Server Migration Assistant for Oracle: Helps with the conversion and deployment of Oracle schema objects including tables, views, indexes and also helps with converting the programmatic SQL objects like PL/SQL procedures, functions and packages.
Striim’s Schema Conversion Utility (CLI): Generates SQL DDL for the target system based on Oracle metadata.
Striim’s wizard-based schema creation: Creates target tables directly from the Striim UI during pipeline configuration.External tools: You can also use existing schema migration utilities or custom DDL as required.

Permissions

Create an Azure SQL user for Striim with write privileges on the target tables. Here is an example script to create a user on Azure SQL:

CREATE USER striim_user WITH PASSWORD 'strongpassword'; GRANT INSERT, UPDATE, DELETE, SELECT ON ALL TABLES IN SCHEMA public TO striim_user; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT INSERT, UPDATE, DELETE, SELECT ON TABLES TO striim_user;

Striim will use this user when running Database Writer components against Azure SQL.

Step 3: Building the migration pipeline

A complete Oracle to Azure Database for SQL migration typically includes three coordinated stages:

Schema Migration – Create equivalent tables and objects in Azure SQL.
Initial Load – Bulk-load historical data from Oracle into Azure.
Change Data Capture (CDC) – Continuously stream real-time transactions, keeping source and target in-sync until production cutover.

Initial load & continuous stream

Once the schema is in place using one of the methods above, you can configure Striim to first bulk-load historical data, then switch to continuous CDC.

During the initial load, Striim uses a Database Reader component to extract full tables from Oracle, and a Database Writer component to load them into Azure SQL. The Striim applications can be built through a drag-and-drop interface, a wizard, or through a text-based interface, shown below.

The Database Writer uses a user-defined batch policy to control how data is written. By default (e.g., EventCount:1000, Interval:60s), Striim will write to SQL when either 1,000 events are accumulated or 60 seconds have passed, whichever happens first.

A conceptual example of an initial-load configuration using TQL might look like:

CREATE SOURCE OracleInitialLoadReader USING DatabaseReader ( Username:'striim_user', Password:'strongpassword', ConnectionURL:'jdbc:oracle:thin:@//oracle-host:1521/ORCL', Tables:'HR.EMPLOYEES' ); CREATE TARGET SQLInitialLoadWriter USING DatabaseWriter ( Username:'striim_user', Password:'strongpassword', ConnectionURL:'jdbc:SQL://pg-host:5432/mydb', Mode:'Insert', BatchPolicy:'EventCount:10000,Interval:30s' ) INPUT FROM OracleInitialLoadReader;

Continuous CDC stream

After the initial load completes, Striim switches to a CDC pipeline that applies new Oracle transactions in real time until cutover. The CDC pipeline uses an Oracle CDC reader (Oracle Reader, OJet, or GoldenGate trail reader) and a Database Writer targeting Azure SQL.

A CDC example in T-SQL could look like:

CREATE SOURCE OracleCDCReader USING OracleReader ( Username:'striim_user', Password:'strongpassword', ConnectionURL:'jdbc:oracle:thin:@//oracle-host:1521/ORCL', Tables:'HR.EMPLOYEES' ); CREATE TARGET SQLCDCWriter USING DatabaseWriter ( Username:'striim_user', Password:'strongpassword', ConnectionURL:'jdbc:SQL://pg-host:5432/mydb', Mode:'UpdateOrInsert', BatchPolicy:'EventCount:1000,Interval:60s' ) INPUT FROM OracleCDCReader;

To ensure zero data loss, follow the sequencing guidelines in Striim’s documentation for switching from initial load to continuous replication.

Cutover

When the Azure SQL environment is fully synchronized, and you are ready to move applications off Oracle:

Pause writes to Oracle. Temporarily stop application writes to the source.
Validate record counts. Compare row counts (and optionally checksums or spot checks) between Oracle and Azure SQL. Striim has recently released a new tool called Validata to automatically do this. Please reach out to learn more.
Redirect application traffic to Azure SQL. Update connection strings so applications now point at the Azure SQL instance.

Because Striim’s CDC keeps the source and target continuously in sync, the cutover window is typically very short, minimizing or eliminating downtime for end users.

Adding Transformations and Smart Data Pipelines

Beyond one-to-one replication, Striim allows you to enrich, transform, and validate data in flight using continuous SQL queries or custom Java processors. For example, you can append metadata for auditing:

SELECT *, CURRENT_TIMESTAMP() AS event_time, OpType() AS operation FROM SQLServerStream;

These Smart Data Pipelines enable in-stream transformations (e.g., deduplication, validation, or enrichment) without separate ETL jobs, streamlining modernization into a single continuous flow.

Performance Expectations

In joint Striim–Microsoft testing:

1 TB historical load typically completed in 4–6 hours, which can be further performance-tuned to decrease initial load time.
CDC replication latency averages sub-second for inserts, updates, and deletes.

Performance depends on schema complexity, hardware, and network configuration. For optimal results:

Deploy Striim in the same Azure region as the target.
Use private networking.
Allocate adequate CPU and memory to handle peak CDC throughput.

Support and Enablement

The Microsoft Unlimited Database Migration Program is designed specifically to provide customers direct access to Striim’s field expertise throughout the migration process.

From end-to-end, you can expect:

Onboarding and ongoing support, including installation kits and walkthroughs.
Higher-tier service packages are available as well.
Direct escalation paths to Striim for issue resolution and continuous assistance during migration and replication.
Professional services and funding flexibility, such as ECIF coverage for partner engagements, cutover or weekend go-live standby, and pre-approved service blocks to simplify SOW approvals.

Together, these resources ensure migrations from Oracle to Azure DB for SQL are fully supported from initial enablement through post-cutover operations, backed by Microsoft and Striim’s combined teams.

Whether your goal is one-time migration or continuous hybrid replication, Striim’s CDC engine, combined with Azure’s SQL Database, ensures every transaction lands with integrity. Start your modernization journey today by connecting with Striim directly through your Microsoft representative.

Zero downtime migration from SQL Server to Azure SQL Database

Sudhir_Raparla — Fri, 23 Jan 2026 12:34:27 GMT

For many enterprises, moving SQL Server workloads to Azure SQL Database is a critical step in their journey to cloud modernization. Yet, migrating mission-critical databases without disrupting operations can be challenging. Downtime, data drift, and performance validation often introduce unnecessary risk and complexity.

With Striim and Microsoft Azure, those challenges become manageable. Striim’s log-based Change Data Capture (CDC) continuously streams every SQL Server transaction into Azure SQL Database in real time to deliver zero-data-loss migration, continuous validation, and minimal impact on live applications.

As part of the Microsoft Unlimited Database Migration Program, Striim is optimized to help organizations accelerate and de-risk their journey to Azure by combining enterprise-grade CDC technology, architectural best practices, and hands-on partner expertise.

This tutorial walks through the key setup steps and configurations for migrating from SQL Server (on-premises or in another cloud) to all SKUs of Azure SQL Database including Hyperscale using Striim.

Why Use Striim for Continuous Migration

In our previous blogpost about Microsoft's unlimited data migration program, we talked about how unlimited partnership between Microsoft and Striim enables continuous data replication from existing databases into Azure in real time, enabling online migrations with zero downtime. Through this Microsoft Unlimited Database Migration Program, customers gain unlimited Striim licenses to migrate as many databases as they need at no additional cost.

Program highlights include:

Online migration capabilities from SQL Server to Azure SQL DB, Zero-downtime, zero-data-loss migrations across SQL Server, Oracle, MySQL, PostgreSQL, Azure SQL and more.
Support for heterogeneous, mission-critical workloads across relational and open-source systems.
Real-time, AI-ready data pipelines, preparing workloads for analytics and ML once migrated.

With Striim, data moves continuously via log-based CDC, reading directly from SQL Server transaction logs and replicating every insert, update, and delete to Azure in real time. This minimizes impact on production systems while maintaining full data consistency during migration.

Architecture Overview

A typical SQL Server → Azure SQL Database setup includes three components:

Source: an existing SQL Server instance (on-premises or hosted in another environment).
Processing Layer: Striim, deployed in Azure for low-latency, secure data movement.
Target: Azure SQL Database (Hyperscale, Business Critical and General Purpose SKUs).

Data flows securely from SQL Server → Striim → Azure SQL Database over port 1433. For production environments, Azure Private Link or private endpoints are recommended to avoid public internet exposure.

Preparing the SQL Server Source

Before replication can begin, ensure Change Data Capture (CDC) is enabled for your database and tables. Run the following commands as a user with sysadmin privileges:

USE master; EXEC sys.sp_cdc_enable_db; GO USE <your_database>; EXEC sys.sp_cdc_enable_table @source_schema = N'dbo', @source_name = N'<table_name>', @role_name = NULL; GO -- Then, create a user account for Striim with access to the transaction logs: CREATE LOGIN striim_user WITH PASSWORD = 'strongpassword'; CREATE USER striim_user FOR LOGIN striim_user; GRANT SELECT, VIEW DATABASE STATE, VIEW SERVER STATE TO striim_user;

Within Striim, configure the MS SQL Reader or MSJet Reader component:

MS SQL Reader – uses Microsoft’s native CDC implementation (shadow tables). Easiest to deploy and supported out of the box.
MSJet Reader – Striim’s proprietary high-performance log reader. Reads directly from transaction log files on disk for minimal overhead.

This log-based approach ensures a low single-digit CPU overhead on the source system while continuously streaming every change event.

Building the Migration Pipeline

A complete migration typically includes three coordinated stages:

Schema Migration – create equivalent tables in Azure SQL Database.
Initial Load – bulk-load historical data from SQL Server to Azure.
Change Data Capture (CDC) – continuously stream real-time transactions until the systems are fully synchronized.

Schema Migration

Before starting the data pipeline, ensure your target Azure SQL Database has the required schema.

To migrate the schema from SQL Server to Azure SQL DB you can use either Striim or Azure Database Migrate Service (DMS).

Striim provides two schema creation methods:

Schema Conversion Utility (CLI): automatically generates DDL statements from the source.
Wizard-based creation: directly builds tables and schemas in the Striim UI.

Azure Database Migration Service provides two options for schema migration:

In the DMS portal, while you select the database tables to migrate, select the checkbox against Migrate missing schema option. This will automatically migrate the schema of the table and the dependent objects like indexes, triggers, views etc.
You can use Azure Database Migrate Service PowerShell and Azcmdlets to migrate schema.

Please note, with both these options you need db_owner permissions on the target database to perform schema migration.

Next, create a SQL user with write access to the target database:

CREATE LOGIN striim_user WITH PASSWORD = 'strongpassword'; CREATE USER striim_user FOR LOGIN striim_user; ALTER ROLE db_datareader ADD MEMBER striim_user; ALTER ROLE db_datawriter ADD MEMBER striim_user;

Ensure Striim can connect to Azure SQL Database over port 1433. For security, use private endpoints and configure appropriate firewall and VNet rules.

Initial Load & Continuous stream

During the initial load, Striim uses a Database Reader to extract full tables and a Database Writer to load them into Azure SQL Database. Once complete, switch to the CDC pipeline, which applies new transactions in real time until cutover. To ensure zero data loss, follow the sequencing guidelines in Striim’s switch-over documentation.

Cutover

When ready to cut over:

Pause writes to SQL Server.
Validate record counts between source and target.
Redirect application traffic to Azure SQL Database.

Building migration pipelines in Striim

Striim provides several ways to build migration pipelines:

Wizards: pre-built templates for SQL Server → Azure SQL Database.
Visual Designer: a drag-and-drop interface for customized flows.
TQL Scripts: programmatic creation of applications for CI/CD pipelines.

Each pipeline is defined by a TQL file, which can be version-controlled and deployed through REST APIs for repeatable infrastructure-as-code workflows.

Adding Transformations and Smart Data Pipelines

SELECT *, CURRENT_TIMESTAMP() AS event_time, OpType() AS operation FROM SQLServerStream;

These Smart Data Pipelines enable in-stream transformations (e.g., deduplication, validation, or enrichment) without separate ETL jobs, streamlining modernization into a single continuous flow.

Performance Expectations

In joint Striim–Microsoft testing:

1 TB historical load typically completed in 4–6 hours.
CDC replication latency averages sub-second for inserts, updates, and deletes.

Performance depends on schema complexity, hardware, and network configuration. For optimal results:

Deploy Striim in the same Azure region as the target.
Use private networking.
Allocate adequate CPU and memory to handle peak CDC throughput.

Support and Enablement

The Microsoft Unlimited Database Migration Program is designed specifically to provide customers direct access to Striim’s field expertise throughout the migration process.

From end-to-end, you can expect:

Onboarding and ongoing support, including installation kits and walkthroughs.
Higher-tier service packages are available as well.
Direct escalation paths to Striim for issue resolution and continuous assistance during migration and replication.
Professional services and funding flexibility, such as ECIF coverage for partner engagements, cutover or weekend go-live standby, and pre-approved service blocks to simplify SOW approvals.

Together, these resources ensure migrations from SQL Server On-Premise to Azure SQL DB are fully supported from initial enablement through post-cutover operations, backed by Microsoft and Striim’s combined field teams.

Removing barriers to migrating databases to Azure with Striim’s Unlimited Database Migration program

Shireesh_Thota — Wed, 19 Nov 2025 02:44:13 GMT

Alok Pareek, co-founder and Executive Vice President of Product and Engineering at Striim
Shireesh Thota, Corporate Vice President of Databases at Microsoft

Every modernization strategy starts with data. It’s what enables advanced analytics and AI agents today, and prepares enterprises for what’s to come in the future.

But before services like Microsoft Fabric, Azure AI Foundry, or Copilot can create that value, the underlying data needs to move into Microsoft’s cloud platforms. It’s within that first step, database migration, where the real complexity often lies.

To simplify the process, Microsoft has expanded its investment in the Striim partnership. Striim continuously replicates data from existing databases into Azure in real time, enabling online migrations with zero downtime.

Through this partnership, we have collaborated to enable modernization and migration into Azure at no additional cost to our customers. We’ve designed this Unlimited Database Migration program to accelerate adoption by making migrations easier to start, easier to scale, and easier to complete, all without disrupting business operations.

Since launch, this joint program has already driven significant growth in customer adoption, indicating the demand for faster, more seamless modernization. And with Microsoft’s continued investment in this partnership, enterprises now have a proven, repeatable path to modernize their databases and prepare their data for the AI era.

Watch or listen to our recent podcast episode (Apple Podcasts, Spotify, YouTube) to learn more.

Striim’s Unlimited Migration Program

Striim’s Unlimited Database Migration Program was designed to make modernization as straightforward as possible for Microsoft customers. Through this initiative, enterprises gain unlimited Striim licenses to migrate as many databases as they need at no additional cost. Highlights and benefits of the program include:

Zero-downtime, zero-data-loss migrations. Supported sources include SQL Server, MongoDB, Oracle, MySQL, PostgreSQL, and Sybase. Supported targets include Azure Database for MySQL, Azure Database for PostgreSQL, Azure Cosmos DB, and Azure SQL.
Mission-critical, heterogeneous workloads supported. Applies for SQL, Oracle, NoSQL, OSS.
Drives faster AI adoption. Once migrated, data is ready for analytics & AI.

Whether moving SQL Server, Oracle, PostgreSQL, NoSQL, or other mission-critical workloads, the program supports heterogeneous sources and targets, ensuring enterprises can modernize on their terms.

Access is streamlined through Microsoft’s Cloud Factory Accelerator team, which manages program enrollment and coordinates the distribution of licenses. Once onboarded, customers receive installation walkthroughs, an enablement kit, and direct support from Striim architects. Cutover support, hands-on labs, and escalation paths are all built in to help migrations run smoothly from start to finish.

Enterprises can start migrations quickly, scale across business units, and keep projects moving without slowing down for procurement hurdles. Now, migrations can begin when the business is ready, not when budgets or contracts catch up.

How Striim Powers Online Migrations

Within Striim’s database migrations, schema changes and metadata evolution are automatically detected and applied, preserving data accuracy and referential integrity. As the migration progresses, Striim automatically coordinates both the initial bulk load of historical data and the ongoing synchronization of live transactions. This ongoing synchronization keeps source and target systems in sync for as long as needed to actively test the target applications with real data before doing the cutoff, thereby minimizing risk.

However, the foundation of Striim’s approach is log-based Change Data Capture (CDC), which streams database changes in real time from source to target with sub-second latency. This helps migrations avoid just moving the static snapshot of a database. Rather, they continuously replicate every update as it happens, so both environments remain aligned with minimal impact on operational systems throughout the process.

While the snapshot (initial load) is being applied to the target system, Striim captures all the changes that occur. Once the initial load process is complete, Striim applies the changes using CDC, and from this point on, the source and target systems are in sync. This eliminates the need for shutting down the source system during the initial load process and enables customers to complete their migrations without any downtime of the source database.

Striim is also designed to work across hybrid and multi-cloud architectures. It can seamlessly move workloads from on-premises databases, SaaS applications, or other clouds into Microsoft databases. By maintaining exactly-once delivery and ensuring downstream systems stay in sync, Striim can reduce risk and accelerates the path to modernization.

Striim is available in the Azure Marketplace, giving customers a native, supported way to integrate it directly into their Azure environment. This means migrations can be deployed quickly, governed centrally, and scaled as business needs evolve, all while still aligning with Azure’s security and compliance standards.

From Migration to Value

With workloads fully landed in Azure, enterprises can immediately take advantage of the broader Microsoft data ecosystem. Fabric, Azure AI Foundry, and Copilot become available as extensions of the database foundation, allowing teams to analyze, visualize, and enrich data without delay.

Once data is in Azure, it becomes AI-ready by default.

Enterprises can begin adopting Microsoft AI services with data that is current, trusted, and governed. Instead of treating migration as an isolated project, customers gain an integrated pathway to analytics and AI, creating value as soon as databases go live in Azure.

How Enterprises Are Using the Program Today

Across industries, we’re already seeing how this program changes the way enterprises approach modernization.

Financial Services
Moving from Oracle to Azure SQL, one global bank used Striim to keep systems in sync throughout the migration. With transactions flowing in real time, they stood up a modern fraud detection pipeline on Azure that identifies risks as they happen.
Logistics
For a logistics provider, shifting package-tracking data from MongoDB to Azure Cosmos DB meant customers could monitor shipments in real time. Striim’s continuous replication kept data consistent throughout the cutover, so the company didn’t have to trade accuracy for speed.
Healthcare
A provider modernizing electronic medical records from Sybase to Azure SQL relied on Striim to ensure clinicians never lost access. With data now in Azure, they can meet compliance requirements while building analytics that improve patient care.
Technology
InfoCert, a leading provider of digital trust services specializing in secure digital identity solutions, opted to migrate its critical Legalmail Enterprise application from Oracle to Azure Database for PostgreSQL. Using Striim and Microsoft, they successfully migrated 2 TB of data across 12 databases and completed the project within a six-month timeframe, lowering licensing costs, enhancing scalability, and improving security.

What unites these stories is a common thread: once data is in Azure, it becomes part of a foundation that’s ready for analytics and AI.

Accelerate Your Path to Azure

Now, instead of database migration being the bottleneck for modernization, it’s the starting point for what comes next. With the Unlimited Database Migration Program, Microsoft and Striim have created a path that removes friction and clears the way for innovation.

Most customers can simply reach out to their Microsoft account team or seller to begin the process. Your Microsoft representative will validate that your migration scenario is supported by Striim, and Striim will allocate the licenses, provide installation guidance, and deliver ongoing support. If you’re unsure who your Microsoft contact is, you can connect directly with Striim, and we’ll coordinate with Microsoft on your behalf.

There’s no lengthy procurement cycle or complex setup to navigate. With Microsoft and Striim jointly coordinating the program, enterprises can begin migrations as soon as they’re ready, with confidence that support is in place from start to finish.

Simplify your migration and move forward with confidence. Talk to your Microsoft representative or book a call with Striim team today to take advantage of the Unlimited Database Migration Program and start realizing the value of Azure sooner. Or if you’re attending Microsoft Ignite, visit Striim at booth 6244 to learn more, ask questions, and see how Striim and Microsoft can help accelerate your modernization journey together.

SQL Server migration in Azure Arc – Generally Available

danimir — Tue, 18 Nov 2025 16:08:06 GMT

We’re excited to announce General Availability of the SQL Server migration in Azure Arc. This experience is designed to simplify and accelerate SQL Server migration journey to Azure SQL Managed Instance offering a unified, end-to-end workflow directly within the Azure portal.

About the solution

SQL Server migration in Azur Arc integrates existing Azure Database Migration Service capabilities into Azure Arc by enabling the entire end to end migration journey with the following capabilities:

Continuous database migration assessments with Azure SQL target recommendations and cost estimates.
Seamless provisioning of Azure SQL Managed Instance as destination target, also with an option of free instance evaluation.
Option to choose between two built-in migration methods: real-time database replication using Distributed Availability Groups (powered by MI link feature), or log shipping via backup and restore (powered by Log Replay Service feature).
Unified interface that eliminates the need to use multiple tools or to jump between various places in Azure portal.
Microsoft Copilot is integrated to assist you at select points during the migration journey.

Learn more about SQL Server Migration in Azure Arc.

Benefits of the solution

Traditionally, migrating SQL Server workloads to Azure required juggling between multiple tools, various places in portal, and some manual steps. This new experience changes that by:

Providing a single pane of glass in the Azure portal for the entire migration journey.
Reducing migration timelines from months to days.
Offering a choice of two migration methods – real-time replication or log-shipping
Enabling validation of target environments using read-only replicas before cutover for real-time replication.
Automatically capturing application client connection data to simplify mapping between applications and databases.
Optional failback from Azure SQL Managed Instancy with configured upgrade policy for SQL Server 2022 and SQL Server 2025 with external tooling.
Providing intelligent step-by-step guidance with Microsoft Copilot at select points of the migration journey, helping you make informed decisions.

Start Your Migration Journey Today

In case your SQL Server is Arc enabled, you could proceed right away to Azure portal. If you need to enable it, then onboard your SQL Server to Azure Arc today.

In the portal, navigate to Arc enabled SQL Server resource, and on the left-hand side select Migration, then Database Migration.

This is where you will navigate to the new database migration experience. Shown below is illustrated experience of the database migration experience you are expected to see.

From the main screen, you can navigate through each stage of the migration journey - starting with the database migration readiness assessment, followed by selecting or provisioning an Azure SQL Managed Instance as the target destination, choosing the appropriate migration method, monitoring progress, and performing the final cutover.

By selecting the Azure SQL Benefits tab, you’ll gain insights into the advantages of Azure SQL - helping you make well-informed decisions about your migration. By selecting the Tutorials tab, you will access information helping you getting started with the solution.

We've also integrated Microsoft Copilot at select points in the journey for any guidance and support you might need to ensure confident and informed decision-making.

For next steps, click on the button below:

Feedback

We love hearing from our customers! Any feedback or suggestions for the product group, use the following online form to let us know:

Provide feedback to the product group

We hope that you will enjoy our solution, and we look forward to your feedback as you embark on your migration journey to Azure.

Assess and upgrade to SQL Server 2025 with SSMS Migration Component

ajith-k — Mon, 17 Nov 2025 16:59:22 GMT

What is new

Starting with SSMS 22, the Hybrid & Migration component now includes upgrade assessment for SQL Server 2025. This feature enables you to quickly evaluate readiness for upgrade. SSMS also provides a streamlined migration path to the instance of higher version if in-place upgrade is not preferred.

Why it matters

Fast readiness check – targeted rules for SQL Server 2025 to flag upgrade blockers with remediation guidance.
Easy alternative to in-place upgrade with guided migration using backup-restore and login transfer.
Up-to-date coverage – breaking changes and discontinued features for SQL Server 2025 included.

What the assessment checks (examples)

Linked servers – detects OLE DB Driver 19 encryption defaults; recommends certificate or Encrypt=Optional.
Discontinued features – flags Master Data Services (MDS) and Data Quality Services (DQS).
Synapse Link – use Mirroring to Microsoft Fabric as replacement.
Discontinued purview access policies – suggests fixed server roles.
Reporting – consolidated into Power BI Reporting Services
Deprecations – highlights Hot-add CPU.

Brief How-to

Install or update SSMS 22 and include Hybrid & Migration component.
Run assessment: Connect to source instance → Migrate SQL Server > New Assessment → select target SQL Server 2025 → review report and mitigate.
Migrate to separately installed SQL Server 2025: Connect to source instance → Migrate SQL Server > New Migration → provide target SQL Server 2025 instance and authentication details → select databases and provide folder paths → select databases and provide folder paths → choose logins to migrate → Once migration completes, connect to target and verify

Documentation & quick links

Notes for DMA users

If you previously used Microsoft Data Migration Assistant (DMA) for upgrade assessments, SSMS migration component is now the recommended alternative. DMA has been retired.

Release Announcement of SQL Server Migration Assistant (SSMA) v10.4

subhojitbasak — Wed, 12 Nov 2025 18:10:48 GMT

We’re excited to announce the release of SQL Server Migration Assistant (SSMA) v10.4, bringing significant enhancements across all SSMA flavors to further streamline your database modernization journey to Azure SQL and SQL Server.

This release focuses on deeper platform support, expanded schema conversion capabilities, and new AI-assisted experiences—with more coming soon

Support for SQL Server 2025

(Available across all SSMA flavors)

With SSMA 10.4, you can now fully discover, assess, convert schema, and migrate data to SQL Server 2025.
This includes:

Target selection for SQL Server 2025 in the assessment report
Updated conversion rules for new SQL Server 2025 features (more to come in future versions)
Data migration pipeline compatibility
Improved schema and datatype mappings

Whether you are modernizing on-premises workloads or planning a hybrid Azure strategy, SSMA 10.4 ensures you're ready for the next SQL Server release.

Migration Target Options

General Availability of Oracle PL/SQL to SQL Code Conversion Copilot

The Copilot experience for converting Oracle PL/SQL to T-SQL is now Generally Available (GA).
The AI-assisted conversion engine helps accelerate application modernization by generating high-quality error handling of T-SQL from PL/SQL packages, procedures, functions, triggers, and more.

We will publish a detailed blog with examples and guidance on how to make the most of this new capability.

Microsoft-Managed Endpoint for Copilot Login (Preview)

(Full blog coming soon)

We are introducing a new Microsoft-managed endpoint that enables SSMA Copilot usage through Microsoft Entra ID authentication, without requiring customers to bring their own Azure OpenAI subscription.

This feature is in Public Preview, and more details—including setup guidance—will be shared in an upcoming blog.

Managed Endpoint

User-Defined Datatypes (UDTs) support in SSMA for Sybase

SSMA for Sybase now supports conversion of User-Defined Datatypes (UDTs) to SQL Server.
This enhancement helps teams eliminate manual schema rewrites, reduces migration risk, and improves assessment coverage for complex Sybase ASE schemas.

Sybase to SQL User Defined Datatype conversion

Other Improvements in SSMA 10.4

This release also includes several enhancements across flavors:

Rule engine improvements in SSMA for Sybase, enabling more consistent and accurate schema conversion
Performance optimizations to reduce assessment and conversion times
Security and compliance updates
Improved explanations and documentation for project settings to help users better understand configuration options during migration

Download Links

Get the latest versions of SSMA v10.4 here:

General Availability - DMS's PowerShell, Azure CLI, and Python SDK

abku14 — Wed, 15 Oct 2025 07:33:02 GMT

We’re excited to announce the General Availability (GA) of DMS client tools - PowerShell, Azure CLI, Python SDK and more.

This milestone unlocks efficient, stable, and scalable automation options for database migration workflows—making it easier than ever to integrate DMS into your DevOps pipelines and enterprise migration strategies.

💡Introduction:

With the general availability of DMS client tools - PowerShell, Azure CLI, Python SDK, users can now use stable release of:

PowerShell module 1.0.0 (https://www.powershellgallery.com/packages/Az.DataMigration/1.0.0)
Azure CLI extension 1.0.0 (https://learn.microsoft.com/en-us/cli/azure/datamigration?view=azure-cli-latest)
DMS V2 APIs (version 2025-06-30)
SDKs for multiple languages (listed below)

SDKs Releases:

Language	GA Package / Link
.Net	https://www.nuget.org/packages/Azure.ResourceManager.DataMigration/1.0.0
Java	https://central.sonatype.com/artifact/com.azure.resourcemanager/azure-resourcemanager-datamigration/1.1.0
Go	https://pkg.go.dev/github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/datamigration/armdatamigration/v2
Python	azure-mgmt-datamigration · PyPI
JavaScript	https://www.npmjs.com/package/@azure/arm-datamigration/v/3.0.0

🔧 What’s New?

Three new commands have been introduced in the latest releases of the SDK, PowerShell module, and CLI extension, as outlined below:

New CLI Commands:

az datamigration sql-db retry - Retry the failed SQL DB migrations.
az datamigration sql-managed-instance delete - Delete Azure SQL MI’s Database Migration resource.
az datamigration sql-vm delete - Delete Azure SQL VM’s Database Migration resource.

New PowerShell Commands:

Invoke-AzDataMigrationRetryToSqlDb - Retry the failed SQL DB migrations.
Remove-AzDataMigrationToSqlManagedInstance - Delete Azure SQL MI’s Database Migration resource.
Remove-AzDataMigrationToSqlVM - Delete Azure SQL VM’s Database Migration resource.

🚀Conclusion:

With this GA / stable release, users can now:

Use them to configure and execute migrations with full control.
Automate migrations: DevOps teams can embed migration steps into CI/CD pipelines.
Integrate into custom applications and orchestration tools.

These support all the DMS migration scenarios—from simple lift-and-shift operations to complex logical migrations—while ensuring stability, and repeatability.

For more details, refer:

Documentation: Migrate databases at scale using Azure PowerShell / CLI
PowerShell: Az.DataMigration Module
Azure CLI: az datamigration
Python SDK: azure-mgmt-datamigration · PyPI

Making Azure DMS More Secure: Azure Portal Permission Enhancements

abku14 — Mon, 13 Oct 2025 16:41:49 GMT

Migrating databases to Azure SQL Managed Instance or Azure SQL Virtual Machine is a critical step in modernizing enterprise infrastructure. With security and compliance top of mind, Azure Database Migration Service (DMS) has introduced key changes to its Azure portal experience—especially around permission for blob container access.

Why the Change?

Previously, in case of Azure Portal, DMS relied on account key-based access to Azure Blob Storage for listing and accessing backup files on the migration configuration page. While functional, this approach is not best in terms of security, especially for industries which prohibit the use of shared keys.

Now, DMS's Azure portal uses security context of the current signed in user on the Azure portal to list and access backup files in the blob container, making it better security approach.

Impact of the Change

When migrating to Azure SQL Managed Instance or Azure SQL Virtual Machine via Azure portal make sure the current signed in user has Storage Blob Data Reader role on the Blob container that contains the backup files. This permission is needed to list folders and files in the blob container during migration setup via Azure portal only.

If the current signed in user lacks the Storage Blob Data Reader role on the Blob container, users will encounter the following error:

Error:

"Blob container selection error: Error listing the contents of the container: This request is not authorized to perform this operation using this permission."

Solution: Make sure the current signed in user has "Storage Blob Data Reader" role on the Blob container that contains the backup files.

For more information, refer :

Migrate and Modernize Summit 2025: Unifying the Database Journey in Azure

Shireesh_Thota — Tue, 23 Sep 2025 12:59:40 GMT

At the heart of every digital transformation is data. This year’s Migrate and Modernize Summit was more than a showcase of new features—it was a demonstration of how Microsoft Azure is reimagining the migration and modernization journey for organizations of every size, including for their databases. The Summit showcased how Azure is making it easier and faster to move, manage, and modernize your data estate, whether you’re running PostgreSQL, SQL Server, Oracle, or Sybase.

Azure is the best place for SQL Server

Azure is the best place to run SQL workloads in the cloud. The next-gen Azure SQL Managed Instance (public preview) further elevates modernization, delivering 5x database capacity, 2x storage, and improved performance vs. prior generations. This fully managed platform makes it easier to scale and migrate SQL workloads with confidence.

The SQL Server journey in Azure is defined by seamless modernization and operational excellence. The simplified SQL Server Migration Experience in Azure Arc delivers an end-to-end migration process, including continuous assessments, streamlined provisioning, and real-time database replication—all assisted by Copilot in Azure. This is both replication and fallback as well, enabling you to cutover when you are ready or fallback when needed. This is an online, no downtime migration experience. What once took months can now be accomplished in days, with confidence, continuity, and control.

A major highlight is the new Azure Databases Migrate Service (DMS) Hub—a central command center for estate-level SQL migration tracking. The DMS Hub guides you through the migration process, provides at-scale dashboards for tracking progress across all SQL Server databases, and offers a new navigation experience. Benefit from online/no-downtime migrations, with the ability to cut over or fall back when ready, and real-time visibility into every step of their journey.

Schema migration for Azure SQL Database is now generally available, enabling seamless migration of missing schema objects along with data—reducing manual effort and maintaining consistency.

Modernizing legacy systems to Azure SQL

We have tooling to help with your heterogenous migrations from DB2, Sybase, and Oracle to Azure SQL.

When migrating Sybase databases to SQL Server or Azure SQL, the SQL Server Migration Assistant (SSMA) for Sybase streamlines the process with automated schema and data conversion, assessment tools, and step-by-step guidance. SSMA helps reduce manual effort and ensures a smooth transition to modern SQL platforms.

Azure continues to unify the migration experience across database platforms. The new SKU recommender for DB2 to SQL migrations in SSMA helps users select the right Azure SQL SKU based on performance metrics and resource consumption, ensuring optimal landing for migrated workloads.

For those migrating from Oracle, Azure’s SSMA (SQL Server Migration Assistant) for Oracle Migrations now includes enhanced monitoring, ensuring smoother migrations and better visibility throughout the process.

Copilot-assisted DB code conversion experiences for Oracle and DB2 in SSMA, currently in public preview reduce manual effort and improves migration speed and quality.

Move to the fully-managed, open source Azure Database for PostgreSQL

Azure’s commitment to open source shines through in our latest PostgreSQL innovations. The journey begins with the recently-announced public preview of Azure Migrate Discovery and Assessment for PostgreSQL, a new capability that streamlines planning and accelerates migrations to Azure Database for PostgreSQL. This tool provides comprehensive discovery and assessment, helping organizations confidently map their migration path.

The built-in migration service in Azure Database for PostgreSQL Flexible Server makes it easy to migrate Postgres workloads from a variety of sources. It supports migration from on-premises servers, as well as virtual machines or managed Postgres services in AWS and GCP.

Once in Azure, developers can use dedicated features in the new PostgreSQL extension for Visual Studio Code. This extension simplifies database management and development workflows, offering intelligent assistance through context-aware IntelliSense and the ‘@pgsql’ GitHub Copilot agent—all within your favorite code editor. These enhancements empower teams to build, optimize, and innovate faster.

Why This Matters

These innovations are not just features—they are part of a unified approach to data modernization that reduces migration complexity and ultimately empower you to create the next generation of AI apps. Whether you’re migrating SQL Server, Oracle, PostgreSQL, or Sybase workloads, Azure’s latest tooling and services provide a streamlined, intelligent path to the cloud.

Ready to Learn More or Get Started?

Watch the Migrate and Modernize Summit 2025 event on-demand, including Tejas Shah’s databases section of the event’s follow-on session.

Release Announcement of SQL Server Migration Assistant (SSMA) v10.3

subhojitbasak — Thu, 18 Sep 2025 06:38:19 GMT

We’re excited to announce the release of SQL Server Migration Assistant (SSMA) v10.3, bringing important enhancements across multiple SSMA flavors to make your database migration journey simpler and more efficient.

Db2 SKU Recommendation (Public Preview)

One of the key highlights in this release is the SKU Recommendation feature for Db2 migrations. This capability helps you determine the right Azure target SKU (Azure SQL Database, Azure SQL Managed Instance, or Azure VMs) by analyzing your Db2 source environment’s performance characteristics such as MIPS, IOPS, CPU count, and storage size.

With just a few inputs, SSMA for Db2 automatically generates a detailed recommendation report in HTML format with source system details and recommended Azure targets, giving you confidence in planning your migration.

You can see the full step-by-step flow in our Microsoft Learn documentation.

z/OS Db2 SKU recommendation flow

SQL SKU Recommendation in Db2 z/OS

LUW Db2 SKU recommendation flow

SQL SKU Recommendation in Db2 LUW

Other Improvements

The remaining SSMA flavors — Oracle, Sybase, Access, and MySQL — received important updates focused on performance improvements, compliance updates, and bug fixes.

Download Links

Get the latest versions of SSMA v10.3 here:

Announcing the Azure Database Migration Service Hub Experience

neelball — Wed, 17 Sep 2025 22:24:55 GMT

We’re excited to introduce the Azure Database Migration Service (DMS) Hub experience—a powerful new enhancement that simplifies how you view, manage, and track your SQL Server migration journey to Azure. Whether you're just getting started or deep into your modernization strategy, the DMS Hub provides a centralized, intuitive experience to help you move faster and smarter.

🧭 A New Landing Experience to Get You Started

The new DMS Hub offers a streamlined landing page that brings together everything you need to begin your migration journey:

Create and manage Azure DMS instances from a single place.
View a unified dashboard for discovery and assessment.
Track all discovered SQL Servers in your environment.

This experience is designed to reduce friction and give you a clear path forward—whether you're assessing readiness or preparing to migrate.

🔍 Discovery and Assessment, Simplified

At launch, the DMS Hub focuses on discovery and assessment:

Automatically surface all discovered SQL Servers in your environment.
Quickly identify which servers are ready for assessment.
Access detailed insights to help you plan your next steps.

This visibility is crucial for teams managing large-scale migrations or consolidations.

📊 A Dashboard Built for Clarity

The dashboard gives you a real-time view of your migration landscape:

See all discovered servers in one place.
Filter and sort based on readiness, environment, or other metadata.
Drill into server-level details to understand dependencies and blockers.

This helps you prioritize and plan with confidence.

🔮 What’s Coming Next: Migration Tracking and Multi-RDBMS Support

We’re just getting started.

Over the next few months, we’re actively working on enhancing the DMS Hub to support migration tracking. This means:

You’ll be able to track the progress of your migrations directly from the dashboard.
Get visibility into migration status, errors, and completion metrics.
Monitor end-to-end workflows from discovery to cutover.

🎯 Ready to Explore?

If you're planning a migration or want to see what’s new, head over to the Azure DMS Hub and experience the future of database migration. To learn more, Dashboards in Azure Database Migration Service | Microsoft Learn.

General Availability - Schema Migration support in Azure Database Migration Service (DMS)

abku14 — Mon, 04 Aug 2025 06:26:50 GMT

We’re thrilled to announce that Schema Migration support in Azure Database Migration Service (DMS) is now generally available (GA)! This milestone marks a significant leap forward in simplifying and accelerating your journey to the cloud.

Introduction:

With the general availability of schema migration in Azure Database Migration Service (DMS), users can now deploy missing schema objects along with either selective or all Tables from the source database to the target Azure SQL Database with a single step. By enabling the schema migration checkbox during SQL migration setup, the service automatically includes the following schema components in the migration process alongside the data:

Schemas
Tables
Indexes
Views
Stored Procedures
Synonyms
DDL Triggers
Defaults
Full-Text Catalogs
Plan Guides
Roles
Rules
Application Roles
User-Defined Aggregates
User-Defined Data Types
User-Defined Functions
User-Defined Table Types
User-Defined Types
Users (limited user types)
XML Schema Collections

This enhancement streamlines the migration workflow, reduces manual effort, and ensures consistency between source and target environments.

Prerequisites:

1) - For schema migration to work, you must have SHIR version 5.37.8767.4 and above installed and registered with DMS services.

2) - Minimum permissions on source SQL Server is db_owner to access the database.

3) - Minimum permissions on target Azure SQL DB is the user should be member of the server level roles mentioned below:

Roles	Description
##MS_DatabaseManager##	Members of the ##MS_DatabaseManager## fixed server role can create and delete databases. A member of the ##MS_DatabaseManager## role that creates a database, becomes the owner of that database, which allows that user to connect to that database as the dbo user. The dbo user has all database permissions in the database. Members of the ##MS_DatabaseManager## role don't necessarily have permission to access databases that they don't own. It's recommended to use this server role over the dbmanager database level role that exists in master.
##MS_DatabaseConnector##	Members of the ##MS_DatabaseConnector## fixed server role can connect to any database without requiring a User-account in the database to connect to
##MS_DefinitionReader##	Members of the ##MS_DefinitionReader## fixed server role can read all catalog views that are covered by VIEW ANY DEFINITION, respectively VIEW DEFINITION on any database on which the member of this role has a user account.
##MS_LoginManager##	Members of the ##MS_LoginManager## fixed server role can create and delete logins. It's recommended to use this server role over the loginmanager database level role that exists in master.

Selecting the Schema Migration

1) In Azure Portal

To enable schema migration when migrating to Azure SQL Database using Azure Database Migration Service (DMS) via the Azure Portal, follow these steps:

In DMS migration wizard, navigate to the "5. Select database tables to migrate" tab during the migration configuration process.
On this tab, locate and select the checkbox labeled "Migrate missing schema". As shown below:

By enabling this option, the service will automatically include missing schema objects from the source database in the migration to the target Azure SQL Database, alongside the data migration.

For more detailed steps, click here..

2) PowerShell, Az cmdlets:

To perform schema migration using PowerShell and Azure Database Migration Service (DMS) cmdlets, refer to the official documentation and resources linked below:

Conclusion

If your target environment is Azure SQL Database, you can leverage Azure Database Migration Service (DMS) to perform a comprehensive migration that includes both database schema and data. This integrated capability ensures that all essential schema objects—such as tables, views, stored procedures, and user-defined types—are accurately deployed to the target Azure SQL Database alongside the actual data. By enabling the schema migration option during configuration, users can streamline the migration process, reduce manual intervention, and maintain consistency between source and target environments.

Refer : Tutorial: Migrate SQL Server to Azure SQL Database (Offline) - Azure Database Migration Service | Microsoft Learn

New database migration experience for SQL Server enabled by Azure Arc – Public Preview

danimir — Fri, 18 Jul 2025 11:13:58 GMT

We’re excited to announce a new database migration experience for SQL Server enabled by Azure Arc - now in public preview. This experience is designed to simplify and accelerate SQL Server migration journey to Azure SQL Managed Instance offering a unified, end-to-end workflow directly within the Azure portal.

🚀 What Is It?

This new migration experience integrates existing Azure Database Migration Service capabilities into Azure Arc by enabling the entire end to end migration journey with the following capabilities:

Continuous database migration assessments with Azure SQL target recommendations and cost estimates.
Seamless provisioning of Azure SQL Managed Instance as destination target, also with an option of free instance evaluation.
Option to choose between two built-in migration methods: real-time database replication using Distributed Availability Groups (powered by the MI link feature), or log shipping via backup and restore (powered by the Log Replay Service feature).
Unified interface that eliminates the need to use multiple tools or to jump between various places in Azure portal.
Microsoft Copilot is integrated to assist you at select points during the migration journey.

💡 Why It Matters

Traditionally, migrating SQL Server workloads to Azure required juggling between multiple tools, various places in portal, and some manual steps. This new experience changes that by:

Providing a single pane of glass in the Azure portal for the entire migration journey.
Reducing migration timelines from months to days.
Offering real-time replication and minimal downtime migration
Enabling validation of target environments using read-only replicas before cutover.
Automatically capturing application client connection data to simplify mapping between applications and databases.
With built-in support for both MI link and Log Replay Service (LRS), customers can choose the migration method that best fits their SQL Server version and business needs.
Optional failback for SQL Server 2022 and above with external tooling.
Providing intelligent step-by-step guidance with Microsoft Copilot at select points of the migration journey, helping users make informed decisions.

🧭 Start Your Migration Journey Today

In case your SQL Server is Arc enabled, you could proceed right away to Azure portal. If you need to enable it, then onboard your SQL Server to Azure Arc today.

In the portal, navigate to Arc enabled SQL Server resource, and on the left-hand side select Migration, then Database Migration (preview).

This is where you will navigate to the new database migration experience.

▶️ Demo Video

Included below is a short YouTube video demonstrating the database migration experience you can expect.

By selecting the Azure SQL Benefits tab, you’ll gain insights into the advantages of Azure SQL - helping you make well-informed decisions about your migration. You can consult the integrated Microsoft Copilot at select points in the journey for guidance and support to ensure confident and informed decision-making.

➡️ Next steps

To get started with the new database migration experience for SQL Server enabled by Azure Arc, visit Microsoft Learn:

Learn more about new migration experience in Azure Arc on Microsoft Learn

We love hearing from our customers! Any feedback or suggestions for the product group, use the following online form to let us know:

Provide feedback on database migrations for SQL Server enabled by Azure Arc to the product group

We hope that you will enjoy our solution, and we look forward to your feedback as you embark on your migration journey!