滚动发布期间，新旧程序可能同时访问数据库。新版本直接删除旧字段，可能让尚未退出的旧实例报错。数据库结构变更需要考虑多个版本共存，而不只是新版本单独运行。
先增加兼容能力
可评估先增加字段、表或兼容接口，让旧版本继续工作，再迁移读写逻辑。新增字段的默认值、历史数据填充和约束生效顺序也要设计，不能只看建表语句是否执行成功。
数据回填需要运行计划
大表回填可能产生锁、日志和复制压力。根据实际规模安排批次、观察指标和停止条件，并记录进度。回填脚本应能识别已处理范围，避免失败后只能从头开始。
清理旧结构需要证据
确认所有受支持程序、报表和后台任务都不再依赖旧字段，再执行收缩。不要只因为主应用已经更新就删除旧结构，低频任务往往更容易被遗漏。
验收新旧版本与历史数据
同时运行需要兼容的版本，覆盖新增、修改和查询，并检查回填后的关键字段。回滚说明应明确哪些阶段仍能直接切回旧程序，哪些需要数据补偿。
常见问题：EF Core 自动生成迁移就能直接上生产吗？
生成脚本仍需审查、验证权限与数据影响，并按部署流程执行，工具不能替代生产变更评估。
技术参考：微软：应用 EF Core 数据库迁移。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的 .NET 应用还缺少可重复的部署、观察或恢复流程，可以通过容器化与自动化交付服务梳理现状，约定实施内容、演练场景与运维交接方式。