Online / Offline Migration to Azure SQL Managed Instance for Large Databases

Question

Online / Offline Migration to Azure SQL Managed Instance for Large Databases

ElenaMarlowe-3376 105

I want to migrate an on-premises SQL Server to Azure SQL Managed Instance. The environment contains two databases, each approximately 1 TB in size.

I’ve reviewed the official Microsoft documentation and noticed that both online and offline migration approaches are supported. However, since I don’t have hands-on experience with large-scale SQL Managed Instance migrations, I’d like to ask the community for practical experience and recommendations.

Is there a recommended online or offline migration method for large databases (~1 TB each)? For example:

Online: Managed Instance Link, Azure Database Migration Service (online mode)

Offline: Native backup and restore, Azure Database Migration Service (offline mode)

Azure Data Studio is scheduled to be retired in February 2026. Will Azure Database Migration Service (DMS) continue to work normally after that? Since I’m planning to perform the migration around mid-2026, I’m concerned that Azure Data Studio may no longer be available to support the migration workflow.

Any experience sharing or best-practice recommendations would be greatly appreciated. Thank you.

0 comments

2 answers

Your answer

Answer 1

Anonymous

Hi @ElenaMarlowe-3376

Thank you for contacting Microsoft Q&A. Please find below the detailed steps to address the reported issue

1. Recommended Migration Method for ~1 TB Databases

For databases around 1 TB, both online and offline migrations are possible, but they serve different business needs. Based on field experience and Microsoft guidance:

Best Online Method (Minimal Downtime) ➡ Managed Instance Link (MI Link) MI Link is the top choice for large databases because it uses Always On technology for near real-time replication and requires only a brief cutover window (seconds to minutes). You can keep the link active for days or weeks until you’re ready to switch, and you can test read-only workloads on MI before cutover. This approach is ideal for ~1 TB because it handles large DBs without lengthy backup/restore cycles, offers the fastest data movement with the least downtime, and supports multiple databases from a single on-premises instance. Microsoft documents describe MI Link as “the only truly online migration option… providing near real-time replication and instantaneous cutover.” Learn more: MI Link migration documentation.
Best Offline Method (If Downtime Is Acceptable) ➡ Native Backup/Restore to URL (with Azure Blob Storage) This path is the simplest and most predictable offline option: upload full backups to Azure Blob Storage and restore on Managed Instance. It requires a downtime window but suits many customers. It is officially supported for SQL MI offline migration in DMS and ADS workflows. When to choose this: if a downtime of a few hours is acceptable, and the migration team prefers a straightforward restore-based workflow.
Azure Database Migration Service (DMS) DMS supports both online and offline modes for SQL MI migrations. Online mode uses log replay behind the scenes; offline mode orchestrates a backup-to-restore workflow. DMS is fully supported and GA for SQL Server to SQL MI migrations.

Recommended Choices Summary

MI Link: Minimal downtime, highly predictable. Best for ~1 TB.
Backup/Restore (Offline): Simple, automated workflow with assessments.
DMS (Online/Offline): Flexible, GA-supported option.

2. Azure Data Studio (ADS) Retirement – Impact on Migration

Yes, DMS will continue to work after ADS retirement. Here are the key points:

ADS Retirement Date - Azure Data Studio retires on Feb 28, 2026, and will no longer receive updates or security fixes.
B. What Continues to Work After Retirement - ADS will still run but is unsupported. DMS as a platform service is not retiring. The Azure SQL Migration extension within ADS is being replaced by VS Code–based tooling.
What Microsoft Recommends - Use Visual Studio Code with the MSSQL extension, which replaces ADS for SQL migrations. It fully supports assessments, schema comparison, and migrations. All SQL projects and scripts remain compatible.
Will mid-2026 migrations be impacted? - No. You’ll simply use the VS Code migration tooling instead of ADS, while DMS continues to function.

3. Concrete, End-to-End Migration Plan (Customer-Ready)

Step 1 — Pre-Migration Assessment

Run Data Migration Assistant (DMA) to detect blockers, deprecated features, and compatibility issues.
Validate logins, SQL Agent jobs, linked servers, CLR, and cross-DB references.

Step 2 — Choose Migration Mode

If near-zero downtime is required: MI Link.
If some downtime is acceptable: Backup/Restore or DMS Offline.

Step 3 — Set Up Target MI

Provision Azure SQL MI with appropriate vCores, storage, and service tier.
Ensure networking connectivity (VPN/ExpressRoute), firewall rules, and subnets.

Step 4 — Migration Execution A. MI Link (Recommended Online Path)

Enable AlwaysOn on-premises availability group.
Configure MI Link from the Azure Portal.
Wait for full synchronization and continuous replication.
Perform final cutover during a small downtime window.

B. Offline Path (Backup/Restore or DMS Offline)

Upload FULL, DIFF, and LOG backups to Azure Blob Storage.
Restore using T-SQL on MI or via the DMS Offline workflow.
Validate database, logins, jobs, and application connectivity.

Step 5 — Cutover

