Summary: Many companies around the globe still run on legacy enterprise applications and systems. They may understand the value of modernization, but view it as a costly/risky project. In this article, we explore a few best practices to follow that will reduce the risk and expense of application modernization.
Legacy application modernization is a common, yet tricky topic. Many businesses across the globe still run their operations on software created 20-30 years ago. These applications create a variety of problems. For instance, they:
– Tie up your budget: Legacy applications are more expensive to maintain, often tying up 70% of an IT budget.
– Waste your time: Over time, legacy applications become more complex. Why? Every customization or change adds another layer of complexity to the system. As these changes build up, maintaining the application becomes more time-consuming.
– Lock you down: Relying on legacy applications often locks you into specific technology. You’ll have to avoid some new technologies because they won’t work with your legacy systems.
If legacy software creates these issues, why doesn’t everyone modernize their applications? It usually boils down to one of two reasons:
1. They’re locked down: Oftentimes, past customizations have locked the business into a specific software or version. Replacing the system comes with considerable cost and risk.
2. It’s too costly/risky: Even if they’re not locked into the legacy system, replacing mission-critical applications is viewed as a huge expense/risk. Executives worry that if something goes wrong, it could harm the business.
The good news: When you follow a few legacy modernization best practices, you dramatically reduce the risk and cost. Today, let’s focus on a few best practices to follow in your modernization efforts:
Learn everything about your legacy system
What do I mean by “everything?” You must understand how it works, how it was built, how it connects to other systems, who uses it, why they use it, and how the underlying logic operates.
“Understand the purpose of the legacy software, what language was it written in, what is the logic behind the lines of code (procedural or object-oriented, mixed), even though it seems to be no logic at first,’ says Dr. Elena Zhebel, Founder of EZNumeric. “This is the most interactive part and possibly the most important and time-consuming one.”
Most importantly, understand what still works and what doesn’t. As explained in the following points, modernization doesn’t mean you must toss everything out and start over. Some aspects can be salvaged.
One more point I’d like to make in this section: When learning about your legacy systems, separate business processes from software. Some companies start a modernization project when the biggest issues stem from their inefficient business processes. Good software will not fix bad processes.
Outline your business requirements and outcomes
In any big project, it’s easy to get sidetracked and lose sight of your end goal. It’s also easy to get frustrated with legacy systems and want to throw everything out and start over. That’s why defining your goals and requirements are so important.
What’s the driving force behind your need for modernization? Are your current systems holding you back? Do they lack the features that you need? Are they costly or time-consuming to maintain? As explained below, approaching modernization from this angle will help you avoid unneccessary work.
“One best practice that should be included in every legacy modernization project, is to approach the modernization strategically, always keep the business requirements and desired outcomes in line,” says Colton DeVos, Marketing and Communications Specialist at Resolute Technology Solutions Inc. “It can be easy to point out all the flaws in your outdated legacy app and want to move to an entirely new platform – but the work involved can be time-consuming, complex, and actually outweigh the benefits gained by moving to a new system.”
Decide if you need modernization or new features
In most cases, you’ll discover that you don’t need to start from scratch. I’ve found that most legacy applications need the “extend and surround” approach. This approach involves gradually surrounding old applications with new and modern applications and features.
Why is this approach so successful? It lets you modernize different parts of your systems gradually, as the need arises. For example, if you need to bring your order entry applications to the web, you can do so without touching other aspects of your system. After that project is complete, you can focus on other areas to modernize.
“If you’re looking to modernize your legacy app to gain a key capability, see what upgrades you can make while maintaining the existing architecture,” says DeVos. “Consider upgrades or new features such as self-service portals and web / mobile front-ends that enhance customer experience, enable better data mining, and analytics gathering while still feeding into the legacy database. Depending on your app, you can often integrate a third-party tool or build a custom interface to feed into your legacy platform.”
Decouple components and approach the project by function
Modernization is an overwhelming job if you approach it from a “big bang” standpoint. Trying to do everything at once is not only overwhelming, it’s dangerous. It can easily slow the business to a halt if there are any problems.
The better solution: As mentioned above, it’s a far simpler project if you approach it from an “extend and surround” standpoint. It turns modernization into a manageable project that you can tackle at your own pace.
The key to this method: Separate the project by function. Don’t look at your legacy systems as a whole. Rather, break it up into smaller chunks that you can tackle independently of each other.
“The most important factor when transforming legacy applications is to try and decouple components into very simple functions and allow these functions to operate independently,” says James Carnie, Co-founder and CTO at Mobilise Cloud. “This allows you to scale these individual components based on throughput requirements and also the ability to work on them almost within isolation without affecting to stability of the whole application.”
Think long-term when choosing architecture and tools
Business applications are the same way.
If you’re building/buying new business apps to replace your legacy systems, or buying software to modernize your business apps, be careful. It’s easy to fall in love with the interface and features without paying any attention to what really matters: The architecture.
Now, I know that application architecture is one of the single most important, yet boring topics you’ll ever run across. You’re not going to make too many friends at a party talking about technology stacks, open frameworks, or any other architecture-related themes.
Yet, architecture is critical to any modernization project. The architecture determines how well an application integrates with other systems. It’s crucial to an application’s security. It determines an application’s scalability. Ultimately, it can make or break a modernization project.
From a practical standpoint, what does this mean? If you’re purchasing software to replace your legacy systems or purchasing a development tool to create new applications, look at the architecture. What is it built on? Will it lock you down? Does it restrict you in any way?
I could go on, but I think you get the point. While not a ‘fun’ topic, architecture is critically important to your modernization project’s success.
Summary
These are just a few modernization best practices to follow, but the list could be much longer. Would you add anything to this list? Feel free to comment below!