云与 AI 架构的可迁移性，不能用“是否支持多云”简单证明。真正需要验证的是：当供应商、区域、芯片架构、模型服务或托管团队受到限制时，企业能否在可接受的时间和成本内恢复核心业务，并同时满足安全、审计和数据合规要求。可迁移性本质上是一种可测试的架构能力，而不是采购标签。
先画出依赖链，再定义替换边界
评估应从业务关键度出发，绘制从数据、模型、算力到运行平台的完整依赖图。云服务至少要区分基础设施层、平台服务层、智能服务层以及管理与安全层。托管数据库、消息队列、身份系统、密钥、日志和监控等服务，即使不直接承载业务逻辑，也可能成为迁移时的控制面锁定点。
AI 架构还应单独记录模型权重、微调数据、提示词模板、评测集、向量数据、推理参数和工具调用协议。能够调用第二家模型服务，并不意味着真正可迁移；模型输出差异、嵌入模型不兼容、算力架构变化和专有编排接口，都可能迫使应用重构。
企业不必让所有系统完全跨云，而应优先为高价值、高风险能力设置替换边界，例如核心客户数据、AI 推理入口、模型与向量数据、身份与密钥系统，以及业务规则和工作流。在这些边界上采用可导出的数据格式、独立配置管理和尽量稳定的接口，通常比复制两套完整生产环境更有效。
用迁移演练替代供应商承诺
验证不能停留在问卷或合同条款。至少应设计三类演练：数据导出演练，检查数据、元数据、权限和日志能否完整带走；应用切换演练，在备用云或备用区域恢复核心服务；AI 替代演练，在第二种模型或算力环境中运行同一组评测任务，并比较准确率、延迟、吞吐量、资源占用、调用成本和故障恢复情况。
每次演练都应记录实际耗时、人工操作、失败环节、性能变化和未解决依赖。对于开源组件、模型权重、容器镜像及其传递依赖，还要核验许可证、来源、维护状态和安全更新路径。
最终评分应综合业务关键度、替换难度、迁移耗时、替代资源不确定性和演练结果。只有能够导出、能够恢复、能够在替代环境中运行，并且证据可审计的架构，才真正拥有云与 AI 的迁移选择权。