企业遗留项目改造和迁移有用的经验都有哪些？

之前做过几个遗留项目的迁移工作了， 每一个都有各自的特点， 然而有用的经验却有很多共同点。

归纳起来有以下几点：

  • 首先要深入了解遗留项目的背景、现状和未来期望，包括业务场景、技术框架、历史演进过程等；
  • 其次要有一个富有经验、技术扎实的团队来做支撑，包括管理、产品、开发、测试、运维等各方面人才均要能力突出，同时保证人员的相对稳定、专注和可持续；
  • 再次需要管理好高层的期望和预期，协调好各参与方的利益和参与度，协调好相关部门的合作沟通机制等；

企业遗留项目改造和迁移的机会在哪里？

传统企业存在着大量的历史遗留系统，都是可以进行改造和迁移的机会。一些可能因为技术落后，一些可能因为跟不上业务需求的变化，一些可能因为使用量增加性能不足，还有一些可能是因为界面显得老旧，希望能够改头换面、焕然一新。总之都是当前的系统从非功能需求方面无法满足日益变化的功能性需求引起的问题。

也有一些是企业 IT 部门在长期战略方面的综合考虑而提起的改造方案，以期在业务需求提出更高要求时，可以及时跟上时代的技术变迁和企业集团的长远战略规划等。

以上这些方面均可以通过与客户的紧密合作、深度沟通获得相关信息，同时还有一个非常关键的方向，就是客户方对于我方的技术水平、管理能力的信任和长期合作的意向。需要日常的长期工作配合、最新技术风向的把握和业界行业所积累的口碑等来共同建立影响。

企业遗留项目改造和迁移的策略和原因是什么？

通常企业遗留项目改造和迁移即有可能由业务部门提出，也有可能由相关的 IT 部门提出，而且通常由 IT 部门提出的相对比较多些，业务部门提出的需求，通常会由 IT 部门由当前的维护团队来进行实现和维护，而并非全面改造和迁移。

而业务部门如果提出改造和迁移的需求时，通常就会是启动全新的开发项目，以应对全新的战略目标和市场需求。

那么 IT 部门提出改造和迁移的需求，则多数是缘于以下一些原因：

  • 遗留系统维护成本的日渐增高或不可行，如一些遗留系统的技术人员流失，市场上已经较难找到相应技术的人员来进行日常的开发和运维了。
  • 遗留系统的技术栈过于老旧，最新的基础设施需要升级，而应用软件无法跟随升级，已经无法再支持继续的运营和正常使用了。 例如： jQuery、IE 浏览器、IBM Notes、Angular 1.x、J2EE/EJB、SSH(Spring+Struts+Hibernate) 等退出历史舞台的情况，就会导致相应的软件项目无法继续安全、正常使用的情况。
  • 遗留系统

项目改造过程的关键问题是什么？

项目改造过程通常需要几个月到一、两年的时间，期间最关键还是技术人员的稳定和技术路线的前瞻性，一方面技术解决方案要综合考虑项目特点和未来发展，使得改造后的系统能够长期稳定地伴随业务发展演进变化；另一方面改造团队的技术人员需要相对稳定，从了解需求，到深入实施方案，需要创新的探索精神和认真的求解精神，使得项目从遗留系统到全新系统得到稳定平滑的传承和升华。

整个过程，需要注意以下这些方面：

  • 选择合适当下的技术框架，解决当下最紧迫的业务问题。
  • 调研清楚客户的使用场景、业务流程等细节，理解客户当下及未来可能的业务发展，搭配最恰当合适的技术解决方案。
  • 让有经验和专业技术的专家提前进入项目调研，综合多方意见，结合具体开发团队特点以及业务需求，给出恰当的改造迁移路线。
  • 通常应该考虑如何稳妥地进行迁移改造，结合遗留项目特点，使用先进的技术方案，可以考虑逐步平滑过渡，使用户体验不受太大影响。

能够复用的能力是什么？

遗留项目一个接一个需要迁移和改造，而项目团队确可以长期稳定持续发展，团队的技术也才可以得到长期持续的积累和提升，彼此的协作和配合变成不可复制的核心竞争力：

  • 因此不断关注技术发展的趋势，提前布局最先进有价值的技术，进行人才和经验的积累将变得非常重要。
  • 不断巩固和提升人才、引进、培养和输送的综合管理能力。
  • 不断积累和发展的新技术研究和探索能力，从而给客户带来略超前于市场主流的技术方案，如此才能让遗留系统在迁移、改造后又重新站在时代和市场的前列。
  • 敏捷软件开发和极限编程的综合实践能力，是长期赢得客户专业认可的永恒能力。