Tech leaders are often faced with a difficult decision on what to do with older applications and platforms. These applications might run on older hardware or use development tools and languages that are no longer common. Perhaps they’re from a vendor that’s no longer in business or based on custom code that was developed by a team who all retired or left the company years ago.
The obvious option is to replace these platforms. However, as anyone who’s gone through a selection, implementation, and transition process can attest, that’s often harder (and more expensive) than it sounds. There’s the relatively straightforward cost of acquiring and implementing the new application and associated hardware, but also other less obvious costs:
- Migrating custom functionality. Most older systems are filled with years of unique tweaks and customizations, so you’ll need to either accommodate these customizations on the new platform or identify alternatives.
- Integrations. The older the system, the more likely it will have interfaces and integrations with dozens of other platforms. An enterprise accounting system might even have hundreds of interfaces that range from real-time transactional interfaces to overnight batches. These must be identified and duplicated in your new application, or you’ll need to create a “translation layer” to connect the new system.
- Data migration. Data in the old systems must be migrated in some form or fashion. The easiest method is to leave the old system in place in a “read-only” mode, allowing users to reference data but not update transactions. While easy, it’s the least user-friendly approach and requires ongoing support and maintenance of the old system.
These complexities can double (or more) the cost of implementing a replacement system. During your analysis, it’s worth considering whether the old application can be updated to extend its useful life or at least prepare for eventual replacement through some intelligent technical choices.
Shift to Services
One way to breathe new life into old applications is to shift them to a service-based approach. This technology architecture breaks monolithic systems into discrete services and provides an API to communicate with other services. For example, you might have an order status service that accepts a customer order number and retrieves the order date, status, tracking information, and line items from the order.
Since there’s a standard API for retrieving order status, it doesn’t matter if a 30-year-old COBOL application contains the order information or if it’s a modern cloud application.
By transitioning key applications into services, you can eventually update the applications that deliver each service without affecting other applications. In effect, you’ve created a common approach for exchanging data that allows you to modify single components without affecting other components.
This transition can be costly and complex during the initial implementation, but API management applications like MuleSoft and Boomi can speed deployment. You can also build services slowly, starting with a limited subset and gradually adding more as you update and modify your tech platforms.
Modernize the UX
The technology equivalent of a fresh coat of paint and some landscaping to improve an older house’s curb appeal can also be applied to older applications. In many cases, improving an application’s user interface and experience can dramatically improve end-user satisfaction, which might be what’s driving calls to replace the application.
For example, convoluted time and expense applications based on enterprise accounting software like Oracle or SAP are the banes of many users’ weekly routines. However, a well-designed mobile application that’s easy to use is far less costly than replacing the accounting package yet can dramatically increase user satisfaction.
A modern front end allows for minimal recreation of complex business logic and maintains all the downstream interfaces, customizations, and complex processes associated with the old application but breathes new life into the application for the end user.
With the prevalence of rapid front-end development tools, it’s easier than ever to create modern interfaces for older systems.
When considering this approach, focus on discrete tasks rather than attempting to create “pretty screens” that duplicate each screen in the older application. For example, order entry in most enterprise software might comprise several screens and hundreds of potential fields. If your company only uses a subset, design your front end to only show those fields and consolidate them to a single screen. Power users and administrators can access the full system, but providing helpful interfaces designed only to show typical users what they need can make them more effective in their jobs and increase satisfaction with the system.
Lift and Shift
For many older applications, the performance and cost of maintaining the underlying hardware can be the primary driver for replacing the system. In the case of older mainframe-based applications, upgrades can be extremely expensive and perhaps of limited benefit if the application is ultimately slated for replacement.
One of the great benefits of cloud computing is that you can move these workloads to a cloud provider, purchase computing capacity as needed, and essentially let your cloud provider worry about maintaining and upgrading hardware.
A further benefit of cloud migration is that many providers will offer assistance with the so-called “lift and shift” operation to migrate your application to their platform. This is not an act of benevolence by any means. Ultimately, migrating your application will result in computing fees on their platform, but these fees might be significantly lower than supporting older hardware for the foreseeable future.
A cloud migration may also prepare you for transitioning to a service-based architecture, as the cloud can be a consolidated platform for communicating with internal and other external applications and services.
While it might be tempting to immediately choose replacement when faced with disposing of an older system, a combination of approaches might allow that costly decision to be deferred and resources deployed toward a more pressing priority.