How to Migrate SQL Server to Azure SQL Database

A SQL Server to Azure SQL migration starts with a choice that affects every later step. You need to know whether an offline BACPAC move fits your downtime window or whether Azure Database Migration Service is a better fit for a controlled cutover.

I checked Microsoft’s migration guide and BACPAC import documentation while preparing this walkthrough. Their guidance separates assessment, data movement, and post-migration checks, so the import wizard is only one part of the job.

Start with the service boundary, not the export dialog.

Choose the migration path before you export anything

Azure SQL Database is a platform-as-a-service database offering, not a hosted copy of every SQL Server feature. Start by confirming that its service model, feature set, and operational boundaries suit the database you plan to move.

Use a BACPAC for a planned offline move

A BACPAC is a package that contains a database schema and its data. It works well when you can pause writes, export a consistent copy, import it into a new Azure SQL Database, and complete verification before applications reconnect.

Choose this route for a smaller database, a development copy, a rehearsal, or a maintenance window with accepted downtime. A DACPAC is different because it carries schema information rather than the database data you need for this migration.

The package type determines what reaches the target.

Use Azure Database Migration Service when downtime must stay small

For a production database that must keep accepting writes until cutover, use the migration path described in the Microsoft SQL Server to Azure SQL Database migration guide. It covers assessment, data synchronization, cutover, and the post-migration work that an offline file import cannot perform by itself.

Azure Database Migration Service supports offline and online migration scenarios, but its prerequisites and limits depend on the source, target, and selected workflow. Read the current offline migration tutorial before you allocate a cutover window, because target preparation and migration monitoring are part of the procedure.

Check compatibility and prepare the target database

Do not treat an export that completes as proof that the database fits Azure SQL Database. Review the Azure SQL Database assessment rules for features such as cross-database references, SQL Server Agent jobs, linked servers, FILESTREAM, CLR assemblies, and server-level behavior that need a different design or remediation.

Make the compatibility check early enough to change the target choice. A database that depends on SQL Server instance features can need Azure SQL Managed Instance or SQL Server on Azure Virtual Machines rather than Azure SQL Database.

Microsoft’s assessment rules are a review list, not an automatic conversion tool.

Check each flagged dependency against the way your application uses it. A cross-database query may need a new data boundary, while a SQL Server Agent job may need an Azure service or another scheduled execution path.

• Record the source database name, SQL Server version, size, collation, compatibility level, and maintenance window.
• Inventory application connection strings, SQL logins, Microsoft Entra identities, firewall rules, agents, jobs, linked servers, and external dependencies.
• Create the Azure SQL Database with the intended compute tier, networking configuration, administrator or Microsoft Entra access, and a tested connection path.
• Run an assessment, save the findings, and resolve every blocker before the migration window begins.

Plan the target’s access controls before moving data. A successful import does not recreate every server-level login or application permission in the form your application expects, so connection and authorization tests belong in the cutover plan.

Database data and instance administration are separate migration concerns.

Move an offline database with a BACPAC

The offline route has a simple state transition. Stop or drain writes, create one export from the source, import that package into the prepared target, then verify the copy before directing application traffic to Azure.

Export the BACPAC from SQL Server

In SQL Server Management Studio, connect to the source database, open Tasks, and choose Export Data-tier Application. The wizard creates a BACPAC file that contains the selected database schema and data.

Keep the source stable during the export. If users continue to change records after the BACPAC is created, the package is a valid point-in-time copy but not the latest state of the production database.

Store the package in a protected location and record its source database, export time, and size. Those details let you tell a stale export from the package approved for the cutover.

Record the package identity before anyone begins the import.

Import the BACPAC into Azure SQL Database

The Azure portal can create a single Azure SQL Database from a BACPAC stored in Azure Blob Storage. Microsoft documents the portal flow, SqlPackage, Visual Studio Code, and PowerShell options in its BACPAC import quickstart.

If the package stays on your workstation, use the SSMS Import Data-tier Application wizard or a supported SqlPackage workflow instead of assuming the portal can read a local file. The SqlPackage documentation describes Export as a BACPAC operation and the current portability behavior.

Import into a new Azure SQL Database rather than overwriting a destination that applications already use. Give the target a deliberate name, select the planned compute tier, and wait for the import status to finish before starting validation.

Treat import failures as compatibility findings

An import failure is useful evidence about the package or target. Read the failed operation detail, identify the database object or unsupported behavior it names, and return to assessment rather than repeatedly importing the same package.

Some failures come from a target configuration that you can correct, such as access to the package location. Others reveal a database feature that Azure SQL Database does not support in the required form.

Keep the source unchanged while you resolve the issue. That preserves a known rollback point and prevents the investigation from mixing migration defects with later production changes.

Repeat the corrected import on a nonproduction copy when the maintenance plan allows it.

A rehearsal tells you how long the export, upload, import, and validation stages take with data that resembles the production workload. Use that observation to set a maintenance window that includes the checks you cannot skip after the target is available.

Validate the migration before cutover

Validation answers a different question from import completion. The import tells you that Azure accepted the package, while validation tells you whether the database and application can perform their intended work.

Do not combine those two checks into one approval.

• Compare expected schemas, tables, views, stored procedures, row counts, and critical aggregate totals between source and target.
• Run application smoke tests through the new Azure SQL connection string with the same identity model that production uses.
• Check failed logins, permission errors, unsupported SQL behavior, and slow queries before declaring the cutover complete.
• Update statistics and monitor the workload after cutover, as Microsoft’s migration guide recommends.

Do not remove the source database when the target opens successfully. Keep the rollback decision, source retention period, and recovery owner explicit until the application tests and data checks have passed.

Rollback remains a planned operation until acceptance is complete.

For a migration that requires a brief outage, take the final write stop seriously. Export or synchronize the final data state only after the application has stopped changing it, then switch connections after the target passes the checklist.

A final write stop makes the target state measurable.

Test the application path, not only database objects

Connect with the same configuration that your application will use after cutover. Test the operations that create, update, read, report on, and delete the records that matter to the business workflow.

Use a representative account, not an administrator shortcut.

Watch for differences that a schema comparison cannot expose. Query plans, collation behavior, time zones, network access, identity permissions, and application retry handling can affect a working workload after it reaches Azure.

Test the conditions that can change an application result.

Write down the acceptance checks before the maintenance window. A named owner can decide whether a failed check means you fix forward or reconnect the application to the retained source database.

Every acceptance check needs an owner and a rollback decision.

Common migration questions

The choice of tool follows the workload and downtime boundary. These answers cover the decisions that most often change the procedure.

Next step

Run the compatibility assessment before scheduling an export or outage. When Azure SQL Database fits the workload and the BACPAC route fits the downtime window, rehearse the export, import, and validation sequence against a nonproduction copy before the production cutover.