This project has moved and is read-only. For the latest updates, please go here.

Compared to EF 4.2/4.3 Migrations

Jan 16, 2012 at 3:49 PM

Please would some kind person like to give advantages/disadvantages with this as compared to EF migrations.


Feb 15, 2012 at 5:08 PM


Great question. I'm still new to EF Code First Migrations, which were just released officially in EF 4.3. They appear to have some similarities in their focus.  Some of the key differences:

  • DBDeploy is for ANY database, not just code first databases.  With EF Migrations, you have to be doing code first.  Many DB people dislike the Code First pattern, since ER and object structures are often difference (for example, there's really no such thing as "Interitance" in a relational database).
  • EF Migrations is more targeted on developer support.  DBDeploy is more targeted on database versioning in general, not just supporting db changes made by developers.
  • DB Deploy gives you more control over EXACTLY what ends up in your change script.  EF Interprets what it thinks should go into the change script.
  • DB Deploy scripts can be maintained by a non-developer.  EF requires a dev to make changes to the source to get database changes.
  • EF Migrations is dependent upon the Nuget package manager, which requires running an Exec task in your build environment.  DBDeploy has native MSBuild tasks that make working in CI environments much easier.
  • Seeing what changes have been made to the data structure is easier with DBDeploy.  EF Migrations is more "magic", and corelating code changes to database changes can be difficult.

In short, if you have an environment where developers control the database completely and only use Code First, and your migrations to production are relatively simple (i.e. small projects), EF Migrations is probably the way to go.  However, as soon as you add a DBA to the mix or have larger teams that need to make changes to databases and coordinate those changes, DBDeploy is probably a better solution.