做数据库迁移别再拍脑袋了：这份数据迁移工具生成的报告救了我一命

干了这么多年的数据库迁移，我最大的感悟就一句话：迁移这事儿，评估阶段没做扎实，后面全是坑。 这篇文章就聊聊我是怎么被金仓的KDMS这个数据迁移工具给“救”回来的，特别是它那个自动生成的量化评估报告，真的把我从拍脑袋估工作量的日子里捞出来了。

前言：为什么说评估是迁移项目的“生死线”

先交代下背景。我在一家做行业软件的公司干DBA兼架构，手里维护着不少老系统。这两年信创替代的活儿一个接一个，基本每个季度都有项目要做数据库替换。

其实做技术的人都明白，数据库迁移这个事情，真正写SQL搬数据的那部分反而不是最难的。最难的在哪儿？在你根本不知道这次迁移到底有多难。

这话听着有点绕，我给你解释下。一个跑了十年的老系统，几百上千张表，几百个存储过程，几十万行业务代码。你接手这么个项目，领导第一个问题肯定是：“多久能迁完？有多少东西要改？风险大不大？”

以前我是怎么回答的？说实话，靠感觉。

拉个Excel，把表结构过一遍，存储过程挑几个看看，然后拍个脑袋：“大概70%兼容吧，改造工作量估个一两个月，风险可控。”

结果呢？项目做着做着就发现，那个“大概70%”里面藏了不知道多少地雷。有个项目的存储过程里嵌了个不知道谁写的动态SQL，迁移过去直接报错，光排查这个问题就花了一周。还有个项目，字段类型映射的问题，数据搬过去全是乱码，返工了两次。

所以后来我特别怕开项目启动会。因为评估阶段给不出准数，后面所有的排期、预算、人力分配，全是建立在沙子上的。

一、那次让我彻底服气的翻车经历

讲个具体的事儿，这事儿我印象特别深。

前年接了一个政务系统的国产化替代项目。源库是跑了快十年的一个老库，业务逻辑复杂得很。当时评估阶段，我按老习惯，花了三天时间人工过代码。

• 表结构：手工建了个映射表，看了看字段类型，觉得问题不大
• 存储过程：挑了十几个核心的看了一眼，觉得写得还算规范
• 视图和函数：扫了一眼数量，觉得不多

然后我给领导汇报：“预计改造工作量3周，风险点主要在几个自定义函数上。”

领导批了。项目启动了。

然后我就开始还债了。

第一周，发现有个核心存储过程用了源库特有的一个语法特性，整个逻辑要重写。这个存储过程1200多行，嵌套了七八层循环。光是读懂原逻辑就花了三天。

第二周，发现一堆视图里面引用了源库特有的系统函数。数量不是我评估的十几个，是六十多个。每个都要找替代写法，还要逐个验证结果对不对。

第三周，测试的时候发现批量插入的性能直接崩了。查了半天，是源库和目标库对某个隔离级别的默认行为不一样。

一个月过去了，我的“3周改造工作量”完成了不到一半。领导天天在项目群里@我，我天天在会议室里解释为什么延期。

最难受的是什么？是我根本说不出“还差多少”。 因为没有数据。我不知道总共还有多少个类似的坑，不知道后面还会不会冒出新问题。整个项目就像是在雾里开车，你不知道前面是直路还是悬崖。

那次项目最后延期了一个多月才上线，验收的时候甲方脸色很难看。事后复盘，我们团队总结出来的第一条教训就是：

评估不能靠经验估，得靠数据算。

二、认识KDMS：评估这事儿真能自动化

翻车之后我就开始琢磨，有没有什么工具能把评估这个环节做扎实点。

后来因为公司战略，我们跟电科金仓合作比较多，就接触到了他们的KDMS。这玩意儿叫Kingbase Database Migration Service，是金仓数据库配套的迁移评估工具。

我一开始对这类工具是有点将信将疑的。因为市面上的迁移工具我见过不少，号称“一键评估”的也不少，但很多其实就是个语法转换器，你给它一段SQL它告诉你能不能转，这跟我人工看也没差多少，只是换个地方看而已。

但KDMS这个工具的思路不太一样。它不是让你一条条SQL去试，而是整个把源库的对象采集上来，然后批量做分析，最后生成一份完整的评估报告。

也就是说，它评估的对象不是“你给它看的那些代码”，而是“源库里实际存在的所有东西”。这个差别很关键。

