Unsupported platforms

Legacy systems most likely run on poorly supported platforms that leave organisations vulnerable to security threats and compliance issues. When it comes to modernisation, there are two main categories of platform to consider:

• Runtime platforms
• Application platforms

Runtime platforms are bound to a specific programming language. The good news is that whether you’re using Java, .Net or even Cobol, upgrading to a newer version is generally not an issue. For example, recent licensing changes have seen seamless migrations from Oracle Java to open-source alternatives. These transitions were smoothed because the only changes needed, apart from those to the development pipeline, were for licensed parts of the original platform such as codecs.

To keep up with the cloud-native competition, more and more businesses are exploring the benefits of replatforming. Of course, migrating a monolithic Cobol system to the cloud won’t solve Cobol issues per se. But it will leverage cloud capabilities and make the system more attractive to potential developers. Another plus is the suite of support tools you get for logging, monitoring, accessibility, back-ups and other features.

Application platforms present a different set of challenges. Solutions might involve encapsulating with an API, rearchitecting material code or even rebuilding the system entirely. In some cases the platform will need to be upgraded before migrating to another language. Systems built on top of application platforms are tightly bound to the features these platforms offer. They’re also often locked into a cycle of suboptimal development practices.

Custom development

So how does a new interface work with an old platform? On the surface, there are a number of benefits a new platform brings. It significantly speeds up delivery and provides out-of-the-box functionalities like user management, single sign-on with popular providers, administration, theming and portal features. But what about all the features that aren’t part of the platform bundle? Can the platform be extended to include these? As shown in the following graphic, it certainly can when a system is linked to its original platform through a custom-development layer.

More features, please!

As a system grows, so does the demand for features. This is when the need for custom moduling kicks in. The goal is to introduce new features so they function within the new ecosystem. It’s all built on the principle of allowing the platform to exploit out-of-the-box features while adding custom functionalities on a graded basis. Upgrades come with their own problems. For application platforms that aren’t backward-compatible, upgrade costs can be of significant concern. An organisation might discover that upgrading a platform requires considerable investments in licensing or custom-platform rework to make the platform backward-compatible. And because replatforming is not an option, abandoning the platform can be just as costly. Fortunately, these situations can be resolved.

Scale as needed

Replacing components of the original system one step at a time leverages the best mix of benefit, impact and risk. In this way, new features are implemented with respect to the new architecture, leaving the original code accessible via a well-defined API. Through incremental modularisation and changes to structure, the interoperation of the system and custom platform becomes more synchronised over time.

Think twice before you replace

When frustration with a legacy system boils over, there’s a temptation to rip and replace. But trusting in a systematic and continuous modernisation strategy is more cost-effective in the long run. Learn more about Legacy Systems Modernisation.