Developer Tools .NET data access premium

EF Core migration

EF Core migration is a versioned Entity Framework Core schema change that records model differences and can generate SQL for controlled database deployment. In practical Azure work, it helps teams move application database schemas forward safely, review SQL before production, coordinate developers and DBAs, and avoid hidden drift between code and database. Plainly, it is the shared label operators use when they need to find the setting, resource, identity, or workflow that controls that behavior. A useful entry connects EF Core migration to owners, dependencies, telemetry, change control, graph relationships, and the CLI or portal evidence that proves current state.

Back to glossary browser Open Microsoft Learn source
Aliases
Entity Framework Core migration, EF migration
Difficulty
intermediate
CLI mappings
4
Last verified
2026-05-14

Microsoft Learn

An EF Core migration records database schema changes from an Entity Framework Core model so teams can generate, review, and apply controlled schema updates.

Microsoft Learn: Applying migrations - EF Core2026-05-14

Technical context

Technically, EF Core migration appears in EF Core migration files, DbContext models, generated SQL scripts, CI/CD pipelines, Azure SQL databases, and deployment release gates and interacts with Azure SQL Database, App Service, and Azure DevOps pipelines. Configuration is reviewed through migration file, DbContext, and idempotent script, while operators validate live state through migration list, generated SQL, and database schema version. Scope determines which permissions, logs, commands, network paths, and dependencies matter. Document the exact production boundary before changing behavior.

Why it matters

EF Core migration matters because a small Azure design choice can shape customer experience, security posture, operational visibility, and incident recovery. When it is shallowly documented, teams may troubleshoot the wrong database compatibility level, manual SQL hotfix, deployment script, pending migration, and application configuration while the real dependency remains hidden. In enterprise Azure work, the value is shared language: application, platform, security, data, finance, and operations teams can discuss the same object without guessing. That reduces incident time, improves audit quality, clarifies ownership, and makes production changes safer because failure modes and graph relationships are visible before change. Treat EF Core migration as production owned when customer traffic, regulated data, privileged access, automation, or release governance depends on it.

Where you see it

Signals, screens, and Azure surfaces where this term usually becomes operational.

Signal 01

In source control, an EF Core migration appears as generated C# migration files that describe model and schema changes during production review when operators need repeatable evidence.

Signal 02

In release pipelines, an EF Core migration appears as reviewed SQL scripts applied to Azure SQL during approved deployment windows during production review when operators need repeatable evidence.

Signal 03

In incidents, an EF Core migration appears when code expects a schema change that was not applied or was applied incorrectly during production review when operators need repeatable evidence.

When this becomes relevant

Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.

  • Generate reviewed SQL scripts from EF Core model changes.
  • Coordinate application releases with Azure SQL schema updates.
  • Diagnose mismatches between deployed code and database schema.

Real-world case studies

Different enterprise-style examples that show the term being used to hit measurable objectives.

Case study 01

EF Core migration in action for retail manufacturing

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Coho Winery, a retail manufacturing organization, needed to address an inventory app release failing because schema changes were applied manually and inconsistently. The architecture team used EF Core migration as the Azure control point for a measurable production improvement.

Business/Technical Objectives
  • Deploy schema changes with controlled review
  • Reduce failed application releases caused by database drift
  • Preserve rollback evidence for production changes
  • Give developers and DBAs a shared migration process
Solution Using EF Core migration

The development team moved schema changes into EF Core migrations and generated idempotent SQL scripts for DBA review. The Azure release pipeline checked the target SQL database, captured metrics, and applied approved scripts during a maintenance window. Deployment slots were used so app startup could validate the migrated schema before production traffic moved. The team validated EF Core migration in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer.

Results & Business Impact
  • Failed inventory releases dropped from five per quarter to one
  • DBA review time decreased by thirty percent
  • Application rollback plans included the exact migration script
  • Schema drift findings became visible before deployment
Key Takeaway for Glossary Readers

EF Core migrations work best when generated scripts are reviewed like production infrastructure changes.

