Microsoft.Data.SqlClient.SqlException (0x80131904): There is already an object named 'Customers' in the database. on dotnet ef database update means EF Core is running a migration that creates a table the database already has. The migrations in your project no longer match the rows in the database's __EFMigrationsHistory table, so EF Core thinks the schema was never built.

Put the original migrations back (from source control, or from wherever the folder was moved) and run the update again; EF Core then sees that everything is applied. On a development database with nothing worth keeping, dropping it and running the update from scratch also works.

The error

Applying migration '20261009082817_Init2'.
Failed executing DbCommand (8ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
CREATE TABLE [Customers] (
    [Id] int NOT NULL IDENTITY,
    [Name] nvarchar(max) NOT NULL,
    CONSTRAINT [PK_Customers] PRIMARY KEY ([Id])
);
Microsoft.Data.SqlClient.SqlException (0x80131904): There is already an object named 'Customers' in the database.

A long stack trace follows, and the tool ends with Error Number:2714,State:6,Class:16, the SQL Server number for "object already exists".

Why it happens

Every applied migration leaves a row in __EFMigrationsHistory: its id and the EF Core version that applied it. On database update EF Core compares the migrations compiled into your project with those rows and runs only the ones it cannot find. Here the database had been built by a migration called Init; then the Migrations folder was moved out of the project and a fresh one, Init2, was scaffolded. Its id, 20261009082817_Init2, is not in the history table, so EF Core runs it from the top, and its first statement creates Customers again.

Deleting the Migrations folder to "start clean" does exactly what moving it did here: the project loses the migration the history table knows about, the next scaffold starts from nothing, and the update replays every CREATE TABLE. The database is fine; the project has forgotten its own past.

The fix

These are the commands that produced the error, run from the project folder:

dotnet ef migrations add Init
dotnet ef database update
Move-Item Migrations ..\Migrations-original
dotnet ef migrations add Init2
dotnet ef database update

And this is the fix that was run: set the new folder aside, restore the original, update.

Move-Item Migrations ..\Migrations-init2
Move-Item ..\Migrations-original Migrations
dotnet ef database update
No migrations were applied. The database is already up to date.
Done.

A query on the history table afterwards showed one row, 20261009082810_Init, matching the one migration in the project. If the original migrations are truly gone and the database is a throwaway, dotnet ef database drop -f followed by dotnet ef database update rebuilds it from the new migration, at the cost of its data. Never do that against a shared or production database.

How it was reproduced

A console project on .NET SDK 10.0.401 with Microsoft.EntityFrameworkCore.SqlServer 10.0.12 and Microsoft.EntityFrameworkCore.Design 10.0.12, the dotnet-ef global tool 10.0.0, and SQL Server 2022 LocalDB on Windows 11. Init, Init2 and the Migrations-original folder name are the test's own; the commands ran from a PowerShell script in the project folder.

Frequently asked

Why does dotnet ef database update say there is already an object named in the database?
EF Core is running a migration whose id is missing from the __EFMigrationsHistory table, so it creates tables that already exist. The usual cause is a Migrations folder that was deleted, moved or regenerated after the database was built.
What is the __EFMigrationsHistory table?
It is the table EF Core uses to record which migrations have been applied to a database: one row per migration with its id and the EF Core version. database update runs only the migrations it cannot find there.
Can I just delete the Migrations folder and create a new initial migration?
Only if you also drop the database or it is new. Against an existing database the new initial migration is not in the history table, so update tries to create every table again and fails with error 2714.

More decoded errors in the Fixes category.