Stop application writes.
Complete the final sync (if online).
Switch application connections to SQL MI.

Step 6 — Post-Migration Tasks

Validate database integrity, Agent jobs, and permissions.
Enable monitoring (Azure Monitor, Query Store).
Decommission on-prem resources.

Key Best Practices for Large (1 TB) Migrations

Use compressed and striped backups to speed up uploads and restores.
Validate TDE certificate migration early if TDE is enabled.
Test MI Link or a restore operation with a subset database first.
Benchmark MI performance with Query Store and Automatic Tuning.

For detailed insights, check out:

ElenaMarlowe-3376 105 Reputation points

2025-12-31T03:40:42.5466667+00:00
Hi @Anonymous ,

I have a few questions related and would appreciate your clarification.

Azure Data Studio retirement and SKU recommendation

We understand that Azure Data Studio is scheduled to be retired on February, 2026, but that the tool may continue to run after the retirement date. So,

Will the SKU recommendation / assessment functionality in Azure Data Studio continue to work after February 2026?

If not, what is the recommended alternative approach or tool to obtain Azure SQL Managed Instance SKU recommendations and workload assessment reports?

Database Migration Assistant (DMA)

We noticed that Database Migration Assistant (DMA) was retired in July this year.

Is DMA still supported for use in existing migration scenarios?

If not, what is the recommended replacement for compatibility assessment and migration readiness checks?

Downtime definition for native backup and restore

For the native backup and restore migration approach:

Is the downtime measured starting from the source SQL Server backup begins?

For a database of approximately 1 TB in size, is there any general guidance or reference range on the expected downtime, assuming a typical enterprise network and storage setup?

Data Factory as a migration option

Would Azure Data Factory be recommended as a migration approach for SQL Server to Azure SQL Managed Instance?

If so, in what scenarios would ADF be suitable or unsuitable compared to native backup/restore, Log Replay Service, or Managed Instance link?

Thanks in advance for your support and guidance.
Anonymous

2025-12-31T07:42:28.4366667+00:00
Hi @ElenaMarlowe-3376

Thanks for sharing your feedback, below are mitigation steps on your additional question -

Azure is retiring some familiar tools (ADS and DMA), and the recommended migration path in mid‑2026 is to standardize on VS Code, Azure Arc, Azure Migrate, and DMS, with MI Link or LRS for low‑downtime moves to Azure SQL Managed Instance.

Azure Data Studio (ADS) retirement and SKU sizing

Q: Will ADS still give SKU recommendations after Feb 28, 2026?

Azure Data Studio officially retires on February 28, 2026. Existing installations may still run, but they are no longer supported after that date, and Microsoft is steering customers toward VS Code–based tooling instead.

The Azure SQL Migration extension in ADS (which collects performance data and generates right‑sized SKU recommendations for SQL Managed Instance) is still documented today, but Microsoft’s roadmap is to move these experiences into VS Code and portal/automation flows, so you should not plan on ADS being a supported dependency in mid‑2026.

Recommended options for SKU sizing and assessment once ADS is retired:

SQL Server enabled by Azure Arc – Continuous Migration Assessment (agentless, recurring, at‑scale assessments with updated readiness and sizing signals). Use this for ongoing sizing and readiness checks.

Azure Migrate – appliance‑based discovery plus performance‑driven sizing and cost estimates for SQL at scale; use this for estate‑level planning and consolidation.

Azure Database Migration Service (DMS) via PowerShell/CLI – use for scripted assessments and fully orchestrated migrations (online or offline) that plug into your existing migration factory patterns.

VS Code with the MSSQL extension – your day‑to‑day DBA and developer surface for projects, query work, and schema compare previews, combined with Arc, Azure Migrate, and DMS for sizing and move execution.

Manual right‑sizing – follow Microsoft Learn guidance: baseline CPU, memory, I/O latency, and throughput on the source, then map those metrics to an appropriate vCore count and service tier (General Purpose versus Business Critical).

Why you should not rely on ADS in mid‑2026

Microsoft is consolidating SQL tooling around VS Code and clearly states that ADS will not be serviced beyond its retirement window. Plan your workflows on VS Code plus Arc, Azure Migrate, and DMS instead of assuming ADS will remain usable or supported long term.

Database Migration Assistant (DMA)

Q: Is DMA still supported? If not, what replaces it?

The Data Migration Assistant (DMA) retires on July 16, 2025; after that date it is no longer supported and is not available for download or updates.

Microsoft’s recommended replacements:

SQL Server enabled by Azure Arc – provides automatic, continuous migration assessments, including readiness checks and SKU signals for Azure targets.

Azure Migrate – gives at‑scale SQL discovery, performance‑based sizing, and cost estimation for large estates.

Azure DMS via PowerShell/CLI – combines assessment and migration orchestration in an automation‑friendly way for both online and offline migrations.

SSMS migration components – useful primarily for version‑upgrade scenarios on SQL Server, rather than for moving into Managed Instance.

Downtime for native backup/restore to Managed Instance

Q: When does downtime actually start, and what does that look like for a ~1 TB database?