Case study 02

EF Core migration in action for travel services

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Margies Travel, a travel services organization, needed to address booking features needing weekly schema updates without surprising database administrators. The architecture team used EF Core migration as the Azure control point for a measurable production improvement.

Business/Technical Objectives
  • Deploy schema changes with controlled review
  • Reduce failed application releases caused by database drift
  • Preserve rollback evidence for production changes
  • Give developers and DBAs a shared migration process
Solution Using EF Core migration

The application team standardized migration naming, checked migration files into source control, and generated idempotent SQL for every booking release. DBAs reviewed index and table changes before approval. Azure SQL metrics were checked for headroom, and migration results were stored with the deployment record. The team validated EF Core migration in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, making the change understandable to security, operations, finance, and application stakeholders.

Results & Business Impact
  • Weekly releases continued without emergency schema fixes
  • Long-running changes were moved to quieter windows
  • Database and application teams used the same migration history
  • Production incidents tied to missing columns dropped to zero
Key Takeaway for Glossary Readers

An EF Core migration creates a shared contract between code changes and database operations.

Case study 03

EF Core migration in action for life sciences research

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Wide World Labs, a life sciences research organization, needed to address research portal databases drifting because developers patched tables directly in test and production. The architecture team used EF Core migration as the Azure control point for a measurable production improvement.

Business/Technical Objectives
  • Deploy schema changes with controlled review
  • Reduce failed application releases caused by database drift
  • Preserve rollback evidence for production changes
  • Give developers and DBAs a shared migration process
Solution Using EF Core migration

The platform owner required EF Core migrations for all model changes and blocked direct table hotfixes except through break-glass approval. Migration scripts were reviewed for sensitive data, index impact, and transaction behavior. Azure SQL diagnostics and deployment logs were linked to each release so researchers could trace schema changes. The team validated EF Core migration in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer.

Results & Business Impact
  • Unapproved schema drift decreased by eighty-one percent
  • Research portal release approvals became auditable
  • Rollback planning improved for high-risk table changes
  • Developers stopped depending on undocumented test database edits
Key Takeaway for Glossary Readers

EF Core migration discipline prevents code-first teams from losing control of production schemas.

Why use Azure CLI for this?

CLI checks for EF Core migration are useful because they turn portal assumptions into repeatable evidence. Start with read-only commands that show scope, service objective, queue settings, function deployment, authentication state, database target, role schedule, metrics, or operational history. Run mutating, security-impacting, or cost-impacting commands only after approval, because the wrong scope can affect production availability, spend, access, workflows, or database schema.

CLI use cases

  • Generate reviewed SQL scripts from EF Core model changes.
  • Coordinate application releases with Azure SQL schema updates.
  • Diagnose mismatches between deployed code and database schema.

Before you run CLI

  • Run az account show, confirm tenant and subscription, and verify the signed-in operator has approved read access for the exact Azure scope.
  • Confirm resource group, service name, identity, region, owner, environment, and change record before collecting evidence or changing production configuration.
  • Prefer read-only commands first; review any command that changes scale, access, runtime settings, database schema, message behavior, or role eligibility before running it.

What output tells you

  • Whether the target database, pool, queue, topic, function app, web app, role schedule, or application resource exists at the expected Azure scope.
  • Which SKU, service objective, endpoint, identity, configuration version, message setting, orchestration host, or role assignment is visible to the operator.
  • Whether the issue is wrong scope, stale configuration, missing access, exhausted capacity, failed schema migration, duplicate message handling, or unsafe privilege design.

Mapped Azure CLI commands

EF Core migration operational checks

direct
dotnet ef migrations list --project <project-path> --startup-project <startup-project-path>
read-only Microsoft docs
dotnet ef migrations script --idempotent --output migration.sql --project <project-path> --startup-project <startup-project-path>
read-only-planning Microsoft docs
az sql db show --name <database> --server <sql-server> --resource-group <resource-group>
az sql dbdiscoverDatabases
read-only Microsoft docs
az monitor metrics list --resource <database-resource-id> --metric cpu_percent,dtu_consumption_percent,log_write_percent --interval PT1H
az monitor metricsdiscoverDeveloper Tools
read-only Microsoft docs

