How would you run database migrations safely when deploying a .NET API to Azure App Service?

How would you handle database migrations during an Azure App Service deployment?

Explains safe migration strategy for Azure-hosted .NET APIs, including expand-contract changes, locking risk, rollback, and deployment order.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would avoid running risky database migrations blindly as part of a web app startup or slot swap. For a production App Service deployment, I would plan migrations as a controlled release step with backups, review, and compatibility checks. Additive changes are easiest: add a column or table first, deploy code that works with both shapes, backfill if needed, then remove old structures later.

Full answer below

Practice focus

Migration safety, backward compatibility, deployment ordering, rollback constraints, Azure SQL behavior, and production risk management.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Migrations are often the hardest part of a safe release. This drill matters because the production behavior is shaped by platform configuration, code boundaries, and the operational path the team will use during a real incident.
I would avoid running risky database migrations blindly as part of a web app startup or slot swap. For a production App Service deployment, I would plan migrations as a controlled release step with backups, review, and compatibility checks. Additive changes are easiest: add a column or table first, deploy code that works with both shapes, backfill if needed, then remove old structures later.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For EF Core or SQL migrations I would separate runtime app permissions from migration permissions. The web API usually needs limited data access, while migrations may need broader rights and a carefully controlled identity. I would test migration duration and locking against realistic data, run it before traffic switch when compatible, and keep the old code able to run if swap-back remains part of the plan. Destructive changes would move to a later release after old code no longer depends on them.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Running migrations from every API instance at startup.
Assuming slot rollback also rolls back the database.
Not reviewing generated SQL for locks.
Combining destructive schema changes with the app release that depends on them.

How would you run database migrations safely when deploying a .NET API to Azure App Service?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement