How to Move SQL Server Express to Azure SQL

Why SQL Server Express Users Are Looking at Azure SQL

Microsoft published a new migration guide on August 19, 2026, showing how developers can move applications from SQL Server Express to Azure SQL Database's free offer. The timing is useful because Express remains a convenient local database, but its resource limits can become restrictive as applications grow. 

SQL Server Express 2022 and earlier versions have a 10 GB maximum relational database size, while SQL Server 2025 Express raises that limit to 50 GB. Express also limits the Database Engine to four cores and about 1,410 MB of buffer-pool memory.

Azure SQL Database takes a different approach. Its free offer provides 100,000 vCore seconds, 32 GB of data storage, and 32 GB of backup storage per database each month, with up to 10 free databases allowed per Azure subscription. 

What You Should Know Before Migrating

The migration is not simply an edition upgrade performed on the same SQL Server installation. Azure SQL Database is a managed cloud database service, so you are moving the database and application connection from a local Express instance to a cloud-hosted database.

Microsoft's current migration guide assumes that you own the application and its connection string. If SQL Server Express was installed as part of another packaged application, check with the application's vendor before attempting the move because the software may not support Azure SQL Database as a target. 

There is another important limitation: Microsoft's Azure SQL documentation says an existing database cannot simply be restored into a free-offer database. The free offer is intended for newly created databases, so an actual migration needs an appropriate data and schema transfer method rather than assuming that a normal restore will work. 

Step 1: Check Your Existing SQL Server Express Database

Before creating anything in Azure, inspect the database you already have. Confirm the SQL Server version, database size, compatibility requirements, users, stored procedures, scheduled jobs, external dependencies, and application connection string.

If you are using SQL Server Management Studio or the MSSQL extension in Visual Studio Code, connect to the Express instance and identify the database you want to move. Microsoft specifically recommends SSMS or the MSSQL extension as the starting point in its current migration walkthrough. 

Pay particular attention to features that depend on the local SQL Server environment. Azure SQL Database is not a drop-in replacement for every SQL Server feature, so compatibility should be tested before switching a production application.

Step 2: Create the Azure SQL Database

Next, create a new Azure SQL Database using the free offer. Microsoft currently provides 100,000 vCore seconds of compute, 32 GB of data storage, and 32 GB of backup storage every month for each eligible free database. The allowance renews at the beginning of each calendar month. 

In the Azure portal, start the Azure SQL Database creation process and select the free option. The portal should show that the free offer has been applied and that the estimated monthly cost is zero under the free configuration. You then select the subscription, resource group, database name, and logical server before creating the database.

Do not confuse the free allowance with unlimited production capacity. The database can continue operating after the allowance is exhausted only if you choose the option that permits additional charges. Otherwise, the database can automatically pause until the next monthly allowance begins. 

Step 3: Move the Schema and Data

Once the destination database exists, migrate the schema and data from Express. The exact method depends on the application and database structure. For a straightforward application, you may use supported SQL migration tooling to transfer schema and data, then update the application connection string.

Microsoft's August 19 guide also demonstrates using GitHub Copilot to assist with the migration workflow. That can be useful for generating scripts and explaining compatibility issues, but generated migration code should be reviewed and tested rather than executed blindly. 

A safer workflow is to migrate a copy of the database first, run the application's test suite against Azure SQL Database, compare important query results, and only then consider switching the application's production connection.

Test the Application Before Switching Connections

Do not treat a successful database migration as proof that the application is ready. Test the application itself against the Azure database.

• Run normal application queries.
• Test inserts, updates, and deletes.
• Check stored procedures and views.
• Verify authentication and database permissions.
• Test background jobs and integrations.
• Compare important query results with the original database.
• Check application response times under realistic usage.
• Confirm that all required tables and indexes were migrated.

This testing stage is especially important when an application was designed around SQL Server features that may behave differently in Azure SQL Database.

How the Free Tier Compares With SQL Server Express

