如果使用数据库作为事实来源，升级主要涉及解决对生成的实体形状所做的任何更改。 迁移的步骤包括：
- 选取一个时间点来为数据库建模。
- 确保 EF6 项目是最新的，并与数据库同步。
- 创建 EF Core 项目。
- 使用 基架工具 将数据库逆向工程为代码。
- 验证 EF Core 生成的类是否与代码兼容。
- 对于异常，请修改生成的类并更新 模型配置 或将代码适应模型。
请注意，尽管 EF Core 目前为成功生成数据库副本所需的所有内容搭建基架，但数据库优先方法不需要大部分代码。 问题 #10890 中跟踪此问题的修复程序。 可以安全忽略为不需要的事项包括：序列、约束名称、非唯一索引和索引筛选器。
处理架构更改
当数据库是事实来源时，EF Core 会从数据库中拉取架构信息，而不是通过迁移推送架构信息。 典型的工作流是在数据库架构发生更改时重新运行反向工程步骤。 全面的测试套件对于此方法非常有用，因为你可以自动执行基架过程，并通过运行测试来验证更改。
处理模型差异的提示
出于各种原因，你可能希望 C# 域模型与反向工程中生成的模型形成不同的形状。 在许多情况下，这意味着手动更新每次架构更改后自动生成的代码。 在重新生成代码时，为避免多余的工作，可以对 DbContext 和相关实体使用分部类。 然后，可以将与业务逻辑和不在数据库中跟踪的属性相关的代码保存在一组不会被覆盖的单独类文件中。
如果模型与生成的模型明显不同，但不会频繁更改，请考虑的一个选项是将 存储库模式 用作适配器。 存储库可以消费 EF Core 生成的类，并发布自定义类。 这可以通过将它们隔离到存储库代码来减少更改的影响，而无需每次架构更改时执行应用程序范围的重构。
可能需要考虑备用工作流，并遵循类似于 混合方法的步骤。 无需每次生成一组新的类，而是指示特定表仅生成新类。 将现有类保留为“原样”，并直接添加或删除已更改的属性。 然后更新模型配置，以应对数据库映射到现有类方式的任何更改。
自定义代码生成
EF Core 6 目前不支持自定义生成的代码。 有第三方解决方案（如 EF Core Power Tools ）可用。 有关精选社区工具和扩展的列表，请参阅： EF Core 工具和扩展。
最后，查看 EF6 与 EF Core 之间的差异的详细列表 ，以解决移植时出现的任何剩余问题。
