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