TL;DR
For an Azure data migration, pick Managed Instance for SQL Server as-is, Azure SQL Database after compatibility fixes, and a VM for full control. Migrate online when downtime must stay in minutes, and go offline when a weekend outage is fine. Ship a Data Box when the network cannot finish the copy in time. Before wave one, define validated: matching row counts, checksums and business totals. Agree the rollback trigger too, and keep the source read-only until sign-off. Drop retired tools as well, since Data Migration Assistant retired in July 2025 and Azure Data Studio in February 2026.
Key Takeaways
Settle five decisions before any data moves: the target, online or offline transfer, wave order, the validation rule and the rollback trigger.
Match the target to the workload: Managed Instance for SQL Server as-is, Azure SQL Database after fixes, a VM for full control, and storage or Fabric for files and analytics.
Do the transfer math early: 20 TB over a 1 Gbps link takes about 44 hours at full line rate and about 56 hours at 80%.
Define pass rules and rollback triggers before cutover, and keep the source read-only until the business signs off.
Migration tooling is mostly free; the real costs are dual running, data transfer and the people who test each wave.
Remove retired tools from the runbook: Data Migration Assistant retired in July 2025 and Azure Data Studio in February 2026.
Watch on YouTube
Why Data Platform Migration Succeeds or Fails
Manisha Chowdari, Head of Business Analysis at Kanerika, talks through why data platform migrations succeed or fail, a useful frame before you plan your own move to Azure.
The 20-Minute Window That Shapes Every Choice
Picture an online retailer moving its order database from an on-premises SQL Server to Azure SQL. So far, the team has picked the target, booked a weekend and told the business. Then operations sets one condition: orders can stop for 20 minutes, no longer.
That single number then rewrites the plan. Over a 1 Gbps link, copying a 2 TB database takes about four and a half hours on its own. That is because 2 TB is 16,000 gigabits, so the copy needs 16,000 seconds at full line rate. A backup-and-restore move is out, so the team now needs continuous replication, a rehearsed cutover and a clear rule for when to roll back.
This is why an Azure data migration is, above all, a sequence of decisions. The sections below follow the order the retailer had to work in: decide first, then choose the tools, then prove the copy.
What Azure Data Migration Covers
Azure data migration means moving data, and the systems that hold it, from where it lives today into Azure services. The source might be an on-premises SQL Server, an Oracle database, a file server, an older warehouse or another cloud.
Scope matters because each kind of data has its own target, its own tool and its own way of failing. Databases, for example, fail on engine compatibility and downtime. File shares fail on permissions, while data warehouses fail when reports stop matching and pipelines fail on dependencies nobody wrote down.
One boundary also helps early. Moving whole servers and applications as virtual machines, often called lift-and-shift, is a related but separate job. For the wider taxonomy, our overview of the types of data migration also lays out storage, database, application and cloud moves side by side.
Data type Typical source Azure target Main risk
Relational databases SQL Server, Oracle, MySQL Azure SQL Database, Azure SQL Managed Instance, SQL Server on Azure VMs Engine capabilities the target lacks Files and objects NAS shares, SMB or NFS servers, Amazon S3 buckets Azure Files, Blob Storage, ADLS Gen2 Lost permissions and broken share paths Warehouse and analytics On-premises warehouse, Azure Synapse ADLS Gen2, Microsoft Fabric Reports that return different numbers Pipelines and ETL SSIS packages, scheduled scripts Azure Data Factory, Fabric Data Factory Jobs that depend on servers nobody listed Cross-cloud data AWS or Google Cloud services The matching Azure services Egress charges and identity mapping
The cross-cloud row deserves its own plan, since landing zones and service mapping differ by provider. Our guide to migrating from AWS to Azure covers that path in depth.
Why Teams Move Data to Azure
The business case usually rests on cost and upkeep. Microsoft’s Cloud Adoption Framework lists the common drivers: lower capital spend, freed datacenter space and less patching and recovery work.
In a forecast dated November 19, 2024, Gartner predicted that 90% of organizations will adopt a hybrid cloud approach through 2027. It expected data synchronization across hybrid environments to be the most urgent GenAI challenge of the following year. That is one reason this guide spends so long on sync, validation and rollback.
Five Decisions to Settle Before You Start
Five decisions shape everything else in the project, and each one gets harder to change once data starts moving. Settle them in writing before the pilot, with the business owner in the room as well as the platform team.
Go back to the retailer. Suppose it had chosen Azure SQL Database and then found an engine capability the service lacks. In that case, it would have redesigned the target in the middle of the move. A written decision, checked against an assessment, prevents exactly that.
Target platform. Decide where each workload lands: Azure SQL Database, Managed Instance, a SQL Server VM, Azure Storage or Fabric. The target fixes your tool, your downtime options and your run cost.Online or offline. Online keeps the source live and syncs changes until cutover. Offline stops writes, copies the data, then switches. Pick by the downtime the business accepts.Wave order. Group databases and files that depend on each other into the same wave. Start with a representative workload, never the most critical one.What “done” means. Write the reconciliation rule before wave one: which counts, checksums and totals must match, and who signs off.Rollback trigger. Agree the thresholds that send you back to the source, and how long the source stays read-only.
You can answer every one of them before choosing a single tool. Each needs an owner, a date and a written record, because an undocumented decision tends to get reopened under pressure on cutover night.
For the platform choice itself, our data platform migration decision framework goes deeper. The rest of this guide takes each decision in turn.
Choosing the Azure Target
The target comes first because it narrows every later choice. A database, a file share and an analytics estate each have a natural home in Azure. When the pick is wrong, it usually shows up as rework during the pilot.
Databases tend to go first, since they hold the most business logic and the tightest downtime limits. Files and analytics then follow, each with trade-offs of their own.
Azure SQL Database vs Managed Instance vs SQL Server on Azure VMs
For SQL Server, the question is how much of the engine you need against how much management you want to hand over. Microsoft’s Managed Instance overview , dated February 19, 2026, puts Azure SQL Managed Instance at near 100% compatibility with the SQL Server Enterprise Edition engine. Its update policy pins the instance to the SQL Server 2022 or SQL Server 2025 engine, or keeps it always up to date. So it is the natural home for a database that must move with few changes.
Azure SQL Database is the most managed option, with patching, backups and high availability handled for you. It suits applications you are willing to adjust when a feature is missing.
SQL Server on an Azure VM sits at the opposite end of the scale from Azure SQL Database. You keep full control of the operating system and the engine, so it covers features neither managed service supports. The price of that control is that your team patches, backs up and tunes the server itself.
Option Choose it when Trade-off
Azure SQL Managed Instance A SQL Server estate must move with minimal code change Less control than a VM; you size and pay for the whole instance Azure SQL Database You can fix compatibility gaps and want the least to manage Some instance-level features are not available SQL Server on Azure VMs You need OS access or a feature no managed option supports You patch, back up and tune it yourself
Blob Storage, ADLS Gen2 or Azure Files
Files follow a simpler rule: choose the target by how the data will be read after the move. Applications and users that mount a share over SMB or NFS need Azure Files, so paths and scripts keep working.
Objects such as backups, images and exports belong in Blob Storage. Data that is heading for analytics lands in ADLS Gen2, which adds a folder hierarchy and fine-grained access control on top of Blob Storage. If you are still deciding how that analytics layer should work, our comparison of data lake vs lakehouse sets out the trade-offs.
Data Target Why
Shared drives mounted by apps and users Azure Files Keeps SMB or NFS access Backups, media and exports Blob Storage Object storage with hot, cool and archive tiers Raw data for analytics ADLS Gen2 Folder hierarchy and access control for analytics engines
When Microsoft Fabric Belongs in the Plan
If the data feeds reporting and analytics, ask whether it should land in Microsoft Fabric rather than a standalone database or lake. Fabric keeps data in OneLake and puts Data Factory , warehousing and Power BI in one service. A warehouse move can therefore land once instead of twice.
The question matters most when an estate is already built on Azure Data Factory or Synapse. That move is a project of its own, covered in our guide to moving Azure Data Factory and Synapse workloads to Fabric . For a plain line-of-business database, Azure SQL is still the simpler target.
Kanerika Service
Azure Cloud Solutions
Kanerika designs Azure landing zones, identity and data platforms, so databases, files and analytics workloads land on the right target from the first wave.
Explore Azure Cloud Solutions Rehost, Replatform or Refactor: Match the Approach to the Scenario
Once the target is clear, decide how much you will change on the way. Rehosting moves the data as it is, so nothing changes on the way. Replatforming moves it to a managed service with small fixes, and refactoring rebuilds the logic around the new platform.
The right answer depends on the workload rather than on a company-wide policy. A finance database with years of stored procedures might move as-is to Managed Instance, while its nightly ETL is rebuilt in Azure Data Factory. Both choices can still sit inside the same program, in different waves.
Microsoft’s Cloud Adoption Framework names five more options beyond these three: retire, retain, rearchitect, rebuild and replace. Two of them matter often in data work. Retire the tables and reports nobody reads instead of moving them, and replace a custom system with a SaaS product when it needs little customization.
Scenario Approach Main tool Downtime profile
SQL Server to Azure SQL Managed Instance, as-is Rehost Azure Database Migration Service, online Minutes at cutover SQL Server to Azure SQL Database with fixes Replatform Azure Database Migration Service, offline A planned window Oracle to Azure SQL Refactor schema and code SQL Server Migration Assistant (SSMA) for Oracle A planned window after testing Legacy SSIS or script ETL Refactor Azure Data Factory or Fabric Data Factory Parallel run, then switch NAS file shares to Azure Files Rehost Azure Storage Mover Final sync and a short freeze
The Oracle row is the hardest, because schemas and code change along with the rows. That is why it helps to understand data conversion versus data migration before you size it. Per Microsoft’s SSMA for Oracle documentation , the tool targets SQL Server 2019 and later, Azure SQL Database and Azure SQL Managed Instance.
Azure Data Migration Tools in 2026
Microsoft provides a family of migration tools, and each one does a specific job. Choosing well means matching the tool to the data type and the kind of move, rather than hunting for one tool that does everything.
The table below maps each tool to its job. A typical program uses three or four of them. For example, Azure Migrate plans the work, DMS moves the databases and Storage Mover handles the file shares.
Tool What it does Use it for
Azure Migrate Discovers and assesses servers, databases and web apps, and right-sizes targets Inventory, readiness and planning Azure Database Migration Service (DMS) Managed database migration, online or offline SQL Server to Azure SQL targets Azure Data Factory Pipeline service that copies and transforms data Repeatable loads and ETL rebuilds Azure Storage Mover Managed migration of files from SMB or NFS shares and Amazon S3 File shares to Azure Storage AzCopy Command-line copy to and from Azure Storage Scripted bulk copies Azure Data Box Physical device shipped to your site and back Datasets the network cannot move in time SSMA Converts schemas and code from Oracle and other engines Database moves between different engines
Azure Migrate vs DMS vs Azure Data Factory
These three are the ones teams mix up most, so it pays to separate them. Azure Migrate is the planning hub. It assesses on-premises SQL Server instances for Azure SQL Database, Managed Instance or SQL Server on VMs, then recommends sizes. Microsoft’s Azure Migrate overview describes both steps. Our guide to the Azure Migrate hub covers assessment in more depth.
DMS then performs the database move itself. According to the DMS overview , it runs online and offline migrations to Managed Instance and SQL Server on Azure VMs. For Azure SQL Database, however, it supports offline migrations only.
Azure Data Factory is a different kind of tool. It is a pipeline service, built for scheduled loads that transform data along the way. So use it when the migration is really a rebuild of data flows. If you are also choosing a long-term pipeline platform, compare it with other data integration tools first.
On-Demand Webinar
Cloud Migration Strategies: Accelerate Your Business Outcomes
An on-demand Kanerika webinar on cloud migration strategies, and on how the right migration plan improves decision-making and business outcomes.
Watch the Webinar → Retired Tools to Stop Planning Around
Older runbooks still name tools that Microsoft has retired. Take them out of the plan before the pilot, or the team will lose days on dead ends.
Data Migration Assistant (DMA): retired from July 16, 2025, per the DMA overview . Use Azure Migrate, or the Azure Arc migration assessment , for SQL Server assessment instead.Azure Data Studio and its Azure SQL migration extension: retired on February 28, 2026, with no further updates or security fixes. Microsoft’s retirement notice points users to VS Code with the MSSQL extension and to dedicated migration tooling for each target.Azure Data Box Heavy: retired, per the Data Box overview . The next-generation Data Box ships in 120 TB and 525 TB usable capacities, and the 80 TB device is being retired region by region.
Moving the Data: Online vs Offline Transfer
The transfer path is an arithmetic problem before it is a tooling problem. Three numbers decide it: how much data you have, how fast it changes and how long the business can wait.
Online transfer copies data over the network while the source stays in use, then syncs the final changes at cutover. Offline transfer either stops writes during the copy or ships the data on a physical device. For databases, DMS handles both modes, while for large file sets Azure Data Box carries the bulk and a network sync catches up the rest.
Worked Example: 20 TB Over a 1 Gbps Link
Here is the worked math for a 20 TB dataset over a dedicated 1 Gbps link. It also assumes decimal terabytes, no compression and a steady rate.
20 TB x 8 bits per byte = 160,000 gigabits.
At full line rate: 160,000 gigabits / 1 Gbps = 160,000 seconds, about 44.4 hours.
At 80% utilization: 160,000 / 0.8 Gbps = 200,000 seconds, about 55.6 hours.
That is more than two days of copying before any validation starts. With a weekend window and a shared link, the copy will probably not finish. In this case, a Data Box for the bulk plus a network sync for the changes is the safer plan.
The retailer from the opening faces the same sum at a smaller scale. Its 2 TB copy needs about four and a half hours, far beyond a 20-minute limit. So the copy has to run online, through DMS Premium to Managed Instance, with a final sync at cutover.
Choosing the Transfer Path
Situation Path Tool
Database with a short downtime limit Online DMS, Premium tier Database where a weekend window is acceptable Offline DMS, Standard tier Files that copy inside the window at your measured rate Online Azure Storage Mover or AzCopy Tens of terabytes, or a slow or shared link Offline device, then sync Azure Data Box, then AzCopy or Storage Mover Continuous loads during a long transition Online, scheduled Azure Data Factory
Two AzCopy settings decide how hard a file copy pushes the link. Run azcopy benchmark first, since it reports a recommended value for the AZCOPY_CONCURRENCY_VALUE variable. On a shared link, add --cap-mbps to put a ceiling on throughput. Microsoft’s AzCopy performance guide also advises keeping each job under 10 million files.
Run the same sum with your own numbers, using a bandwidth you have measured with a real test copy. If the result is longer than your window, the decision is made for you.
The Azure Data Migration Process, Step by Step
A dependable migration runs in seven stages, and each one produces something the next stage needs. Skipping a stage rarely saves time; it only moves the problem to cutover night.
1. Inventory and Assess
List every database, file share, data pipeline and report, with its owner, size and dependencies. Run Azure Migrate to check SQL Server readiness and size the targets.
Also note which jobs, linked servers and logins each database relies on. These are the things that break after a test cutover.
2. Select the Target and Method
Map each workload to a target and an approach from the tables above. Record the downtime each owner accepts, because that number decides between online and offline. For the retailer, the order database goes to Managed Instance online, because its owner accepts only 20 minutes.
3. Prepare the Landing Zone, Identity and Network
Build the subscriptions, networks, private endpoints and Microsoft Entra ID groups before any data arrives. Then test bandwidth with a real copy rather than a vendor estimate, since your measured rate feeds the transfer math.
4. Pilot One Representative Workload
Pick a typical workload with real tables, jobs and users. Run it end to end, including validation and a rehearsed rollback, and time every step.
The pilot’s real durations then replace guesses in the wave plan. If the pilot copy overran, you have learned it at the cheapest possible moment.
5. Migrate in Waves
Move dependent systems together, in waves small enough to validate before the window closes. Freeze changes on each wave’s source from the final sync until sign-off, so the numbers you reconcile stay fixed.
For the retailer, wave one holds the order database and the reporting replica that reads from it. The ETL jobs that load the warehouse follow in wave two, once wave one has passed its checks.
6. Validate
Reconcile counts, checksums and business totals, then ask the business owner to confirm the key reports against the pass rules set out below. For the retailer, order counts and daily revenue must match on both systems before the owner signs off.
7. Stabilize, Optimize and Retire Legacy
Watch performance and cost closely in the first weeks, and tune indexes and service tiers as real load arrives. Set up data observability so freshness and volume problems surface before users report them.
Retire the source only after the agreed hold period, and remove the migration accounts and credentials once it is gone.
Kanerika Service
Data Migration Consulting Services
Assessment, wave planning, migration and reconciliation for databases, files and pipelines moving to Azure, with validation and rollback rules agreed up front.
Explore Migration Services Validation, Cutover and Rollback
Validation is where a migration earns trust, and it is the part many guides skip. A copy that finished without errors can still be wrong, because a truncated column, a time zone shift or a missed partition all pass silently.
The fix is to define the checks and their pass rules before wave one, then run them the same way for every wave. Keep the source read-only until sign-off, so a rollback stays a switch instead of a rebuild.
What to Reconcile Before Sign-off
Always run the checks from cheap to expensive, so early failures cost little. Row counts catch missing data fast, checksums catch changed values, and business totals catch the errors that only matter to finance.
Check How Pass rule
Row counts Count rows per table on source and target Exact match per table Checksums or hashes Hash rows or columns on both sides Identical per table or partition Business-rule totals Sum revenue, units or balances by period Match within the agreed tolerance Report parity Run the key reports on both systems Same figures on the same filters Performance baseline Time the top queries and jobs Within the agreed baseline
For SQL Server sources, one short T-SQL query gives a first signal. Run it on the source and on the target, then compare the two results.
-- Run on source and target, then compare both columns
SELECT COUNT_BIG(*) AS row_count,
CHECKSUM_AGG(BINARY_CHECKSUM(*)) AS table_checksum
FROM dbo.Orders;A matching checksum is a strong signal, not proof, since different data can produce the same checksum. Use it to find the tables that need a row-level comparison, and confirm the finance totals separately.
Rollback Triggers to Agree in Advance
Rollback only works if the trigger is agreed before cutover night, when nobody is tired or under pressure. Write the rules down and name the one person who makes the call.
Any table fails its row count or checksum rule after the final sync.
Business totals differ by more than the agreed tolerance.
Critical reports or applications fail their smoke tests.
Key queries run slower than the performance baseline allows.
The cutover runs past the agreed window.
Keep the source read-only, not deleted, until the business signs off. A failed check then means pointing applications back at the source, which is a connection change rather than a restore.
What Azure Data Migration Costs
The migration tools are mostly free, so the costs sit in running two systems at once, in moving the data and in the people doing the work. Budget each one separately so none of them surprises finance.
According to the DMS pricing page , the Standard tier is free and offline only. The Premium tier also supports online migration, and its 4-vCore option is free for the first six months (183 days). The Azure Migrate pricing page lists its assessment and migration tools as free. Server migration is free for 180 days per machine, then $25 per month per replicated instance.
Dual Running and Licenses
The bigger line, however, is dual running. From the day the target goes live until the source retires, you pay for both. Licenses can soften that cost, so review your options for Microsoft licensing optimization before wave one.Azure Hybrid Benefit lets you apply SQL Server licenses with Software Assurance to Azure SQL Database and Managed Instance. Microsoft puts the saving at up to 30% or more. For Azure SQL Database, it applies only to the provisioned vCore tier, not to DTU or serverless.
Cost Items to Budget
Cost item What drives it Note
Database migration tooling DMS tier and how long you use it Standard is free; Premium 4-vCore is free for six months (183 days) Azure Migrate Servers replicated beyond 180 days $25 per month per replicated instance after the free period Target run cost during dual running Service tier and weeks of overlap Hybrid Benefit can cut SQL costs by up to 30% or more Transfer and storage Data volume, device shipping, egress from other clouds Storage and transfer charges apply even when tools are free People and testing Number of waves, validation cycles and rehearsals Grows with scope and with every failed rehearsal
Shortening the dual-run period is the most direct saving you control. It is one more reason to validate quickly and retire each source on schedule.
Common Challenges and the Fix for Each
Migration problems usually announce themselves early, if you know the signs. The table pairs each common challenge with the first sign it gives, the fix and the stage where that fix belongs.
Challenge Early sign Fix Stage
Compatibility gaps The assessment flags unsupported features Choose Managed Instance or a VM, or refactor the code Assess Downtime overrun The pilot copy runs longer than the window Switch to online migration, or Data Box plus sync Pilot Hidden dependencies Jobs fail after a test cutover Map linked servers, jobs and feeds, then move dependents in one wave Inventory Poor data quality Reconciliation fails on legacy rows Clean or quarantine at the source before the final sync Validate Lost permissions Users cannot open migrated files or tables Map identities to Microsoft Entra ID groups before the move Landing zone Cost overrun Dual running stretches past the plan Set a retirement date per source and track it weekly Stabilize
Look down the Stage column and a pattern appears: almost every fix lands before cutover. The cheapest moment to solve a problem is the stage where its first sign shows up.
Hidden dependencies deserve special care, because they hide well. A linked server, a nightly export to a partner or a report that reads a table directly rarely appears in an application inventory. Ask each owner what would break if the source server went offline for an hour, then add every answer to the wave plan.
Cost overrun, unlike the others, keeps growing after go-live. A business case written before wave one, with the dual-run weeks priced in, gives the team a number to hold the plan against.
Migration ROI Calculator
What Will Your Azure Migration Return?
Use Kanerika’s Migration ROI Calculator to estimate the savings and payback of moving your data platform, dual-run period included, before you commit to wave one.
Calculate Migration ROI → Security and Governance During the Migration
Data in motion is data at risk, so security and enterprise data governance need a plan of their own. The aims are simple: control who touches the data, protect it on the way and keep a record of where it went.
Identity comes first, before any data moves. Map source accounts to Microsoft Entra ID groups, the service formerly called Azure Active Directory, and grant each wave only the access it needs. Encrypt every transfer in transit and keep encryption at rest switched on at each target.
Microsoft’s migration planning guidance puts ExpressRoute first, then a VPN, with Data Box for large offline moves. It keeps the public internet for less sensitive data. Data Box itself encrypts data with AES 256-bit at all times, and Microsoft wipes its disks to NIST 800-88r1 after upload.
Identity: Entra ID groups, least privilege, and separate migration accounts that are removed after cutover.Encryption: TLS for every transfer and encryption at rest on every target.Catalog and lineage: register sources and targets in Microsoft Purview , so lineage shows where each table came from.Residency: pick regions that meet your data residency rules before the landing zone is built.
Lineage matters more than it first seems. After cutover, auditors and analysts will ask where a number came from, and a catalog with lineage answers that without a hunt through old scripts. Our comparison of data governance tools covers Purview alongside the other options.
Azure Data Migration Readiness Checklist
Use this checklist as the gate before wave one. If any item is still open, the migration is not ready to start, however good the plan looks on paper.
Every database, share, pipeline and report is inventoried with a named owner.
The Azure Migrate assessment is complete and targets are sized.
Each workload has a target and an approach: rehost, replatform or refactor.
Each owner has signed off the downtime they accept, and online or offline is chosen.
Waves are grouped by dependency, and the pilot workload is named.
The landing zone, network and Entra ID groups are built and tested.
Measured bandwidth confirms the transfer fits the window, or a Data Box is booked.
Validation checks and pass rules are written and agreed.
Rollback triggers, the decision owner and the source hold period are agreed.
No retired tool, such as DMA or Azure Data Studio, appears in the runbook.
A list like this turns a vague “are we ready?” into ten yes-or-no answers, while each “no” points straight at the stage to revisit.
Checklist
Microsoft Azure Checklist
Download the Microsoft Azure Checklist to assess cloud readiness, improve security, manage costs and build a reliable Azure environment before wave one.
Get the Checklist → How Kanerika Runs Azure Data Migrations
Kanerika starts every Azure data migration with an assessment, because the five decisions above depend on what the estate really contains. We inventory sources and dependencies, design the target and agree validation and rollback rules with the business before any data moves. Our data migration services cover that full path, while our Azure cloud solutions team builds the landing zone.
Delivery then follows the sequence this guide describes. A pilot on a representative workload comes first, followed by migration in waves and reconciliation against the agreed pass rules. A hypercare period then runs before the source retires. Where pipelines and reports need converting, FLIP , our migration accelerator, automates that conversion so engineers can spend their time on testing.
Reconciliation carries the same weight on every project. In a cloud application migration for a global spend-management provider in logistics, data kept flowing in throughout the move. Our team validated data integrity and the client’s business rules through reconciliation, and the project delivered 60% faster error resolution. Kanerika holds ISO 27001 and ISO 27701 certification, SOC 2 and GDPR compliance, and a CMMI Level 3 appraisal.
A North American steel mill services provider with a 96-year history shows the result. Before the project, its legacy system had a complex interface, limited encryption types and a heavy processing cost. Kanerika moved its data onto Azure data engineering, bringing in Dynamics AX data and Power BI dashboards. The outcome was a 25% reduction in storage expenses, a 40% improvement in productivity and a 2.5% increase in revenues. Our steel manufacturing case study details the full project.
Case Study
25% Lower Storage Costs for Steel Manufacturing on Azure
A North American steel mill services provider moved off an outdated legacy system onto Azure data engineering with Dynamics AX data and Power BI dashboards: 25% lower storage expenses, 40% higher productivity and a 2.5% revenue increase.
Read the Case Study → The Bottom Line on Azure Data Migration
An Azure data migration succeeds or fails on choices made before the first byte moves. Choose the target per workload, pick online or offline by the downtime the business accepts, and order the waves by dependency.
Then write down what validated means and what triggers a rollback, and keep the source read-only until sign-off. Settle those five decisions in writing before you start, and the migration becomes a schedule to run rather than a series of surprises.
Frequently Asked Questions
What is Azure data migration?
Azure data migration is the process of moving databases, files, warehouses and pipelines from on-premises systems or another cloud into Azure services. Typical targets are Azure SQL Database, Azure SQL Managed Instance, SQL Server on Azure VMs, Blob Storage, ADLS Gen2, Azure Files and Microsoft Fabric. Each data type needs its own target, tool and validation plan.
What is the Azure migration process?
A dependable Azure migration runs in seven stages: inventory and assess, select the target and method, prepare the landing zone, pilot one representative workload, migrate in waves, validate, then stabilize and retire the legacy system. Each stage produces something the next one needs, so skipping a stage usually moves the problem to cutover night instead of saving time.
How long does a typical Azure data migration take?
Duration depends on data volume, the number of waves and how much code changes. A single database can move in days, while an estate with many dependent systems runs for months in waves. Do the transfer math early: 20 TB over a 1 Gbps link takes about 44 hours at full line rate.
How much does Azure data migration cost?
The tools cost little. DMS Standard is free, DMS Premium 4-vCore is free for six months (183 days), and Azure Migrate’s assessment tools are free. The real costs are running source and target in parallel, data transfer and storage, and the people who test each wave. Azure Hybrid Benefit can cut Azure SQL costs by up to 30% or more.
How is Azure data migration different from regular cloud migration?
Cloud migration usually means moving servers and applications, often as virtual machines. Azure data migration focuses on the data itself: databases, files, warehouses and pipelines, and on proving that every row arrived intact. It needs extra work on schema compatibility, reconciliation and rollback rules, because a copy can finish without errors and still be wrong.
What types of data can be migrated to Azure?
Almost any data can move to Azure. Relational databases such as SQL Server, Oracle and MySQL go to Azure SQL services. File shares go to Azure Files, objects and backups to Blob Storage, and analytics data to ADLS Gen2 or Microsoft Fabric. ETL pipelines can be rebuilt in Azure Data Factory or Fabric Data Factory.
What is the difference between Azure Migrate and Azure Database Migration Service?
Azure Migrate is the planning hub. It discovers servers and SQL Server instances, checks readiness for Azure SQL Database, Managed Instance or SQL Server on VMs, and recommends target sizes. Azure Database Migration Service performs the actual database move, online or offline. Most projects use Azure Migrate to plan and DMS to migrate the databases afterwards.
Azure Data Factory vs DMS: which is better for migration?
They do different jobs. DMS is built for one-time database moves from SQL Server to Azure SQL targets, with online sync for short cutovers. Azure Data Factory is a pipeline service for scheduled copies and transformations. Use DMS to move a database as a whole, and Data Factory when you are rebuilding ETL or running repeated loads.
Can Azure data migration be done without downtime?
Near-zero downtime is possible, but some cutover pause remains. Online migration with Azure Database Migration Service keeps the source in use and syncs changes until you switch, so the pause can shrink to minutes. Online mode is supported for Azure SQL Managed Instance and SQL Server on Azure VMs, while Azure SQL Database is offline only.
Can I migrate Oracle databases to Azure SQL?
Yes. SQL Server Migration Assistant for Oracle converts Oracle schemas and code and moves the data to SQL Server 2019 or later, Azure SQL Database or Azure SQL Managed Instance. Treat it as a refactoring project, because stored procedures and data types change. Test converted code thoroughly and plan a cutover window after the testing is complete.
What is the best way to move very large datasets to Azure?
Work out the transfer time first. If your measured bandwidth cannot copy the data inside the window, ship it on Azure Data Box, whose next-generation devices come in 120 TB and 525 TB usable capacities. Then use AzCopy or Azure Storage Mover over the network to sync the changes made while the device was in transit.
How do I validate data after an Azure data migration?
Run checks from cheap to expensive. Compare row counts per table, then checksums or hashes, then business totals such as revenue by period, then key reports on both systems, then query performance against a baseline. Agree the pass rule for each check before wave one, and keep the source read-only until every check passes.
Will my business experience downtime during Azure data migration?
Some downtime is normal, but you control how much. Online migration keeps the source live and syncs changes until a short cutover, often minutes. Offline migration stops writes during the copy, so it suits workloads that can pause for a planned window. Agree the acceptable downtime with each business owner before you choose the method.
How do I migrate an on-premises SQL Server database to Azure?
Assess the instance with Azure Migrate to choose Azure SQL Database, Managed Instance or SQL Server on a VM. Build the landing zone and identity, then use Azure Database Migration Service, online for short downtime or offline for a planned window. Reconcile counts, checksums and totals, and keep the source read-only until sign-off.
Is data secure during Azure data migration?
Data stays secure when the migration has its own security plan. Map accounts to Microsoft Entra ID groups with least privilege, encrypt every transfer in transit and keep encryption at rest on each target. Register sources and targets in Microsoft Purview for lineage, and remove temporary migration accounts and credentials once the cutover is complete.
How can I ensure a smooth Azure migration?
Settle five decisions in writing before any data moves: the target, online or offline transfer, wave order, the validation rule and the rollback trigger. Then pilot one representative workload end to end, including a rehearsed rollback, and use its real timings to plan the waves. Keep each source read-only until the business signs off.
What if our legacy applications don't work with Azure?
Start with an Azure Migrate assessment to see which capabilities the target lacks. If a SQL Server database relies on engine features, Azure SQL Managed Instance offers near 100% engine compatibility. If you need operating system access, use SQL Server on an Azure VM. Code that cannot move as-is can be refactored in a later wave.
What are the 5 Rs of Azure migration?
The 5 Rs are rehost, refactor, rearchitect, rebuild and replace. Rehost moves workloads as they are, refactor makes small changes for a managed service, rearchitect redesigns for cloud services, rebuild rewrites the application, and replace swaps it for a SaaS product. For data, most programs mix rehost, replatform-style fixes and refactoring across different waves.
What are the four types of data migration?
The four common types are storage migration, database migration, application migration and cloud migration. An Azure project often combines several of them, for example moving file shares to Azure Files while databases move to Azure SQL. Our guide to the types of data migration explains each type, its risks and the tools usually used for it.
What are the biggest challenges in Azure data migration?
The most common challenges are compatibility gaps, downtime overruns, hidden dependencies, poor data quality, lost permissions and cost overruns from long dual running. Each one shows an early sign, such as assessment warnings or a slow pilot copy. Fixing it at the stage where the sign appears is far cheaper than fixing it at cutover.
What tools does Microsoft offer for Azure data migration?
The main tools are Azure Migrate for discovery and assessment, Azure Database Migration Service for database moves, Azure Data Factory for pipelines, Azure Storage Mover and AzCopy for files, Azure Data Box for very large offline transfers, and SSMA for Oracle and other engines. Data Migration Assistant and Azure Data Studio are retired.
