c# - Are there reasons to keep EF migration code around once all environments have been migrated to the latest version?

Question

I've inherited an ASP Net Core MVC project that uses Entity Framework. The project contains a number of database migrations, and it is only used internally in my company. All environments running the project have migrated the database to the latest version.

I am still learning Entity Framework, but from what I understand the way this project uses migrations is unorthodox: several of them include custom SQL scripts for data population that I think don't belong in a migration, they do not integrate well with the EF command-line tools, and the actual upgrade is done on ad-hoc basis by calling a migration method when starting the app.

Considering that all environments are running the latest database version, what reasons are there to keep these migrations around? To me it looks like dead code, effectively. If new migrations are needed in the future, then I can follow a more by-the-book approach.

Answer 1

In your company, how is the database schema established, if not via migrations?

Say I want to provision a new database, e.g. because we're going to run a second instance of this application - but with completely new and unrelated data. What would I need to do to bring this database structurally up to date?

There's several possibilities here, I'm curious as to which approach your company takes.

One way to do this is by using your migrations as the sole source. I.e. you start from an empty database, and anything you add (or later change) is considered a migration. Therefore, to create a new database from scratch, you simply make a new (empty) database and replay the migrations.

Therefore, you can't just throw away old migrations.

---

Secondly, does your company keep database backups? Do they still have backups that date from before the latest migration?

Suppose we restore an old backup, how would we get it back into working order when we've deleted the migration logic?

This too would be a good reason to keep migrations around.

---

Over all, your question suffer from the fairly common "things can only get better" attitude that every developer struggles with at some point. That is not always the case.

For example, you'd say that a codebase with bugfixes is better than the same codebase before those fixes. But that is not a reason to delete your source control history from before those fixes were committed.

First of all, it's a matter of record-keeping. Secondly, there's always the possibility that the changes that were made ended up introducing problems that were not immediately apparent.

In such a case, the ability to roll back may become necessary. Furthermore, if the ability to roll back becomes necessary, that in turn also argues that you need your migration logic, both for downwards migration (i.e. rolling back but while keeping the new data) and for the future upwards migration you're going to perform once the current issues have been sorted out.