Before embarking on a legacy modernization initiative, it’s important to select the migration approach that best fits your budget, timeframe and goals. If your application logic and data structures no longer meet your business needs in their current format, you are likely looking at one of a few scenarios:
- Implementing a commercial off the shelf (COTS) solution
- Creating a new custom application from scratch
- Re-architecting your legacy application into a new framework
While each option may ultimately provide you with an updated environment, there can be significant tradeoffs in how each approach gets you to your final destination.
Commercial off-the-shelf software (COTS)
COTS packages, such as SAP and PeopleSoft, are viable alternatives for legacy environments where current business and technical functionality can be met with minimal customization (e.g., standard accounting functionality or enterprise reporting solutions) or when you are fully prepared to change business processes to fit a package.
If your current IT system provides significant competitive differentiation, or enables jurisdiction-specific policy or regulatory compliance functionality, it could take years to accommodate your custom functionality into a package. Although moving to a COTS environment provides a standardized target application environment, findings show that many of these projects exceed their scheduled completion time and allocated budget.
Custom application development
Developing a new application to replace your legacy system can be the right choice if much of your current program code and business logic is not salvageable. This strategy is not recommended for the replacement of primarily business-relevant legacy systems, as the custom application development approach does not incorporate methods and tools for harvesting the intellectual property (IP) embedded in legacy systems.
The custom application development process can be lengthier than other approaches because additional steps must be followed to ensure that appropriate functionality is built (e.g., requirements gathering, additional analysis, design documentation and new test case builds). While there may be some reference made to legacy functionality, there is very little reference, if any, to the legacy code in the final output.
Application re-architecture is best suited for applications that are still business-relevant and provide differentiation, or when you are unable to change your business processes to fit a package. With this approach, you can increase IT efficiency with agile architectures that allow for continued growth, while quickly adapting and responding to changes in business demands such as cloud, mobile and big data.
Rather than starting from scratch, application re-architecture eliminates the obsolete code in your application that constrains your agility, while preserving and enhancing business-relevant functionality. This approach reduces the time, effort and cost to add new functionality as compared to moving to a COTS package or rewriting from scratch.
- Does your application support processes that differentiate your business or commodity business processes (e.g., standard accounting functionality)?
- Can your change your processes to fit a package or would your have to tailor a package to fit the business?
These are some of the questions an experienced partner can help you answer by conducting an assessment of your existing environment and your in-house capabilities – two aspects you need to consider before deciding which route best serves your needs.