Time To Update Application modernization/re-engineering is considered when existing legacy applications enjoy properties worth preserving. They are already deployed and have usually undergone significant scrutiny by their users. A long history of maintenance has resulted in “stress-hardened” code and a wealth of test and validation capabilities. Nonfunctional properties such as performance and accuracy have been fine-tuned. Application history exists in the form of original designers, current and past maintainers, and (potentially) in bug reports and change order records.
However, the same history of maintenance that “stress-hardened” the applications, cause a problem: the system becomes ‘brittle” and increasingly resistant to change, hard to modify, and thus becomes a candidate of modernization projects.
Legacy Modernization, or Software modernization, refers to the conversion, rewriting or porting of a legacy system to a modern computer programming language, software libraries, protocols, or hardware platform. Legacy transformation aims to retain and extend the value of the legacy investment through migration to new platforms.
Motivation or “Need” for Migration
There are a variety of reasons that a migration of a legacy system may be needed:
Legacy languages are hard to support:
The legacy languages and development tools needed to support the legacy system are increasingly difficult or expensive to obtain. This is a very common occurrence with 4GLs popular in the 1970s.
People are scarce:
People that know the legacy languages are becoming difficult to find and retain. Younger staff are reluctant to learn “legacy” languages because it does not appear to advance their long-term career.
The underlying platform is hard to support:
Many legacy systems run on legacy hardware systems. Such hardware systems are becoming more expensive to maintain, and personnel that know these systems are also more difficult to find.
Legacy software does not integrate well with other IT systems:
The architecture of legacy languages often does not lend itself to building bridges to other IT systems that have grown up around it.
Migrating larges software applications needs automation. The need to migrate mainframe software is often motivated by a mixture of motives, including :
- The high cost of operating the mainframe
- Shrinking pool of IT personnel that understand the mainframe system languages and structure
- Need for faster application evolution in response to changing requirements by use of more modern software engineering methods
- The need to integrate the application and its data more effectively with the balance of the organization
Yet most of the legacy software performs an extremely valuable function which must not be disturbed by a migration. Hand-migrating large applications by re-coding from scratch usually causes huge management overheads when the migration team attempts to re-validate the requirements with management. Hand-migrating by translating line for line introduces errors by damaging implicit business rules, and suffers from scope creep. In addition, there is a continual war between the application maintenance staff, which must keep the application running during the migration process, and the migration staff, which does not want to see any change during the lengthy migration process. As a consequence, many manual migrations fail or run significantly over time and cost budgets. Offshore hand-migration suffers the same problems as well as communication and coordination problems.
Many organizations face the problem of having to modernize their existing software systems by migrating to more capable systems. Modernizing legacy software systems is a complex engineering problem that includes most aspects of traditional software development with more constraints. A successful migration effort requires both a sound development plan and a sound migration plan.
A development plan addresses the selection of the appropriate software processes, methods, tools, and hardware and software platforms. A migration plan created in conjunction with the development plan is necessary to help ensure that the operational transition to the new system goes smoothly.
A good migration plan should weigh programmatic and technical drivers for system development against customer priorities. Because of this, the plan may impact system development and certainly should impact system deployment. Iteration among the key stakeholders is necessary for an effective migration effort. Like development, migration planning involves tradeoffs among cost, schedule, risk, and resources.
Legacy system modernization is often a large, multiyear project. Because these legacy systems are often critical in the operations of most enterprises, deploying the modernized system all at once introduces an unacceptable level of operational risk. As a result, legacy systems are typically modernized incrementally. Initially, the system consists completely of legacy code. As each increment is completed, the percentage of legacy code decreases. Eventually, the system is completely modernized. A migration strategy must ensure that the system remains fully functional during the modernization effort.
Making of software modernization decisions is a process within some organizational context. “Real world” decision making in business organizations often have to be made based on “bounded rationality”. Besides that there exists multiple (and possibly conflicting) decision criteria, the certainty, completeness, and availability of useful information (as a basis for the decision) is often limited.
Legacy systems are still alive because of their distinct characteristics and good pedigree. In the last 40 years, we have learned that it is neither practical nor affordable to migrate $5 trillion worth of legacy code into other technologies which were short lived. However, it is possible to either eliminate or integrate the legacy systems by following effective migration strategy and appropriate migration tools.