我第一次跑KDMS评估的时候，是抱着“试试看”的心态。结果报告出来那天，我盯着屏幕看了得有十分钟。

为啥？因为报告第一页就是我上次翻车那个项目最想要的东西：一个量化的数字。

报告里明明白白写着：

• 采集对象总数：1284个
• 兼容对象：1215个，占比94.6%
• 需改造对象：69个，占比5.4%
• 预计改造工作量：约42人天

这个“42人天”的数字，比我当时拍脑袋说的“3周”精准太多了。而且后面还有明细，69个不兼容对象每一个都列出来了，问题类型是什么，改法建议是什么，一条条清清楚楚。

当时我就想，要是我那个翻车的项目有这份报告，我至少能提前知道：

1. 那1200行的存储过程是不兼容的，改造工作量要单独算
2. 那六十多个视图的函数引用问题，报告里全列出来了
3. 我给领导的排期可以是“6周，其中改造4周测试2周”，而不是“3周”然后延期

这就是数据决策和经验估算的区别。

三、金仓KES的KDMS是怎么干活的：采集源库对象

好了，前面铺垫这么多，接下来讲讲这个工具实际怎么用。我按自己的操作流程走一遍。

3.1 第一步：配置采集

用KDMS的第一步是让它连上你的源库，把对象采集下来。这一步需要在界面上填一堆连接信息，或者用配置文件的方式。

我习惯用配置文件，因为项目多，配置文件好归档。大概长这样：

# 源库连接配置
source.db.type=oracle
source.db.host=192.168.10.21
source.db.port=1521
source.db.name=orcl
source.db.user=business_user
source.db.password=********

# 采集范围配置
collect.scope=schema
collect.schema=BIZ_MAIN
collect.object.types=TABLE,VIEW,PROCEDURE,FUNCTION,TRIGGER,SEQUENCE,INDEX,SYNONYM

# 目标库版本（决定兼容性判断基准）
target.db.type=kingbase
target.db.version=V9R4

# 输出配置
report.output.path=/home/kdms/reports/
report.output.format=html,pdf

这里有几个点我想单独说一下，因为我自己一开始没注意，后面吃过亏。

第一，采集范围要选对。 我一开始偷懒，选了整个数据库全采集。结果采下来一堆系统schema的对象，几百个无关对象混在报告里，看得我头大。后来学乖了，按业务schema来采，报告干净很多。

第二，目标版本要填准确。 KDMS判断兼容不兼容，是依据目标库版本来的。我有个项目一开始填的旧版本号，评估结果里一堆“不兼容”，吓得我半死。后来换成实际要用的V9R4版本重新评估，很多原来标红的东西其实已经兼容了。这事儿后面我还会细说。

第三，密码别明文写在配置里。 这是个安全习惯问题，我们公司审计会查。KDMS支持密文方式，配一下就行。

3.2 第二步：执行采集

配置好了就跑采集。这个过程的快慢主要看源库的对象数量和网络。

我采集过最大的一个库，对象总数2800多个，其中光存储过程就有600多个。采集加分析，跑了大概40分钟。一般情况下的小项目，十几分钟就搞定了。

采集的时候工具会去读源库的数据字典，把表结构、索引定义、约束、存储过程源码这些东西都抓下来。注意它读的是元数据和代码定义，不会去扫你的业务数据，所以对源库的压力很小，白天跑也没事。这一点我专门确认过，当时怕影响生产，还先在测试环境验证了一遍才敢上生产源库跑。

3.3 第三步：等报告

采集分析完，报告就生成了。KDMS能出HTML格式的报告，方便在浏览器里看，也能导出PDF拿去开会。

报告出来了，重头戏才开始。

四、评估报告长什么样：我把核心内容拆给你看

这部分是我想重点讲的。因为评估报告是这个工具的核心价值，报告好不好用，直接决定了这个工具有没有意义。

KDMS的报告内容挺多的，我挑对决策最关键的几块说。

4.1 总览页：第一眼就要看的东西

打开报告，第一页是总览。这个页面我管它叫“给领导看的页面”，因为汇报的时候基本就看这一页就够了。

上面有几个核心数字：

指标	数值	说明
采集对象总数	1284	本次评估覆盖的全部对象
完全兼容对象	1215	无需任何修改可直接迁移
需要改造对象	69	存在不兼容点，需人工处理
综合兼容率	94.6%	完全兼容对象占比
预计改造工作量	42人天	按不兼容对象的复杂度加权估算
迁移风险等级	低	基于不兼容项的类型和分布综合评定

