过去的历史经验表明，依托大型机托管20个或更多应用程序，长期来看成本更低，但目前需要解决的是短期成本问题，因此很多公司下定决心要将所有大型机应用全部迁移到Unix、Linux和/或Windows平台。
　　6年前，在IT成本削减大潮推动的最后时刻，抛弃大型机还很困难，但现在从大型机迁移大型企业级关键应用已经变得越来越简单了，其中一个原因是IBM和用户在现代大型机应用和中间件方面都做出了巨大的努力，另一个原因是目标平台本身也更标准化，同时提供了更多的迁移工具可供选择，现在的厂家也为迁移提供了更好的服务水平。
　　因此，在大部分情况下，如果不出现问题或问题较少，从大型机迁移可以在合理的时间范围内完成（如在1到2年内迁移200个应用），但如果采取的迁移策略不当，很可能以惨败结局，想要获得成功，用户实施时必须采取正确的策略和最佳实践。
　　大型机迁移的三大策略
　　一个成功的大型机迁移策略的基础是理解迁移的目的，迁移不是为了尽可能快速和廉价地将大型机应用移动到新的平台，而是为了在合理的时间范围内将这些应用的功能移到目标平台上，并且对最终用户的影响要降到最低，在迁移过程中过份强调准时或成本只可能导致迁移后的应用不能很好地适应新环境，其后续发生的问题消耗的成本可能比快速迁移节约的成本要高得多。
　　要降低迁移及迁移后的系统中断时间，必须采用下面三大策略：
　　软件分类
　　分步实施
　　使用第三方迁移服务
　　下面我逐个进行解释。
　　软件分类
　　一般说来，如今的企业都会使用下面这三个方法迁移一些大型机应用到Unix/Linux或Windows平台：
　　迁移：将程序源代码或二进制代码不做修改或稍做修改移动到另一个平台上，开发人员在新平台上再增加需要的功能。
　　重建：首先对程序实施反向工程，这个过程创建一个抽象的设计模型，然后在新的平台上使用新技术重新生成应用程序。
　　替代：丢掉现在的大型机应用，在新平台上编写一个全新的应用，新的应用程序包含旧程序的所有功能。
　　听起来似乎有点违反常规，但如果可能，最好的方法是重建，记住，首要目标是要最小化业务中断，经过重建，可以在新环境中对程序进行再次调优，因此在新平台上可能比在大型机上运行得更好，同时，掌握了设计模型后，检测和修复遗留的性能问题就相对轻松多了。
　　因此对大型机应用程序进行分类，可以很好地识别那些程序应该重建，那些可以迁移，那些必须重写，并可以推断出那些应用迁移会对用户造成较大的影响。
　　分步实施
　　过去，大型机应用迁移要么设定一个切换日期，一旦切换完毕，大型机就可以关闭了，所有应用全部运行在新的平台上，要么大型机一直开着，以防万一。
　　这意味着你的计划应该包括以下步骤：
　　新应用开始运行后，旧的应用也不要关闭；
　　如果可能，分步按功能或按部门使用新的应用；
　　创建一个网络切换开关，可以在新旧应用之间快速切换；
　　不要同时迁移所有应用，等用户完全适应新平台上的应用后才关闭大型机上的应用，或许需要3个月，6个月不等。
　　使用第三方迁移服务
　　虽然今天的IT部门在大型机和新平台方面都积累了不少知识，但要靠IT部门的力量就完全实现大型机应用的迁移显然不太现实，一方面他们没有迁移的经验，二是可能缺少关键的工具，三是没有深入到每个应用中去，但第三方迁移服务商就不同了，他们有专家级队伍，有大量的实战经验和技术积累，已经熟悉流行的应用，他们可以熟练地实施迁移任务，可以将停机时间，应用中断时间降到最低。因此花钱购买第三方专业迁移服务在资金预算充裕的情况下应该考虑。
　　在后面的文章中，我将会介绍如何选择第三方迁移解决方案，这里我只想告诉你，过去几年，已经有很多迁移服务商成功地迁移了许多中等规模的企业级应用。
　　一个有效的迁移策略是迁移成功的关键，一个好的策略通常不是一个人能够实施下来的，也不会这么写，在迁移过程中还需要考虑是否要扩展应用程序的功能，这样可以再多花一点钱以满足未来几年的变化，另外还需重点考虑的就是云计算，接下来我继续讲述迁移大型机应用到Linux，Unix和windows平台有效方法。
　　我们假设你有一个项目的目标是迁移走大型机上的所有应用，通常这个时候你会担心运行在z/OS上的旧应用程序，特别是那些与大型机紧密相关的技术，如COBOL，IMS，CICS等。我们再假设你已经根据本系列的第一篇文章制定好了最佳实践策略，首先将要迁移的软件进行归类，然后选择第三方迁移工具和列出详细的操作过程。
　　接下来的任务是任务分解，首先弄清楚哪些软件最容易迁移，然后为不同类型的大型机软件制定迁移步骤，准备相关的工具，总之就是要将复杂的任务进行分解，划分成一个个容易实现，容易办到的小任务。
　　根据迁移难度级别划分应用程序
　　因为大部分大型机应用都依赖于大型机特定的环境，过去用户发现这类迁移比Unix迁移到Linux，或windows迁移到Linux都要复杂得多。那些不会使用任何大型机特定的软件或固件用COBOL编写的应用程序，大多数时候可以在目标平台上实现开箱即用的效果，这几乎没有难度。那些依赖于COBOL的和某些使用了CICS的应用程序，在Unix/Linux/windows上需要使用CICS或UniKix，也就是说需要在新环境中重新创建CICS，这有一点难度。
　　难度大一点的是那些只依赖于COBOL，DB2和/或CICS的应用程序，DB2转换并不简单，即使DB2在大型机和其它平台上现在都能很好地运行，但由于大部分依赖于DB2的应用程序使用存储过程实现的业务逻辑，而这些存储过程往往是依赖于大型机的。此外，多个应用可能使用的是相同的数据库/数据存储，但存储过程却又不同，因此需要在目标平台上重建那些存储过程。
　　除了那些20多年前的主流软件外，还包括依赖于第三方大型机数据库——Datacom，MODEL 204，Adabas的应用，以及IBM数据管理系统——IMS。许多应用使用专用编程语言（MODEL 204用户语言）或老式的3GL（第三代语言）——PL/1、FORTRAN。因此，这些应用程序如果不能在目标平台上顺利通过编译，那就得重新编写代码了，但幸运的是，现在许多迁移工具已经能够帮助我们自动完成代码重写任务，因此迁移规划一般只需要几个月，而不会长达几年了。
　　我们再来看看那些严重依赖于IBM程序集或裸机ISAM和VSAM数据存储技术的应用程序，这些应用通常缺乏说明文档，可能无法完全搞清楚，那些当年编写这些应用程序的人现在可能已经退休了，因此，自动再生工具可以指出在新环境中重建它们的方法，最著名的就是10年前千年虫问题期间出现Y2K这样优秀的再生工具，有些工具正是因为其处理艰巨的迁移任务的能力得以生存至今。
　　但值得注意的是，即使有些应用程序你做了很大的努力去修改它，但它仍然不能很好地在新平台上运行，于是出现了一些分析工具，它可以对应用程序的功能进行分析，并捕获它们的行为，然后模拟这些行为在新平台上生成新的应用程序，至少可以为开发人员生成这些不可迁移的大型机应用程序在新平台上的基础代码。
　　任务分解
　　关于任务分解的最佳实践与你如何使用大型机应用程序分类结果有关，聪明的用户不会首先将重点放在关键业务应用程序上，无论它是否容易迁移，因为这样做会造成整体迁移进度滞后，相反，这些用户首先会为每个分解的任务寻找合适的工具，并制定好各自独立的迁移步骤，然后优化整个过程和资源分配。
　　在分解完任务后，应该确定哪些应用程序不需要迁移，因为你可能发现这些应用程序不是那么容易迁移，同时找出最容易迁移的先行迁移。
　　在分解任务时还需要重点考虑的是尽量使用自动化迁移工具，不要图便宜使用廉价但功能不佳的迁移工具，迁移关键业务应用时尤其应注意这一点，因为它可能是最大，最复杂的应用了，迁移这些关键应用所花的时间可能也是最多的，而且是整个迁移工作中最主要的一步。
　　小结
　　如果你读完本系列文章，你对迁移所有大型机应用应该都会有一个清晰的思路，每一步使用什么工具最好，有哪些步骤最佳应该都有把握。
　　但我要告诉你不好的消息，大量的迁移实践证明，简单的划分应用是不行的，分解的目的是要找出迁移到新平台上需要花多少时间，而不是软件在新平台上如何才能更好地运行，在新平台上性能是否有明显的下降，是否可以简单地一次性迁移成功，过去的经验表明，这些因素往往是造成迁移延迟的重要原因，也是造成用户业务中断的罪魁祸首。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。