迁移需分四步：明确范围与数据校验（分层比对+md5哈希）、灰度上线与回滚预案（按维度→事实→报表顺序，每批保留源系统读能力72小时）、权限调度血缘同步（rbac重映射、调度重写、血缘自动采集）、报表兼容适配与用户沟通（sql方言替换、提前发布影响清单）。
明确迁移范围与数据一致性校验机制
迁移前必须清晰界定哪些表、视图、存储过程、ETL作业和报表依赖项需要迁移，避免遗漏关键对象导致报表断链。重点识别源系统中存在业务逻辑计算（如动态分区、行级安全过滤、自定义函数）的字段，这些在目标数仓中需重新实现或适配。数据一致性不能只靠“行数比对”，应设计分层校验：基础层核对主键唯一性与空值率，汇总层验证指标口径（如GMV是否含退款）、时间分区切片逻辑是否一致，报表层抽样比对TOP N明细与聚合结果。建议用SQL脚本自动比对关键字段的MD5哈希值或统计分布（均值、标准差），而非人工肉眼检查。
分阶段灰度迁移与回滚预案必须落地
禁止一次性全量切换。推荐按“维度表→事实表→报表模型→前端报表”顺序分批上线，每批次上线后保留源系统读能力至少72小时。每个批次需配套可执行的回滚SQL：例如维度表迁移失败时，能快速切回原视图别名；事实表迁移异常时，可通过临时物化视图还原上一周期快照。回滚脚本须提前在测试环境演练，确保5分钟内可完成核心报表服务恢复。同时监控迁移窗口期的查询性能抖动，防止新数仓因分区策略或统计信息缺失引发慢查拖垮BI服务。
权限、调度与血缘关系同步重构
目标数仓的RBAC权限模型往往与源系统不同（如从数据库用户级变为数据产品级角色），需映射并重置报表用户访问权限，避免迁移后出现“查不到数据”或“越权可见”。原有ETL调度任务（如Airflow DAG、Cron Job）要重写适配新引擎语法与连接方式，尤其注意时区、并发控制、失败重试策略差异。更重要的是重建端到端血缘：从原始日志表→清洗层表→聚合模型→报表指标，用工具（如OpenLineage、Atlan）或SQL解析自动采集，否则后续问题排查将陷入黑盒。未同步血缘的迁移等于埋下长期运维隐患。
报表兼容性适配与用户沟通节奏
旧报表常硬编码数据库名、Schema名、字段别名甚至MySQL特有函数（如DATE_FORMAT），迁移至Doris/StarRocks/BigQuery等引擎时会报错。需批量扫描报表SQL，替换方言、调整NULL处理逻辑、统一时间函数（改用TO_DATE或FORMAT_TIMESTAMP）。更关键的是主动管理用户预期：提前发布迁移时间表、影响范围清单、临时不可用时段，并提供新旧报表并行对照文档。避免让业务方在上线当天才发现“销售额少了一半”——大概率是时区转换或去重逻辑未对齐，而非数据丢失。