这几个数字里面，我个人最看重两个：兼容率和改造工作量。

兼容率告诉你这个项目整体难度。我做过兼容率98%的项目，那种基本就是“数据搬过去，改几个函数就能上线”的活。也做过兼容率75%的项目，那种就得认真掂量了，存储过程重写的量会很大。

改造工作量是直接给你排期用的。当然这个人天的估算不能当圣旨，但它给了你一个锚点。你可以在这个基础上，根据团队对业务的熟悉程度上下浮动，但至少不是从零开始猜了。

4.2 按对象类型的统计：颗粒度够细

总览下面是分类统计。这块我觉得是报告里最实用的部分，因为它把“哪些东西不兼容”拆得很清楚。

一个真实项目的数据，我搬过来：

对象类型	总数	完全兼容	需改造	不兼容率	主要问题类型
表	423	419	4	0.9%	2个含特殊类型字段，2个含XML存储
视图	156	138	18	11.5%	引用源库特有函数
存储过程	512	489	23	4.5%	动态SQL、特殊语法、自治事务
函数	87	76	11	12.6%	自定义聚合、特殊返回类型
触发器	64	61	3	4.7%	触发器顺序依赖
序列	42	42	0	0%	无
索引	689	685	4	0.6%	特殊索引类型
同义词	38	38	0	0%	无

这张表信息量很大。我逐行给你说说怎么读。

表和索引基本不用操心。 423张表只有4个有问题，这种量级就是开个会、拉个清单，一天内就能确认改法。索引同理。数据结构层面的迁移，现在的工具链基本都能自动处理。

视图和函数是问题集中区。 你看视图的12.6%不兼容率，是因为里面引用了源库特有的函数。函数12.6%不兼容率也是类似原因。这类问题的特点是：单个都好改，就是数量可能多，得逐个过。18个视图加11个函数，29个对象，每个平均按半天算，半个月的工作量就有了。

存储过程看绝对数。 512个存储过程里23个要改，4.5%看着不高，但架不住基数大。而且存储过程的改造深度差异很大，有的改两行语法就行，有的得整个逻辑重写。所以这块我会点进明细里逐个看。

这里我要插一句KDMS一个我觉得挺贴心的设计：它对存储过程的问题不是简单标红，而是会分类标注问题类型。比如“语法不兼容”、“依赖对象缺失”、“行为语义差异”这几种，处理成本完全不一样。语法不兼容的基本是机械改写，行为语义差异的就得坐下来认真读了。

4.3 明细部分：每个问题对象的具体分析

统计数字看完了，就要下钻到明细了。这是KDMS报告里篇幅最大的部分，每个不兼容对象都有单独条目。

我截一个真实案例里的条目格式（表名做了脱敏处理）：

对象编号：PROC-0178
对象名称：SYS_BILL_MONTHLY_SETTLE
对象类型：存储过程
所属Schema：BIZ_FINANCE
源码行数：847行
兼容性判定：需改造

问题清单：
[1] 行231：使用了源库特有的BULK COLLECT INTO语法变体
    影响范围：中 | 改造建议：替换为标准批量收集语法，涉及游标逻辑调整
[2] 行402：引用函数FN_CALC_TAX_RATE未在采集范围内发现定义
    影响范围：高 | 改造建议：确认函数归属，可能需纳入迁移范围
[3] 行568-612：包含动态SQL拼接，其中使用了源库特有的标识符引用格式
    影响范围：高 | 改造建议：需人工分析动态SQL的运行时行为
[4] 行733：使用了源库的自治事务特性
    影响范围：中 | 改造建议：目标库需确认等效实现方式

工作量估算：6人天
依赖对象：SYS_MONTHLY_BILL, SYS_SETTLE_RULE, SYS_ACCT_LEDGER

看到没有，这一条里面信息很全。行号、问题类型、影响范围、改造建议、工作量、依赖对象，全列出来了。

这个条目对应的存储过程847行，里面四个问题。其中“引用函数未发现定义”这种问题特别坑，因为它不是语法问题，是依赖问题。你源码看过去没毛病，但那个函数压根不在你评估的范围里，可能是别的团队维护的，也可能是个历史遗留。这种问题不提前发现，到联调阶段才炸出来，排查成本翻好几倍。

