该迁移案例共分为三步，一、评估：预判迁移风险；二、计划和验证：找到最佳迁移路径；三、严密的测试 上线水到渠成。
二、计划和验证：找到最佳迁移路径
提要
上一篇，浪潮的工程师向小编介绍了迁移评估，在经过这个阶段的“把脉问症”后，迁移工作将进入计划和验证阶段，也就是“开方子”和“专家会诊”阶段。
计划——“开方子”
计划阶段好比“开方子”，但并不是每个医生第一次开的方子都是正确的，所以计划阶段其实是对评估阶段的“体检报告”对症下药，决定采取何种诊疗方案。
制定计划的核心
计划的核心目的是，将评估结果和客户需求相结合，生成一个可以给客户清晰可见的执行方案。这里面包含：针对项目浪潮的迁移团队打算怎么做？实施步骤是什么？业务分工包含哪些？以及包括ISV在内的第三方资源如何协调等。
同时，要保证计划的制定要落实到每一个环节，并且对每个环节都要做风险评估。这样做的目的是确保一旦当某个环节出现问题，或者某些应用迁移不过去的时候，该采取什么措施，协调什么样的资源去支持迁移工作？这些都需要写进迁移计划方案里。
在河南某银行迁移过程中，浪潮迁移团队在了解客户需求和IT状况后，对向K1平台迁移制定计划：
1、硬件平台入场的调试安装步骤；
2、基础软件在K1平台的兼容性测试计划；
3、应用系统在K1平台的功能性测试计划；
4、模拟数据在迁移后系统上的测试计划；
5、运维监控工具和监控方式的培训计划（如果客户原有监控手段不变，可以不用此计划）；
计划全面，确保回退
在制定兼容性测试计划的时候，由于客户的数据库是从Oracle迁移到DB2数据库，在评估阶段会发现原有的系统会用到Oracle特有的函数和存储过程，而DB2的转换工具不一定能100%实现转换，那么我们在制定计划的时候，就需要增加对客户特定的存储过程的迁移做测试计划，并评估如果无法完成转换。
下一步的步骤该如何做，是否需要提前引入DB2的工程师支持，还是和应用开发商沟通，更改应用程序的代码？
如果前2种都不能满足，是否考虑依然退回沿用原来的数据库，同时在计划阶段，需要把此类风险和客户充分沟通，有助于客户早期决断，避免客户在系统迁移到一半的时候，出现无法回退的情况。
验证——“专家会诊”
验证是对迁移计划的校验过程，校验之前医生开的“方子”是否可行，需要众多专家一起“会诊”。
验证内容
验证的内容包含：人员分工协作的校验；时间节点校验；应用迁移模块和过程的校验；对数据完整性的校验等。
在迁移过程中，有时会出现在理论评估阶段认为迁移环境兼容性是一致的，但实际在迁移的过程中会发现一些异常。因此验证的主要目的是，在制订了完整计划以后对迁移的计划中的每个步骤，进行分解检验，通过验证过程中的预先演练，找出在迁移过程中可能出现的应用基础软件的版本不兼容问题，系统的环境变量以及核心参数设置的错误，软件编译出错以及数据库对象无法正常工作等意外。通过演练，严格按照执行计划进行反复地测试，保证任何一位迁移工程师，在针对该业务迁移的时候通过标准化操作，都能获得一样的迁移结果，从而大大降低在正式迁移中所遇到的风险。
验证场景
下图列举的是一个原先运行在X86平台的3个Java应用和国外小型机上的数据库全部迁移到K1平台的场景。在应用层的迁移的时候，需要验证JDK的版本有没有变化，功能模块是否正常工作，应用代码是否可编译等等问题；在数据库的迁移，需要验证迁移前后数据的完整性，数据库对象是否可正常工作等一系列的问题。
验证主要解决应用兼容问题、数据库调优和性能优化。验证阶段，迁移团队要全程记录验证过程中的BUG和解决方案，并针对此生成相应的“升级包”（一种可执行的规范性的校验操作手册），固化迁移过程中的问题修复流程，以便在正式迁移过程中，迁移工程师可严格按照升级包和迁移计划，“有迹可循”地快速对应解决在验证阶段发现的问题。
公开透明的迁移过程
正因为有了充分的计划以及严谨的验证过程，使得整个迁移过程对客户公开透明，客户可以充分了解整体迁移计划可能出现的风险点，浪潮迁移团队的工作分配，合作伙伴的专家支持等信息，从而打消客户的种种顾虑，避免在上线阶段出现的各种意外而引起的割接失败，从而有计划、有步骤地帮助客户完成业务系统的升级工作。