The comparison is not entirely one-sided. SQL Server Express can be preferable when you need a completely local database without cloud connectivity or Azure administration. Azure SQL becomes more attractive when managed backups, patching, cloud access, and reduced server maintenance matter more than keeping everything on one machine. 

How to Avoid Unexpected Azure Costs

The most important step is understanding what happens when the free allowance is consumed. Microsoft's documentation provides an auto-pause option that can stop the database until the next monthly period. You can instead allow continued usage beyond the free allowance, but that option can generate charges.

Idle connections can also matter. Microsoft recommends closing unused query tools such as SSMS or VS Code when you finish working because active connections can prevent the database from entering its paused state.

For development and testing, monitoring the remaining free vCore allocation is a simple way to avoid surprises. Azure provides metrics that show how much of the monthly allowance remains, and you can create an alert when usage becomes low.

Should You Use the Free Tier for Production?

This is where Microsoft's marketing language needs some context. The free database uses production-quality General Purpose infrastructure, but Microsoft's FAQ says the free offer does not include an SLA and recommends it primarily for development and proof-of-concept scenarios.

That makes the free tier particularly useful for prototypes, internal tools, development environments, integration testing, demos, and applications with intermittent workloads. For an important production application, plan for a paid Azure SQL configuration rather than assuming that the free allowance is an unlimited production solution.

A Better Local-to-Cloud Development Workflow

Developers who do not want every development task to depend on the cloud can keep a local SQL workflow while using Azure SQL as the cloud target. Microsoft's current guide also highlights Azure SQL Developer as a local container option in preview, allowing developers to work locally and later move the application to Azure SQL Database by changing the connection configuration.

This creates a practical workflow: build and test locally, migrate a representative database to Azure, validate the application against the managed service, and then decide whether the free tier or a paid tier is appropriate for the actual workload.

Common Migration Mistakes

• Assuming the free tier is unlimited: The monthly compute and storage allowances are real limits.
• Trying to restore an existing database directly into the free offer: Microsoft says restoration into a free-offer database is not supported.
• Skipping compatibility testing: A database that imports successfully can still expose application-level problems.
• Leaving development connections open: Idle connections can interfere with auto-pause.
• Switching production immediately: Test the migrated environment before changing the live connection string.
• Ignoring backup requirements: Free-tier backup storage has its own 32 GB allowance and feature limitations.

Frequently Asked Questions

Is Azure SQL Database really free?

The current free offer provides a monthly allowance of 100,000 vCore seconds, 32 GB of data storage, and 32 GB of backup storage per database. The offer has no time limit, but usage beyond the included allowance can become billable if you choose continued operation instead of auto-pause.

Can I restore my SQL Server Express backup directly into the free Azure SQL database?

No. Microsoft's current FAQ states that restoring an existing database to a free-offer database is not supported. A migration approach that transfers the required schema and data should be used instead.

Is SQL Server Express still useful?

Yes. Express remains useful for small local applications, learning, prototypes, and development environments where keeping the database on the same machine is important. Its limits become more significant as database size, memory requirements, compute requirements, or operational needs increase.

What happened to Azure Data Studio?

Azure Data Studio was retired on February 28, 2026. Microsoft recommends Visual Studio Code with the MSSQL extension for continued SQL development, while SSMS remains the supported choice for SQL Server Agent and broader traditional administration tasks. 

Final Takeaway

Moving from SQL Server Express to Azure SQL Database can be a sensible next step when local resource limits or server maintenance are becoming obstacles. The current Azure SQL free offer gives developers a practical way to evaluate the managed database platform without an immediate database-service bill, provided the workload stays within the included limits. 

The safest approach is not to think of the process as a simple SQL Server upgrade. Treat it as a migration: inspect the Express database, create a new Azure SQL destination, move and validate the data, test the application thoroughly, monitor the free allowance, and only then decide whether Azure SQL is the right long-term home for the workload.