我自己做评估的时候养成了一个习惯：把“依赖对象”那一栏单独拉出来做个清单。因为有些对象本身兼容，但被不兼容的对象依赖着，改造的时候得分批处理，不然会牵一发动全身。

4.4 那个“42人天”是怎么算出来的

这块内容技术味重一点，但对理解报告很关键，我说简单点。

KDMS的工作量估算不是简单数“有几个不兼容对象”，而是有个加权模型。我观察下来，它大概考虑这几个因素：

1. 对象本身的规模：847行的存储过程和80行的存储过程，改造工作量肯定不是一个量级
2. 问题类型的难度：语法替换类的问题机械劳动，行为语义类的问题得动脑子，权重不一样
3. 问题的耦合程度：一个对象里有一个问题和有四个问题，处理时间不是线性叠加的，有沟通和上下文切换的成本

所以你会看到，同样是“需改造”的存储过程，有的标2人天，有的标6人天。

当然，这个模型不可能完美。我拿实际项目对过：KDMS估42人天的那个项目，实际改造花了47人天，偏差率大概12%。这个精度放在以前“拍脑袋±50%”的时代，已经是质的飞跃了。

而且我发现一个规律：项目越大，KDMS的估算越准。因为大项目的不兼容对象多，个体偏差会互相抵消。反而是那种只有五六个不兼容对象的小项目，单个估算的偏差会被放大。所以小项目用KDMS，我会把估算结果当参考下限，再人工加个缓冲。

五、拿着报告去开会：从“我觉得”到“报告显示”

工具好不好，最终要看它能不能改变你的工作方式。我讲讲评估报告在实际项目里怎么用的。

5.1 启动会：数据第一次说话

以前开迁移项目启动会，我是最紧张的。因为一汇报工作量，业务部门和技术部门的领导就开始砍价：“能不能快点？”“这个评估靠谱吗？”

现在开会，我的PPT第一页就是KDMS的总览截图。兼容率94.6%，改造工作量42人天，不兼容对象69个。

神奇的事情发生了：没人砍价了。

为什么？因为对着一个具体数字，砍价就变成了对具体对象的讨论。“这69个对象里，有没有可以先不迁的？”这种讨论是有建设性的。而对着“大概两三个月”这种模糊说法，讨论就变成了立场之争。

有一次一个业务领导指着报告问：“这18个不兼容的视图里，有6个是老报表，现在没人用了，能不能这期不迁？”

这问题问得好啊。我当场在报告基础上做了个减法：6个视图砍掉，工作量从42人天降到38人天，兼容率从94.6%升到95.1%。会议五分钟达成一致。

这种决策效率，以前靠人工评估根本做不到。因为人工评估给不出“砍掉这6个具体能省多少”的账。

5.2 排期和分人：报告直接变任务清单

评估报告的另一个用法，是直接转成开发任务。

那69个需改造的对象，每个都有问题清单和改造建议。我把它导出来，按对象类型和负责人分组，就是个现成的任务分配表。

• 23个存储过程，分给两个熟悉业务的老开发
• 18个视图加11个函数，分给一个细心的姑娘，这类活琐碎但难度低
• 剩下的表、索引、触发器问题，我自己处理，一天搞定

每个任务都有KDMS给的工作量估算做参考。谁的任务为什么估3天，为什么估6天，报告里写得明明白白。开发做完了，实际花的时间和估算对比一下，偏差大的复盘一下原因，下个项目估算就更准了。

这个过程里有个细节：改造建议那一栏特别有用。 很多不兼容问题，工具直接给了建议改法。比如“行231使用了源库特有的语法变体，建议替换为标准语法”，开发看到这个建议，本来要查半天文档的，现在直接照着改就行。当然不能盲目照抄，但至少省了查资料的时间。

5.3 风险汇报：不兼容项就是风险清单

项目风险管理里有个要求叫“风险登记册”。以前我做这个全靠脑子想，现在直接从评估报告里捞。

69个不兼容对象，按风险类型分：

• 高风险（行为语义差异、依赖缺失）：11项
• 中风险（语法改造、特性替代）：37项
• 低风险（机械性改写）：21项

高风险项就是我每周风险例会要过的内容。每项什么时候能确认改法，什么时候能改完验证，进度可视化。

甲方对这个也买账。因为风险不是我说了算，是工具分析出来的，带着数据来，带着进度走，甲方安全感强很多。

六、一个完整项目的评估复盘

空讲工具没意思，我复盘一个真实项目的完整评估过程。这是个医疗行业的项目，源库是个运行了九年的老库。

