Our recent post Modernize Or Die covered the existential threat facing many businesses, a threat arising from an inability to innovate brought on by the spiderweb of technologies and architectures prevalent in legacy software systems.

Doing nothing is no longer an acceptable option. So what are the alternatives?

In broad terms there are three.

1. Replace the legacy system with an off-the-shelf package

This is an option for the enterprise rather than the ISV (Independent Software Vendor). As an ISV you can’t replace the product you sell with somebody else’s although it could be an option for back-office systems.

This option has the highest cost and lowest competitive advantage. It’s the highest cost because it’s off-the-shelf software and it offers the lowest competitive advantage for the same reason – it’s standard code albeit likely with the opportunity to customize.

Where competitive advantage is not being derived from the application in question, the “Package” option has merit.

Enterprises adopting this option often do so as a convenient way to move from an on-premise legacy system to a cloud-enabled application. Dale Vecchio of Gartner has started to refer to this type of cloud-enablement as “Migration”.

As an example, Pekin Insurance recently announced that they are working with system integrator PwC to implement Guidewire’s standard insurance platform and move its entire Property & Casualty line to the cloud.

In the banking sector, TechNavio recently forecast the global market for third-party banking software, i.e. “Package”, to have a 7% CAGR between 2015 and 2019.

2. Rewrite the legacy application from scratch

How many years do you have? This is not necessarily the most expensive option (especially given the temptation to offshore the work) but, in terms of time to market, it is the longest; has the highest risk and least chance of success. At Morphis, we routinely receive enquiries from companies who started down this route and then realized that it was an endless journey and smartly decided to change tack before all was lost.

3. Use application modernization technology and processes

The “Modernize” option is distinct in working with the legacy system and either transforming it to new multi-tier architectures, or “wrapping” it so that it can be exposed in new ways such as a web front end.

3.1 Wrapping

This approach takes the legacy system as it is and essentially applies a “connectivity” layer that will enable web/mobile deployment and improve user experience. The connectivity solution could be API-based a la Mulesoft or use some other technique such as Capriza’s workflow approach.

While wrapping has the advantage of rapid deployment it does nothing to address the inherent issues with the legacy code (what’s in there, how stable is it, how secure is it, who understands how to make changes, it’s still running on that expensive hardware etc). Nor is wrapping suitable for dynamic applications. For example, enterprises who need to make regular changes to their legacy systems to maintain regulatory compliance still face the same challenges even when the application is “modernized” using wrapping.

Dale Vecchio of Gartner uses the term “non-invasive application modernization” to describe wrapping.

3.2 Transformation to a multi-tier architecture

This approach takes the legacy application in whatever language it is in and transforms that code to a new target environment, typically a multi-tier architecture. The legacy application is basically implemented on a new technology stack.

There are many levels of sophistication on the market for what Dale Vecchio of Gartner terms “invasive application modernization”. There are the garbage in/garbage out, point-to-point solutions of the automatons promising ridiculously high automatic conversion rates yet unable to deliver any kind of success on code that is anything other than the most basic.

And then there is Morphis, offering a single solution across many source languages and delivering cloud-compliant transformations to Java or .NET in an as automated as possible fashion and routinely delivering the most complex modernization projects globally today.

The Morphis approach begins with analyzing the legacy system to identify duplicate code, redundancy, module interdependence and complexity, not only to document the state of the legacy system to also to determine the size and risk associated with modernizing the code.

Indeed every alternative introduced here requires upfront analysis. For example, with the “Package” approach you need to identify the functionality gaps between the old legacy application and replacement app and fill them either with custom code or other apps.

And then there’s the business logic (the corporate IP for most enterprises) – how does this get identified and modernized?

Watch out for further posts to explore these alternative approaches and trade-offs in further detail.