Architecture context

EF Core migration belongs to Developer Tools architecture decisions where identity, monitoring, cost ownership, reliability, and production support need shared evidence.

Security

Security for EF Core migration starts with least privilege, trusted configuration, and evidence that access matches workload risk. Review connection secret handling, managed identity access, SQL permissions, migration review, least-privilege deployment, and audit trail before approving production use. A common failure is assuming that a working feature, successful deployment, visible resource, or populated dashboard proves the configuration is safe. Use Microsoft Entra groups, managed identities, RBAC, private connectivity, diagnostic logging, source-controlled definitions, and approval records where applicable. Keep exceptions ticketed, time-bounded, and owned. For regulated workloads, align the term with classification, retention, break-glass, and incident-response procedures. Remove broad access, stale secrets, unreviewed contributors, public exposure, and undocumented exception paths before EF Core migration becomes an incident path.

Cost

Cost for EF Core migration appears through developer rework, release delays, database downtime, log growth, support escalation, and failed deployment windows, and the human effort required to recover from mistakes. Some costs are direct, such as provisioned capacity, paid tiers, message operations, function execution, storage, logs, or database compute. Others are indirect, such as failed releases, emergency scaling, duplicated troubleshooting, excess review queues, and support escalation. Tag related resources, monitor usage, and separate exploratory work from production. A cost review should connect spend to a real owner, service objective, and measurable business value. When spend changes, inspect EF Core migration dependencies before blaming only the service SKU or adding capacity.

Reliability

Reliability for EF Core migration depends on repeatable configuration, tested dependencies, and clear failure signals. Watch idempotent scripts, rollback plan, transaction behavior, locked tables, preproduction testing, and backup restore point because drift often appears later as failed releases, broken workflows, low throughput, throttling, duplicate processing, lost recovery evidence, or missing audit data. Use lower environments, source-controlled definitions where possible, deployment validation, monitoring, and recovery notes before changing production. Operators should know which endpoint, database, queue, function, web app, role, or downstream application fails first and which metric or log proves the failure. The goal is predictable recovery: detect EF Core migration drift, preserve service, restore safely, and explain the incident without guessing.

Performance

Performance for EF Core migration depends on index changes, table locks, long-running DDL, transaction log usage, database headroom, and application startup time, and the monitoring path used to confirm success. Review workload shape, concurrency, retry behavior, network path, service limits, database waits, runtime settings, and identity checks before increasing capacity or retrying blindly. The better fix might be correcting configuration, reducing log noise, tuning query or message design, changing scale boundaries, or repairing drift in source-controlled infrastructure. Measure under representative production conditions. Operators should connect symptoms to evidence: latency, throttling, backlog, failed operations, stale state, or high utilization. Good performance work ties EF Core migration measurements to user impact and avoids hiding design issues behind larger resources.

Operations

Operations for EF Core migration should focus on ownership, observability, and safe repeatability. Standardize names, tags, owner groups, environment labels, diagnostic destinations, runbook links, approval records, and change windows so support teams do not reverse-engineer the platform during incidents. Use read-only CLI, API, diagnostic, or portal checks first, then compare live state with intended configuration. For production, connect alerts, audit events, cost records, graph links, and release notes to the same term. The support question should be simple: who owns it, what changed, and what proves the current state?. Capture owner, scope, evidence, and recovery procedure before changing EF Core migration in a production environment.

Common mistakes

  • Changing production before checking the exact Azure scope, owner, dependency, identity, approval record, and rollback or recovery procedure.
  • Treating a portal screenshot as sufficient evidence when CLI output, Activity Logs, metrics, and source-controlled configuration are repeatable.
  • Assuming a name match proves the correct resource when subscriptions, SQL servers, function apps, web apps, queues, topics, and roles can look similar.