A practical definition you can adopt: downtime starts when you stop application writes to the source (for example, enforce read‑only), take the final differential and tail‑log backups, and begin uploading and restoring those backups to Managed Instance; downtime ends once the restore has completed, post‑cutover checks are done, and client connections are repointed to MI.

For Azure SQL Managed Instance, the restore flow uses RESTORE FROM URL (backups in Azure Blob Storage with SAS/credentials) via SSMS or T‑SQL.

Restore time is influenced by database size, MI compute size, the number and size of log backups, the volume of changes to replay, network throughput, and regional service load. Microsoft documents these as determinants but does not guarantee a specific recovery time, so you should measure your own throughput and derive a realistic downtime window from test runs.

Practical ways to keep the outage small:

Pre‑stage one or more full backups to Azure Blob days before cutover. At the cutover point, take a final differential plus tail‑log backup, upload them, and restore in sequence to Managed Instance.

Use compressed, striped backups (multiple backup files) and tune BUFFERCOUNT and MAXTRANSFERSIZE to accelerate both backup and restore; these techniques are standard for SQL Server backups to URL and apply directly here.

Schedule your Managed Instance maintenance windows so that platform maintenance does not pause or slow your restore.

Before allowing writes again, validate logins and users, SQL Agent jobs, and application connectivity, following the broader Managed Instance migration guidance.

If downtime is tightly constrained, use an online migration:

Managed Instance link for near‑real‑time replication and a very short cutover window.

DMS online mode or Log Replay Service (LRS) for continuous log replay where the main outage is the final cutover and validation.

Using Azure Data Factory (ADF) for migration

Q: Is ADF a good option to migrate SQL Server to Managed Instance?

Official guidance for SQL Server to Azure SQL Managed Instance highlights Managed Instance link (online), Azure DMS (online/offline), Log Replay Service, and native backup/restore as the primary migration paths. ADF does not appear there because it is an ETL and data‑movement service, not a full‑fidelity instance or database migration tool.

When ADF can make sense:

Building custom pipelines for table‑level sync (for example, an initial bulk load followed by CDC‑based changes) or side‑by‑side patterns, especially when synchronizing data with Azure SQL Database or Managed Instance for integration or phased migration scenarios. In such designs, you are responsible for re‑creating consistency guarantees, dependencies, jobs, and cross‑database behaviors.

When ADF is the wrong tool:

For like‑for‑like instance moves that must preserve transactional consistency, cross‑database semantics, logins, jobs, and strict, minimal downtime, you should rely on MI Link, DMS, or LRS instead of ADF.

Putting it together: path for ~1 TB databases (mid‑2026)

Assessment and SKU sizing without ADS

Turn on SQL Server enabled by Azure Arc and use Continuous Migration Assessment to get right‑sizing signals and blocker visibility. Pair this with Azure Migrate for broad‑estate sizing and cost projections.

Cross‑check those tool‑driven recommendations with manual baselines from Microsoft Learn (CPU, memory, and I/O characteristics mapped to vCore counts and the appropriate General Purpose or Business Critical tier).

Choose your migration pattern

Minimal downtime: use Managed Instance link for near‑real‑time replication from SQL Server to MI and keep the cutover outage to a brief window.

Controlled offline window: use native backup/restore to URL or an offline DMS migration when a planned downtime window is acceptable and predictable.

Programmable online (no ADS dependency): use DMS PowerShell/CLI or Log Replay Service for continuous log replay and automated, scriptable online migrations.

After cutover

Validate logins and permissions, SQL Agent jobs, linked servers, and application connection strings. Then enable features like Query Store and Automatic Tuning on Managed Instance so you can quickly baseline and tune performance in the new environment.
Anonymous

2026-01-02T03:38:29.88+00:00

Hi @**ElenaMarlowe-3376
**
I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.

Answer 2

For migrating large databases (approximately 1 TB each) from on-premises SQL Server to Azure SQL Managed Instance, both online and offline migration methods are available, and the choice depends on your specific requirements regarding downtime and complexity:

Recommended Migration Methods:
- Online Migration: Using the Azure Database Migration Service (DMS) in online mode is recommended for large databases if minimizing downtime is crucial. This method allows for near-zero downtime during the migration process, which is beneficial for production environments. The Managed Instance Link feature is also a strong option as it allows for real-time replication and read-only access during migration.
- Offline Migration: If downtime is acceptable, the native backup and restore method can be used. However, this will involve more significant downtime as the application will be unavailable during the migration process. The offline mode of Azure DMS is also an option but may not be as efficient for large databases compared to online methods.
Future of Azure Data Studio and DMS:
- While Azure Data Studio is scheduled for retirement in February 2026, Azure Database Migration Service (DMS) is a separate service and is expected to continue functioning normally beyond this date. Therefore, you should be able to use DMS for your migration in mid-2026 without issues, even if Azure Data Studio is no longer available.

In summary, for large databases, the online migration methods are generally preferred to minimize downtime, while DMS should remain operational for your planned migration timeline.

References: