测试各种场景的漫长的一天结束，我不必重新创建生产数据库...
我们从EF开始，在开发过程中没有足够明智地从自动迁移转向命名迁移。现在我正在尝试回放时钟，并创建一个与生产数据库对齐的初始迁移。
另一个皱纹 - 数据库是用EF5创建的，我们现在正在开发EF6。
在此先感谢您的帮助。
它应该是可能的：
我也强烈建议阅读 团队环境中的代码优先迁移。
如果你不喜欢bricelam答案的第7步。然后继续阅读。
因为从自动迁移升级到手动也可以自动化。而且你不需要像bricelam那样删除migrationhistory表。
在这种情况下，我假设您有一台开发机器和多台其他（开发）机器，其中已存在数据库。
在您的开发机器上，您将数据库移动到一个安全的位置（保持安全，以测试您的自动升级过程）。 （您可能希望确保您的代码与要升级的所有数据库处于完全相同的状态）。
删除项目中的任何迁移（您还没有任何迁移）
禁用迁移配置类中的自动迁移
添加迁移InitialCreate
将数据库的备份（副本！）放回原位
在启动应用程序（或升级应用程序）时，您可以执行以下操作：
using (var db = new YourDatabaseContext())
{
InitialCreate.SkipInitialCreate = db.Database.Exists();
}
在您的InitialCreate中添加如下内容：
public static bool SkipInitialCreate = false;
public override void Up()
{
// Skip initial create
if (SkipInitialCreate)
return;
这假定如果存在数据库，则其结构与您在开发机器上的结构相同。当然，这可能比对你来说更复杂。要获得更多控制，您可以检查配置的DbMigrator对象，并跳过多个迁移。 （如果你能在DbMigrator中查询模型的哈希值，那会很好...）
在步骤4中的代码之后添加如下内容：
var configuration = new YourDatabaseConfiguration();
var migrator = new DbMigrator(configuration);
migrator.Update();
在您的开发机器上启动您的应用程序以测试升级。您的历史记录表应具有自动迁移记录和初始创建记录。
如果一切顺利，您应该能够在db已经存在的机器上简单地部署和运行应用程序。
一个非常重要的方面（也许是bricelam说您需要删除历史记录表的原因）是，如果该表中的AutomaticMigration记录比您的一个手动迁移更新，那么您将遇到错误的时间。因为迁移者使用日期来整理它需要做的工作。
因此，如果有系统仍然自动升级到最新的自动升级模型，那么你有点腌渍。