Approach | Description | Benefits | Drawbacks |
Lifetime Extension and Future Proofing | The legacy code is restructured to reduce dependencies (“disentanglement”). Large programs are broken into smaller, reusable components with well documented internal and external interfaces. Components stay on legacy programming language and platform. | - Low-risk modernization strategy
- Reduced dependencies, allows for independent maintenance and testing of components
- Prerequisite for flexible sourcing models and migration of individual components to new platforms
- Evolutionary, low risk approach
| - Takes very long-term view on modernization strategy
- Only medium term ROI
- Doesn’t solve problems with high operation costs and license fees for legacy platforms
- Doesn’t solve skill shortage problems on legacy platforms
|
Legacy Transformation | The business knowledge embedded in the legacy applications is extracted and re-coded/migrated to modern technology | - More flexibility, faster to react to market demands
- Improved ability to manage complexity, due to modern, layered architecture (SOA, BPM)
- Reduced operating and maintenance costs
- Future proof, also from a skill point of view
- Less risky than complete re-write from scratch, because of well defined functional scope
- Faster execution than evolutionary disentanglement
| - More risky than Lifetime Extension
- New, unproven architecture (scalability, security, fault tolerance)
|
Re-Write from Scratch | The application is written from scratch, without salvaging any assets from the legacy system | - Allows to re-capture business requirements, and provide a solution which is closer to today’s needs
- All other benefits of modern, open, layered architectures (flexibility, agility, cheaper operations)
| - No cost savings due to re-use of existing assets
- New, unproven architecture
- Often suffers from feature creep, because this opens the scope discussion too widely
- Probably the most risky approach
|
Re-Hosting and Automatic Transformation | Automatic conversion of legacy application to different operating platform and/or programming language | - High level of automation possible (up to 95%)
- Quick relief on operational issues (e.g. end of life of legacy platform)
| - Does not address any of the issues with monolithic application architecture and bad quality code (“Garbage in, garbage out”)
- Especially in case of automatic code transformation (e.g. COBOL to Java), the end result is even harder to maintain than the original code
|
Replacement with packaged application | The legacy applications are replaced with modern, off-the-shelf-packages. | - Often lower acquisition, maintenance and operation costs than custom applications
- Often richer features, better quality than custom applications
| - Only feasible if suitable application package is available (otherwise risk of high customization costs)
- Business often has to modify processes to meet functionality which is available out of the box.
|
