A pending migration means the application already knows about a database schema change, but the database has not received it yet. The code might expect a new table, column, index, or constraint that is missing in production. In Azure, this often appears during App Service, Functions, container, or pipeline deployments connected to Azure SQL, PostgreSQL, or another managed database. It is not just a developer warning; it is a sign that release order, approval, connection strings, and rollback plans need attention.
EF Core pending migration, unapplied migration, database migration pending, schema migration drift, pending model change
Difficulty
intermediate
CLI mappings
4
Last verified
2026-05-17
Microsoft Learn
A pending migration is an Entity Framework Core migration that exists in application code but has not been applied to the target database. In Azure-hosted apps, it signals schema drift between deployment artifacts and databases, requiring controlled review, scripting, application, and rollback planning before production traffic depends on the change.
In Azure architecture, a pending migration sits between application deployment and the database data plane. EF Core stores applied migrations in a migrations history table, while source code and build artifacts contain the available migration files. CI/CD systems, deployment slots, App Service settings, managed identities, Key Vault references, and database firewall rules all affect whether the migration can be inspected or applied safely. Operators usually validate it outside Azure Resource Manager, then use Azure CLI to confirm target resources, network access, backups, and release state.
Why it matters
Pending migration matters because application code and database schema must move together. If code reaches production before the schema change, users may see runtime errors, missing columns, failed writes, or broken reports. If the migration is applied without review, it may lock tables, drop data, or change indexes during peak traffic. Azure teams also need evidence for which database, slot, region, and connection string will be touched. Treating pending migrations as release gates helps prevent silent schema drift, makes rollback realistic, and gives database owners time to review generated SQL before customers depend on the change. That clarity prevents late-night guesswork when database schema and deployed code disagree.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In deployment pipeline logs, EF Core tooling reports migrations that exist in the build artifact but are absent from the target database history table during release readiness reviews and incident triage.
Signal 02
In application startup or request logs, missing table, column, index, or constraint errors appear after code reaches an Azure-hosted app before schema rollout during slot swaps, rollback planning, and production readiness checks.
Signal 03
In release review notes, teams compare migration IDs, generated SQL scripts, target database names, deployment slots, and backup timestamps before approving production changes during release audits and schema-drift investigations.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Block a production deployment until generated EF Core SQL has been reviewed and approved.
Compare migration history between a staging slot database and the production database.
Plan a safe Azure SQL or PostgreSQL schema change with backups, locks, and rollback evidence.
Diagnose application errors caused by code expecting a schema version that has not been applied.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Subscription billing schema gate
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
MetricForge ran a billing analytics SaaS on App Service with Azure SQL. A new invoice-adjustment feature added two EF Core migrations, but pipeline logs showed they were pending against the production database.
🎯Business/Technical Objectives
Prevent application code from reaching production before required schema objects existed.
Review generated SQL for destructive operations and lock duration before approval.
Capture Azure resource evidence for database, slot, and connection-string scope.
Reduce failed billing requests during monthly close by at least 80 percent.
✅Solution Using Pending migration
The platform team changed the deployment pipeline so build output generated an idempotent EF Core SQL script and compared the latest migration ID with the production migration history table. Azure CLI steps captured the App Service slot, Azure SQL database resource ID, service principal, and Key Vault-backed connection setting before approval. The migration ran in a scheduled window after a verified backup, then the staging slot warmed up against the upgraded schema before swap.
📈Results & Business Impact
Failed billing API requests during close dropped 91 percent after schema and code moved in order.
DBA review time fell from two hours to 35 minutes because every migration carried generated SQL and target evidence.
Rollback drills confirmed the team could restore the database and redeploy the prior slot within 25 minutes.
Audit findings about unmanaged schema changes were closed with pipeline records and migration history screenshots.
💡Key Takeaway for Glossary Readers
Pending migrations become safer when Azure evidence, database history, and application release order are treated as one deployment gate.
Case study 02
Transit portal slot rollout
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
Northline Transit hosted a rider portal in App Service and stored trip preferences in Azure Database for PostgreSQL. A release added nullable columns for accessibility settings, but the staging slot showed pending migrations before swap.
🎯Business/Technical Objectives
Keep the rider portal available during a regional timetable update.
Prove the staging and production slots targeted the correct PostgreSQL databases.
Apply schema changes without exposing database credentials in pipeline logs.
Verify post-migration app health before public traffic moved to the new version.
✅Solution Using Pending migration
Operators added a pre-swap checklist that ran EF Core migration listing from the build agent and used Azure CLI to show slot settings, PostgreSQL server status, and resource tags. The migration used a managed pipeline identity and Key Vault references rather than inline passwords. After SQL review, the team applied the migration to production, checked the history table, warmed the staging slot, and only then completed the slot swap. Failed health probes triggered an automatic stop instead of forcing traffic forward.
📈Results & Business Impact
The schedule-change release completed with no rider-facing outage during the morning commute.
Wrong-database deployment risk was reduced because slot settings and server names were archived for every release.
Secret exposure findings disappeared after connection strings moved to Key Vault-backed references.
The team shortened post-release verification from 45 minutes to 18 minutes using repeatable checks.
💡Key Takeaway for Glossary Readers
A pending migration is a warning to verify both schema state and Azure deployment scope before a slot swap changes user traffic.
Case study 03
Donor portal migration bundle
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
HarborAid Foundation maintained a donor portal on Azure Container Apps with an Azure SQL backend. Volunteer developers frequently added EF Core migrations, and operations discovered pending migrations only after deployments failed.
🎯Business/Technical Objectives
Create a repeatable migration process that did not require the .NET SDK on production hosts.
Lower release failures caused by unapplied schema changes to fewer than one per quarter.
Document backup, approval, and target resource evidence for every database change.
Separate application image deployment from schema application when risk was high.
✅Solution Using Pending migration
The team adopted EF Core migration bundles built in CI and stored as release artifacts. Before execution, an Azure CLI evidence job showed the SQL database, container app revision, managed identity, and resource group. Reviewers approved the generated script and the bundle command separately from the image deployment. For larger changes, the team applied schema first, ran smoke tests through a temporary revision, and promoted the container app only after migration history matched the release manifest.
📈Results & Business Impact
Deployment failures from missing columns dropped from five in six months to zero in the next two release cycles.
Non-developer release managers could approve changes using migration ID, SQL summary, backup timestamp, and Azure resource evidence.
Emergency rollback work fell by 60 percent because bundles and prior container revisions were paired in runbooks.
The portal handled a fundraising campaign without schema-related support tickets.
💡Key Takeaway for Glossary Readers
Pending migrations are easier to control when the migration artifact, Azure target, and application revision are versioned together.
Why use Azure CLI for this?
Azure CLI does not list EF Core pending migrations directly, but it is still valuable because it proves the Azure side of the migration target. Operators can verify the subscription, app, slot, database, identity, firewall state, and backup posture before the dotnet ef command or migration bundle touches data.
CLI use cases
Show the Azure SQL database, tier, region, and status before running a generated migration script.
Inspect App Service slot settings and connection strings to confirm which database a deployment will target.
Check PostgreSQL server state, firewall rules, and maintenance windows before applying EF Core migrations.
Export resource IDs and tags for change records that tie a migration to the approved Azure workload.
Before you run CLI
Confirm tenant, subscription, resource group, app slot, database server, database name, and migration ID before collecting evidence.
Verify permissions for read-only resource inspection separately from database privileges used to apply schema changes.
Check backup recency, maintenance window, private network path, Key Vault references, and destructive SQL risk before production.
Use JSON output for audit capture and avoid printing database passwords, access tokens, or connection strings in shell history.
What output tells you
Database status, SKU, location, and server name confirm the migration target and help avoid wrong-environment deployment mistakes.
App settings and slot settings reveal whether code, staging slots, and production slots point at the intended database.
Firewall, private endpoint, and identity fields explain whether the pipeline can reach the database securely.
Tags, resource IDs, and timestamps give change records evidence for ownership, approval scope, and rollback investigation.
Mapped Azure CLI commands
Migration target evidence commands
adjacent
az sql db show --server <sql-server> --name <database> --resource-group <resource-group> --output json
az sql dbdiscoverDatabases
az webapp config connection-string list --name <app-name> --resource-group <resource-group> --slot <slot> --output json
az webapp config connection-stringdiscoverDatabases
az postgres flexible-server show --name <server-name> --resource-group <resource-group> --output json
az postgres flexible-serverdiscoverDatabases
az resource show --ids <database-resource-id> --output json
az resourcediscoverDatabases
Architecture context
In Azure architecture, a pending migration sits at the boundary between app deployment, database schema governance, and release orchestration. For EF Core-backed workloads on App Service, Functions, AKS, or Container Apps, the application artifact may contain migrations not yet applied to Azure SQL, PostgreSQL, MySQL, or another target database. Treat it as a deployment dependency, not a code detail. Pipelines should detect the pending state before slot swap, rollout, or scale-out, because multiple replicas applying the same schema change can create locks or partial failures. Architects usually separate build, migration execution, health validation, and traffic cutover, with secrets in Key Vault, identities scoped to the database, and rollback planned around backup or point-in-time restore.
Security
Security impact is indirect but important because pending migrations usually require privileged database access. The migration itself does not grant Azure permissions, but applying it may need database owner rights, elevated service principals, managed identities, secrets, or firewall openings. Risk appears when pipelines store connection strings in plain text, run migrations against the wrong database, or leave broad credentials active after deployment. Generated SQL can also create permissions, views, stored procedures, or columns holding sensitive data. Operators should verify identity scope, Key Vault references, private connectivity, audit logging, and separation between migration approval and application deployment. Review approvals, audit logs, and migration identity scope before every protected schema change.
Cost
Cost impact is usually indirect, but it can become expensive quickly. Failed migrations trigger incident time, rollback work, extra deployments, support tickets, and emergency DBA review. Large schema changes may increase DTU, vCore, storage, transaction log, backup, or replica load while indexes rebuild or data backfills run. Teams may temporarily scale Azure SQL, PostgreSQL, App Service, or worker processes to create a safer maintenance window. Poor migration hygiene also creates long-term cost through stale columns, duplicate tables, unnecessary indexes, and fragile release processes that slow every future feature delivery. Track these costs as release-quality debt, not unavoidable database spend and risk.
Reliability
Reliability impact is direct because unapplied migrations can break application startup, request handling, background jobs, or reporting queries. Applying migrations at the wrong time can be just as risky if changes lock tables, rebuild indexes, or collide with active traffic. Reliable teams script migrations, test them against production-like data, take backups, rehearse rollbacks, and separate schema changes from risky app changes when needed. In multi-region or blue-green deployments, every slot and replica must understand the same migration state. Monitoring should confirm both the database history table and application health after the migration completes. Include schema checks in readiness probes and post-deployment validation after every major release.
Performance
Performance impact is indirect until the migration is applied, then it can be very direct. Pending migrations may include index changes, column additions, foreign keys, seed data, or backfills that affect query plans and locking behavior. If they remain unapplied, new code may fall back to inefficient paths or fail repeatedly. If they run during busy periods, users may see high latency, blocked sessions, or connection pool exhaustion. Operators should examine generated SQL, estimate row counts, test duration, check database metrics, and watch P95 latency, deadlocks, CPU, I/O, and application errors during rollout. Record baselines so teams can distinguish schema delay from normal load.
Operations
Operators inspect pending migrations by comparing source-controlled EF Core migrations, generated SQL scripts, application logs, deployment pipeline output, and the target database migration history. Azure CLI helps confirm which App Service, slot, database server, resource group, subscription, and identity are involved before touching data. Day-to-day work includes checking connection strings, verifying backup status, documenting migration IDs, approving SQL, and capturing evidence after deployment. Runbooks should state who can apply migrations, how destructive changes are reviewed, when locks are acceptable, and which health checks prove the schema and application are aligned. Keep the latest expected migration ID visible in each release checklist and incident note.
Common mistakes
Running dotnet ef database update from a developer machine against production without reviewed SQL or a rollback plan.
Deploying application code first, then discovering the database is missing a required table or column.
Using a staging slot connection string that accidentally points to production during migration testing.
Treating a successful Azure deployment as proof that EF Core migrations were applied to the database.