6.1 项目背景

• 源库：某传统商业数据库，跑了9年
• 目标库：金仓KES V9R4
• 业务领域：医院管理信息系统
• 特点：存储过程特别多，历史包袱重

6.2 评估执行过程

第一天：配置和采集

上午配好采集参数，中午挂上跑，下午出结果。采集对象统计：

• 表：512张
• 视图：203个
• 存储过程：743个（对，你没看错，743个）
• 函数：112个
• 触发器：89个
• 序列、索引、同义词等其他对象：638个

总对象数2297个。

第一天晚上：看总览

报告出来了，核心数字：

• 完全兼容：2161个
• 需改造：136个
• 综合兼容率：94.1%
• 预计改造工作量：118人天

看到118人天的时候我心里咯噔一下，这比客户预期的工作量大不少。但转念一想，总比报少了然后延期强。

第二天到第三天：下钻分析

接下来两天，我和团队把136个不兼容对象全部过了一遍。按对象类型分：

对象类型	需改造数	占该类型比例	最头疼的问题
存储过程	58	7.8%	14个超500行的大过程，含动态SQL
函数	21	18.8%	3个自定义聚合函数
视图	34	16.7%	引用了一批源库特有函数
触发器	9	10.1%	触发器执行顺序依赖
表	14	2.7%	特殊字段类型

有个发现让我挺意外的：报告里标出来7个存储过程，它们引用的子过程在源库里已经不存在了。也就是说，这些代码在源库里已经是死代码，调用链早就断了，只是没人清理。

我们拿着这个清单去找医院信息科确认，人家一看：“哦这几个是2016年某次升级废掉的，忘了删。”

结果这一下子核减了7个改造对象，还避免了无效工作量。这就是自动化评估的好处，它不带感情，死代码活代码一视同仁全给你列出来，人肉看的时候反而容易想当然。

6.3 用报告做决策

分析完，我拿着数据去和客户对方案。

第一个决策：范围裁剪。 136个不兼容对象里，有19个属于已经停用的历史模块（报告里依赖分析能看出来哪些对象在业务高峰期零调用）。和客户确认后，这19个对象不迁，工作量降到103人天。

第二个决策：分批策略。 58个存储过程里，有14个超500行的大家伙。这14个单独拉出来，安排了两个资深开发，每个负责7个，预留了充分的时间。剩下的44个小过程，平均每个1天多，分给其他人。

第三个决策：工期承诺。 基于报告，我们给出的排期是：改造阶段6周，测试验证3周，双轨并行2周，总计11周。客户拿这个排期去和院里汇报，一次通过。

后来项目实际执行，改造阶段花了6周零3天，偏差不到5%。这是我职业生涯里排期最准的一次。 而且过程中没冒出来任何评估阶段没识别到的大坑，这一点比准不准更难得。

七、使用中的坑和经验，我给你交个底

工具是好工具，但用的时候有些门道。我把我踩过的坑分享一下。

7.1 目标版本一定要对

这个我前面提过，这里展开说。KDMS评估的时候，兼容性判断是“以目标库版本为基准”的。同样的源代码，目标库版本不同，判定结果可能完全不一样。

我吃过一次亏：项目上用的金仓是V9R4版本，但我评估的时候配置里填了个早期版本号。结果报告里一堆不兼容，我拿着这报告去开会，把大家吓得够呛。后来发现配置错了，改过来重新跑，不兼容数从89个直接掉到54个。

教训：评估配置里的目标版本，必须和实际部署的目标版本严格一致。 这不是个可以“差不多”的参数。

7.2 采集范围宁全勿缺

有一次我评估的时候，只采了主业务schema，把另一个辅助schema漏了。当时想着那个schema就是个配置库，问题不大。

结果迁完上线，跑了半个月，一个跑批任务挂了。一查，那个任务调的存储过程在辅助schema里，用了一个源库特有的语法。

事后我复盘，如果当时把辅助schema也纳入采集，报告里标红那个存储过程，这个问题上线前就能发现。

从那以后我评估的原则就一条：源库里的业务schema，全采，一个不落。 多花点评估时间，比上线后救火便宜一万倍。

7.3 动态SQL是评估的盲区，要人工补位

这一点得客观说。KDMS对存储过程的静态分析做得很好，源码里写明的语法问题都能扫出来。但动态SQL——就是运行时才拼接出来的那些语句——它扫不到内部。

