Application modernisation: Safe and steady on an incremental journey

“It’s not the destination, it’s the journey that counts” is an old adage that is gaining fresh resonance in the business world. The maxim is relevant when aligning IT with business goals, especially when choosing ways to migrate and modernize business-critical applications and data that run on mainframes.

As we’ve learnt, paying attention to the journey and being light footed is vital when external shocks like the pandemic or market volatility mean that business priorities can switch overnight.

Legacy application modernisation is a complex endeavour that rarely lends itself to a simplistic A-B route. But that doesn’t mean it should become an unpredictable journey.

Taking decades of unique business logic embedded into applications, and moving them to cloud or open source environments where they can better power innovation for the modern enterprise, is no mean feat. That mainframes are still with us is testament to the difficulty of the migration and modernisation task. And, at the same time, our own research tells us that 92% of organisations want to reduce their dependency on the mainframe- reflecting a new priority in the boardroom.

Choose gradual, mixed mode for early return

Given the layers of complexity and interdependencies that pile up in legacy environments, LzLabs advocates a gradual, incremental approach to application modernisation. Developers and businesses in other domains are busily embracing an agile philosophy of continuous iteration, going to market faster with products that meet customers’ changing needs. A step-by-step modernisation approach brings companies gradually closer to their target architecture, prioritising legacy assets according to their business criticality and technical complexity. It is a gradual, mixed-mode model to workload modernisation that minimises project risk and also delivers value early, builds trust for further investment, and introduces transparency that shores up scarce in-house skills.

I like to cite the example of a vehicle manufacturer that opted for an interim, staged approach when shifting its configurator application off the mainframe. The company was able to prove a reduced MIPS footprint for the rehosted application within six months, and application users were happier, too: rehoming the configurator before a final migration meant it could run that workload on open systems immediately. Most important, delivering a financial win early on built trust and provided the business justification to move to the next modernisation steps.

Super projects bring high risk

Despite examples like these showing the benefits of adopting an incremental, low-risk route to modernising mainframe applications, many organisations remain wedded to the old ways. A predilection for the ‘super project’ that aims to convert a legacy application portfolio from proprietary Cobol to cloud-ready Java in one go (for example, by refactoring or rewriting legacy code) risks failure. Some sources estimate that big technology initiatives, including digital transformation projects, fail at rates of 70%.

It’s understandable, given the criticality of mainframe applications to current business operations and future competitiveness, that business leaders want to get a full migration done and dusted. Leaders get the benefits of having cloud-native applications that can easily scale up and down, be paired with business intelligence or AI tools in the cloud. They see their digitally native competitors in Fintech or equivalent spaces doing this right now and reaping the benefits – and they want a piece of the action.

The C-Suite is focused on business strategy and operations and not on the intricacies of the legacy environment: the interdependencies among mainframe workloads, the ISV landscape, plus the data that is sitting on the mainframe. Cumulatively, these bring major challenges that may prove insurmountable if companies rigidly adhere to a pre-ordained plan. In the C-suite, a big, fat tick at the end of a 3-year project may be appealing; but waiting that long before being able to demonstrate value is super risky, too.

Transparency brings learning

A fixation on the destination and a blind faith in suppliers’ narrative – for instance, that refactoring can be achieved with the flick of a button – has caused blue chips to come unstuck. One large manufacturing company, attempting to recode DB2 applications to Java, encountered unforeseen challenges, including the architectural risk of data inconsistency across platforms. It was solved by deploying an extra data capture solution – but only at high additional cost.

Another shortcoming of the modernisation-in-one-go approach, often referred to as ‘big bang,’ is the lack of transparency around how the destination code is arrived at. When a supplier asks for your source code, and sends you the Java conversion by return, it’s the modern equivalent of the system administrator retiring with the organisation’s mainframe knowledge in his head. Organisations give extra credit to a modernisation partner with expertise both on mainframe and open-source environments, and also value highly end-to-end project planning and implementation experience and capabilities.

Organisations also need a modernisation partner that runs evidence-based evaluations of different modernisation options. For example, if evidence suggests that either transcoding or refactoring are the right approach for a particular situation, then we’ll consider how databases are structured, accessed and whether code-generating language can be handled by refactoring solutions. In the end, we’ll always champion the gradual, incremental approach, inspired by use cases of compliance, reduced costs and improved customer experience. We know gradual keeps teams motivated and upskilled, and shows the board early returns. 

Related articles.