国产化迁移服务：做什么，不做什么
国产化迁移服务，是指由平台原厂团队主导，把企业已有的数据分析资产（工作流、脚本、模型、调度任务）迁移到自主可控平台上继续运行的一整套实施服务。它与「换一套软件」的区别在于：交付的不是安装包，而是一份可验收的迁移结果 – 每个流程在新平台上跑出的数字，要和原系统对得上。服务贯通实施咨询、部署交付与培训赋能三个环节，迁移完成后由运维支持团队承接。
| 覆盖工具 | Alteryx、SAS、KNIME、SPSS（含 Modeler 流与语法）、Minitab、Power Query、Tableau Prep |
|---|---|
| 服务方式 | 原厂团队实施，支持远程与驻场两种模式 |
| 评估周期 | 迁移评估 3-5 个工作日出具报告；实施周期随资产规模与工具类型确定 |
| 切换方式 | 并行运行，新旧结果比对一致后切换，切换前全程可回退 |
| 阶段交付物 | 资产盘点表、对照清单、改造件、比对记录、培训与运维材料 |
| 目标运行环境 | 麒麟 V10 / V11、统信 UOS 的 x86-64 版本；海光 C86 已完成部署验证 |
| 暂不承接 | ARM64 环境（鲲鹏、飞腾）的迁移实施，该架构支持在规划中 |
| 后续衔接 | 迁移完成即转入培训赋能与运维支持，由同一团队贯通 |
※ 表中所列运行环境均为已完成测试并有实际交付的组合。未列出的环境请在评估阶段提出，我们单独确认，不在未验证的组合上做承诺。
七类工具，迁移的难点完全不同
很多迁移方案把「支持多种工具」当成一句口号。实际做下来，工作量能差好几倍，而分界线不在工具的知名度，在于原工具和 iModel 是不是同一种范式。同为可视化工作流的，做的是按对照表重建；代码型和统计型工具，做的是跨范式改造。这两类的排期必须分开估，混在一起报总工时是排期失控最常见的原因。
第一类：同为可视化工作流 – 按对照表重建
这一类不需要改写代码，也不需要业务人员重新建立心智模型。工作量集中在工具与节点的逐个映射，以及迁移后的结果对账。
KNIME 迁移
同源，最轻iModel 与 KNIME 同源内核，.knwf 工作流文件可直接打开，业务逻辑不动。工作量集中在环境适配与结果比对，而不是重写。需要单独处理的只有商业版专有节点，评估阶段就能全部列清。
查看 KNIME 替代方案 →Alteryx 迁移
同范式，较轻.yxmd 文件不能直接导入，需按工具对照表逐个重建。但范式一致，有 Alteryx 经验的人 1 至 3 天可上手。真正的卡点在 Join 三出口、Multi-Row Formula 的跨行引用，以及 .yxdb 中间数据的提前导出。
查看 Alteryx 替代方案 →Power Query 迁移
范围集中Excel 与 Power BI 里的查询步骤逐步对应到节点，处理逻辑本身不复杂。难点通常不在迁移，而在盘点 – 查询往往散落在几十个人的本地文件里，先找齐比改造更花时间。
查看 Power Query 替代方案 →Tableau Prep 迁移
同范式，较轻同为流程式数据准备工具，清洗、合并、聚合步骤可逐步对照。需要单独确认的是下游 – 原本输出给 Tableau 的数据，切换后走什么路径，这部分要和 BI 侧一起定。
查看 Tableau Prep 替代方案 →第二类：代码与统计工具 – 跨范式改造
这一类的逻辑藏在脚本里，需要人工读懂后重建，工作量与不确定性都明显更高，但改造完成后的收益也更大：流程从此可视、可复用、可交接。
SAS 迁移
跨范式，最重从脚本语言迁到可视化工作流，是全部类型中工作量最大的。宏、PROC 步、DATA 步需要逐段映射为节点组合，业务逻辑要人工确认。好处是改造完成后不再依赖个别写脚本的人。
查看 SAS 替代方案 →SPSS 迁移
分两种来源要先分清资产是 Modeler 流还是语法脚本。Modeler 流按节点对照迁移，路径接近第一类；语法脚本则接近 SAS 的改造方式，需要逐段重写。两类混在一起报总工时，一定会低估。
查看 SPSS 替代方案 →Minitab 迁移
范围集中，最快以统计方法与图表的对照为主，数据量通常不大、逻辑集中，一般最快完成。重点不在迁移本身，而在迁完之后把原本手工重复的质量分析做成可调度的工作流。
查看 Minitab 替代方案 →其他工具与自研脚本
须单独评估Excel 手工流程、自研 Python 脚本、老旧 ETL 工具的资产，不套用上面的口径，需要在评估阶段逐项判断。我们的处理方式是先看能不能迁，再谈迁多久 – 不做笼统承诺。
Excel 手工流程的处理方式 →国产化迁移服务：五步实施路径
整套方法论的核心是第四步。并行运行期新旧系统同时跑同一批数据，逐项比对输出，对得上才切换 – 这是把迁移风险降到可控的唯一办法，也是验收的依据。
迁移评估
盘点资产规模、所用功能与数据源，判断可行性与优先级
能力对照
逐项映射功能、节点与脚本，标出需改造和需替代的部分
对照改造
按对照清单完成流程与脚本转换，形成可运行的迁移件
并行验证
新旧系统同跑同一批数据，逐项比对结果并留存记录
培训交接
交付材料、培训团队，正式切换并转入运维支持
工期与投入怎么估
「先评估再报周期」是对的，但立项的人在拿到评估报告之前就需要一个量级判断。下面这组口径来自同类项目的交付经验，可以直接用于内部立项的初步测算，实际工期以评估报告为准。
| 阶段 | 估算口径 | 说明 |
|---|---|---|
| 迁移评估 | 3-5 个工作日 | 清点资产数量、所用功能、数据源与调度依赖，产出可迁移比例判断 |
| 可视化工作流改造 | 20 个流程以内，约 1-2 周 | 指 KNIME、Alteryx、Power Query、Tableau Prep 且仅用常用工具的流程 |
| 代码型资产改造 | 按脚本段落另计 | SAS 宏、PROC 步与 SPSS 语法需逐段重建，复杂逻辑每处约 0.5-1 个工作日 |
| 专有节点替代 | 按清单逐项确认 | 商业版专有节点无通用等效方案，数量在评估阶段就能定，不会中途冒出来 |
| 并行验证 | 与改造工作量大致相当 | 同数据双跑、逐字段对账。这一步占比高但不能压缩，它就是验收依据 |
| 环境部署 | 单机约半天，服务器按环境另计 | 麒麟与统信的 x86-64 版本为双击安装，已有完整部署手册 |
| 培训交接 | 2-3 天 | 范式相同的（Alteryx、KNIME 等）更短，跨范式的需覆盖工作流搭建基础 |
※ 以上为区间口径，不构成报价。我们不提供未经评估的固定报价，也不承诺未验证过的迁移比例。影响工时最大的三个变量依次是：资产类型（跨范式 vs 同范式）、流程数量、依赖专有节点的比例。
建议先立试迁移，而不是一次性全量
最省成本的路径是：选 3 至 5 个有代表性、又不在关键路径上的流程，走完完整五步，拿到实测工时再决定全量排期。这批流程的对账经验可以复用到后续批次，同时也验证了团队接不接得住。原系统的许可保留到最后一批验证通过为止 – 迁移期间任何一步出问题都有退路，这是并行策略的意义。
国产化迁移服务：每一步交付什么
服务能不能验收，取决于交付物是否具体。下表是各阶段应当拿到的东西，可直接用于合同附件与验收单。
| 阶段 | 交付物 | 用途 |
|---|---|---|
| 迁移评估 | 资产盘点表、可行性评估报告 | 确定迁移范围、排期与投入，作为立项依据 |
| 能力对照 | 功能 / 节点 / 脚本对照清单 | 明确哪些直接迁、哪些需改造、哪些用等效方案替代 |
| 对照改造 | 改造后的工作流与脚本 | 在目标环境中可运行的迁移件 |
| 并行验证 | 新旧结果比对记录 | 切换决策与项目验收的直接依据 |
| 培训交接 | 培训材料、运维手册 | 团队自主接管，减少长期外部依赖 |
各工具的具体对照方法另见对应的替代方案页；SAS 侧的改造思路可参考迁移指南文章，Alteryx 侧的完整工具对照表见Alteryx 国产化替代。
把边界写清楚，比把承诺写满更有用。下面右侧这几项不在标准迁移服务范围内，如有需要按单独项目评估。
什么情况下我们建议你先别启动
下面三种情况，项目做到一半才发现走不通的成本，远高于一开始就说清楚。把它们写在这里，是因为我们希望评估阶段就把这些拦下来。
目标服务器已确定为 ARM64（鲲鹏、飞腾）
iModel 目前不支持 ARM64 架构，相关版本仍在规划中，这类环境的迁移实施我们暂不承接。如果信创选型已经锁定鲲鹏或飞腾，请在评估阶段就提出来，不要等到实施环节 – 前面的改造工作会白做。可行的替代路径是先把范围限定在 x86-64 的海光平台上。
资产还没盘清，或者根本没人知道有多少
「大概几十个流程吧」是最危险的起点。Power Query 查询散在个人电脑里、SAS 脚本堆在共享目录里、没人说得清哪些还在跑 – 这种情况下先做的不是迁移，是盘点。可以只买评估这一段，拿到资产盘点表之后再决定要不要往下走。
现有许可还剩很长，也没有监管时限
如果合同还有两年以上、也没有明确的替代时间点，那么把存量整体搬迁未必划算。更省的做法是新增需求用 iModel 做，存量继续跑在原系统上，等许可到期时自然完成切换 – 迁移成本摊进日常工作，而不是变成一个需要单独立项的项目。