报告里会把含动态SQL的对象标出来，提示“需人工分析运行时行为”。这个提示很重要，但工具确实无法替代人工去看。

我的做法是：把所有含动态SQL的对象单独拉个清单，让业务开发逐个确认这些动态SQL可能拼出什么语句。这个环节偷懒不得，我们行业里出过事故的，很多都栽在动态SQL上。

7.4 报告是个基线，不是圣旨

最后说个心态问题。KDMS的报告很细，数字很唬人，但你不能把它当成百分百准确的圣旨。

它是基于代码静态分析的估算，覆盖了绝大部分风险，但有它够不到的地方：

• 运行时性能差异（比如某个查询写法在目标库跑得慢），这个得靠后面的性能测试
• 数据本身的脏数据问题（比如字符串里有非法字符，迁过去报错）
• 应用侧的连接驱动、ORM框架适配问题

所以我的完整评估流程是三段式：

1. KDMS自动评估：覆盖代码兼容性，占评估工作的70%
2. 人工专项分析：动态SQL、特殊依赖、业务逻辑确认，占20%
3. POC验证：搭环境实测关键链路，占10%

三者合起来，才是完整的评估。KDMS把最耗时的那70%自动化了，这已经省了我天大的事。剩下的人工部分，有了报告打底，做起来也有方向得多。

八、从“猜”到“算”：评估方式改变了什么

写到这儿，我想停下来聊聊这个变化背后的东西。

以前我们做迁移评估，本质上是一种经验驱动的抽样调查。你看100个存储过程里的20个，用那20个的复杂度去推算整体。这个方法在对象数量少、代码风格统一的时候，还能凑合。但现在的系统动辄几千个对象、十年以上的历史积累，抽样误差大到没法用。

KDMS这类工具带来的变化，本质上是从抽样变成了普查，从估算变成了测量。

2297个对象，每一个都被扫过，每一个都有判定。你的决策依据从“我感觉大概”变成了“报告显示5.9%的对象需要改造”。这两种决策方式的可信度，完全不是一个量级。

而且这个变化有个连带效应：评估报告成了项目各方的通用语言。

以前技术团队和业务团队谈迁移，鸡同鸭讲。技术说“存储过程兼容性有风险”，业务听不懂。业务问“到底多久上线”，技术不敢给准数。

现在有了量化报告，桌子中间摆着同一份数据。业务看兼容率和人天，技术看问题清单和改造建议，领导看风险等级和排期依据。讨论从“我认为”变成了“报告第几页显示什么”。

这一点，我觉得比工具本身的任何单一功能都值钱。

九、写在最后的一些话

聊了这么多，我在这行干久了，越来越认一个理：技术决策的质量，取决于你掌握的信息的质量。 迁移评估这个环节，以前是整个项目里信息最模糊的部分，所以也是最容易出幺蛾子的部分。

电科金仓的KDMS把这块补上了。它不是什么高深莫测的黑科技，原理说白了就是“把源库对象全量采集，挨个做兼容性分析，汇总成量化报告”。但就是这么个朴素的思路，把评估这件事从“老师傅的手艺”变成了“标准化的流程”。

对要上手的朋友，我给几条实在建议：

1. 评估先行，编码后置。项目一立项就跑评估，别等方案定了才想起来。评估结果会影响你的方案设计。
2. 报告要下钻，别只看总览。总览是给领导看的，明细才是干活的人要读的。
3. 目标版本配置要对，采集范围要全。这两个错误最常见，代价也最大。
4. 把报告当基线，人工补盲区。动态SQL、性能问题这些，工具标出来的地方要人工跟进。
5. 用报告驱动沟通。启动会、风险会、评审会，都把报告带上，沟通效率天差地别。

对了，补一句大家关心的：金仓的这套东西是跟着商业授权走的，金仓KES的KDMS是配套的评估工具，没有开源版本，要用得走正规的商务渠道获取。这不是什么公开下载的社区工具，这点大家心里要有数。

最后说句实在的。我现在接迁移项目，第一件事就是问一句：“KDMS的评估报告跑了吗？”没跑的，先跑报告再谈方案。

这不是迷信工具，是迷信数据。在数据面前，经验只能当参考。 这句话，是我那次翻车项目用血泪换来的。

就写到这儿吧。希望正在做或者准备做迁移的你，别再经历我当年那种“雾里开车”的日子。评估这一步做扎实了，后面的路，其实没想象中那么难走。