The Executive’s Guide to Application Modernization Strategies

When a business can’t schedule appointments because its scheduling software dies, it is a cause for concern. Existing clients can’t come in. New leads can’t be converted to clients. The business loses a lot of money. It is a multi-thousand-dollar problem.

But when a business can’t suddenly process 500,000 incoming financial transactions because the software crashed and no one knows why, you know that it’s a multi-million dollar problem. Fortunately, there is a quick and cheap workaround for the first type of business. You can schedule appointments by hand. And then, take your time to figure out why the scheduling software isn’t working.

In the second scenario, the transactions are coming in, and there is no way to process them by hand. Every second that the software isn’t working means thousands of dollars lost. Potential future damages are incalculable.

In both cases, the problem is old software.

In both cases, the solution is to modernize it. But, in the second case, in the enterprise world, the modernization effort can take months and often years.

Let’s look at your options to modernize your enterprise software and how to tackle each one.

The Problem

Most enterprise companies run on old and often brittle software that can break anytime. Most of their internal and external business functions are supported by this software. Frequently, this software hasn’t been updated for many years, raising the possibility that the software’s functionality is out of date. For example, our scheduling app may not have a modern mobile UI, making it difficult for people to schedule appointments on their most frequently used computer, their phone. Older software often encounters performance problems because demands for the software have changed - think of the influx of online orders during the COVID lockdown. Each time it goes down, it costs these businesses hundreds of thousands.

The story of 500,000 transactions not being processed happened a few years ago to a very big financial institution. The majority of the public won’t know anything about this company. But it runs many of the financial transactions in North America.

The application that caused the problem was built in the early 2000s. It served a very specific function back then: checking if the account was valid. And it did it well.

As time passed, the people who built the application left or retired, and new hires had little understanding of what the application did, let alone how. But it worked. So, no one paid any attention. Because it worked so well, other system parts began to rely on its functionality. At its peak, it handled tens of millions of transactions per month.

Because so many other applications used this app, it became the bottleneck for all those other applications. When the account validation service slowed down, everything else slowed down. When the application crashed, everything else crashed.

One of the main reasons for these crashes was the application’s inability to handle large amounts of incoming transactions. The programming language version and the libraries it was built on weren’t designed for this scale. There was no way to easily upgrade it without rewriting the whole application.

Since this application was built, the developer community has devised numerous ways to solve this bottleneck issue. But, because the account verification app had been neglected for so long, it didn’t have those new capabilities. The cost of this one small piece of software going down was sky-high. Hundreds of thousands of cancelled transactions. Lost revenue for the business. Loss of client confidence and loss of trust by customers of this company’s clients.

Something needed to be done. But when leadership decided to address the problem, no one in the company knew how the software worked or how to improve it.

Ultimately, it took over a year and around $3M to update it, but it saved the business tens of millions in lost transaction fees.

The Harsh Reality of Old Software

The grim reality of enterprises is this. They are run on old and brittle software, and when it goes down, it costs these companies billions of dollars in lost revenue, operations maintenance and upkeep costs.

One study estimated that operating and maintaining just 10 of the US government’s legacy systems costs around $337 million annually. And there are hundreds of these systems in the government and thousands in the enterprise.

The Solution

The solution is simple. ChatGPT: “Modernize my software for me.”

The answer to everything seems to be using AI to fix it. Except that life isn’t that simple. Modernizing enterprise software is a complex undertaking that involves a lot more than just writing code:

• Process discovery
• User experience undertakings Software architecture
• Software design
• Software development
• Software testing and quality assurance
• User interface design
• Product management
• Business process engineering production deployment
• Change management
• Training and promotion communication
• Strategy

And the list goes on.

Often, modernizing software applications is like doing open heart surgery and trying to replace additional organs while the patient is still taking customer calls on Zoom. It is not an easy job, and the more you delay it, the more complicated it becomes.

Companies delay modernizing applications for many reasons. Some executives aren’t aware of how fragile and brittle their software is. Others don’t know how to start modernizing applications. The rest don’t have the resources, both in terms of people and finances.

If you don’t modernize, here’s what is going to happen:

• It will cost more later.
• Upkeep costs will rise.
• Business process knowledge will be lost.
• Your competitors will take your market share.
• The SMEs in your organization will retire or leave.
• When it goes down, it will cost more money to bring the application back up.
• You won’t be able to reuse existing components easily; technology won’t wait for you.
• No one will know how your applications work and, more importantly, why they work that way.

There are more consequences, but hopefully, these are enough to get you to start thinking about modernizing your applications sooner rather than later.

Software Modernization is 1 Part Writing Code, 99 Parts Fixing Process

I have been modernizing applications for the last 15 years. I’ve modernized small applications for medium-sized businesses and large enterprise applications with millions of users that help run the North American financial system.

Every modernization project has been different. Some were simple updates to existing software, and others required a change in operations strategy and the implementation of new business processes.

Contrary to what you might expect, technology often played a small part in these modernization efforts.

Each project’s success was due to research, planning and decisions that were made before we started. Success came down to what processes we implemented while modernizing legacy systems.

Projects I’ve led have saved businesses $100s of millions in efficiency and operational costs and billions of dollars in headaches and stress.

Here’s how I lead these modernization efforts.

The Four Ways To Modernize Your Application

Modernizing enterprise applications is a costly and often failing endeavour. To do it successfully, you must decide which method to use and navigate a flood of unexpected events that will derail your project.

A lot has been written about methods of modernizing software. Some say there are 5 modernization patterns, and it’s been known to go up to 7. I like to simplify it into four different approaches:

1. Replatform: Move the application to the cloud.
2. Reimagine: Build a brand new application.
3. Rebuild: Rebuild an existing application.
4. Replace: Buy an off-the-shelf solution.

Each approach has its upsides and downsides. Let’s break it down.

Replatform: Move the application to the cloud.

This is the quickest and the cheapest method of modernizing an existing application. But it also keeps your processes the way they were, potentially still costing your business time and money.

If your application is relatively new and has been deployed to an in-house server, you might benefit from moving the application to the cloud and setting up an automated integration and deployment pipeline to ensure any new updates to the software are smooth and quality-tested.

One of the main benefits of this approach, also known as “lift-and-shift,” is the speed with which you can do it.

If you use popular cloud platforms from Azure, Google, or Amazon, you will be working with well-structured platforms that provide all of the services you need to make your application work. You will just have to shift your code onto those platforms, and everything else should be handled for you.

The major downside of this approach is that it doesn’t solve the operational issues your business might be dealing with.

On the technology side, Replatforming creates integration headaches. In many cases, integrating the old application into the newest environment is like driving a unicycle on a highway. It might get you to where you are going, but it’ll be the most dangerous trip, and you will be breaking many laws.

On the business process side, software is designed to automate a business process. If the business process no longer fulfills its function, replatforming might make the application faster, but the existing problems will remain.

If your application doesn’t solve a particularly painful business problem or creates additional problems because of its design, the Replatform approach is not the right solution.

One of the other four options is often a better choice in these cases.

Things to Consider

Here are some things you need to consider when considering the Replatform approach.

• Which cloud provider should you choose? There are many options available for private and public cloud.
• Do you have the expertise to manage the application in the cloud? Even with managed cloud services, you need people who can set it up and ensure everything is running smoothly.
• Should you select a private cloud solution? The decision between public cloud or on-premises private cloud usually comes down to business requirements, regulations, and integration requirements.
• Where will the data for the application live? In most cases, if the app runs in the cloud, the data must also be in the cloud. And vice-versa for private cloud.
• Are there any regulatory requirements that you must comply with? What happens to the old application? Regulated industries like finance, pharma, and governments must follow stringent rules when deploying applications.
• What are the timelines for the project? Some applications need modernization work immediately because they cost the business millions of dollars. Others can wait.

Reimagine: Build a Brand New Application

Often called green-field development in software engineering, building a brand new application to replace an existing one can be an appealing approach.

The decision to do it comes from this simple fact: your business processes have evolved so much that the old software is no longer fulfilling its function. It has become more of a hindrance than an accelerator of work.

Let’s say you are running a large warehouse. For the past 15 years, you and your team have been using an inventory tracking and management system that was built in-house. It has worked well, but because it was written in an old programming language, it can no longer be updated.

In the meantime, the automation landscape in the warehousing industry has taken off. Many of the manual jobs can now be automated. Inventory tracking can be done with RFID tags, and robots can run the place independently.

In this scenario, you can reimagine everything about the warehouse and its operations. You still have to build a custom software solution, but you can create new processes, automate work, and redesign this part of the business.

Building a brand-new application has several benefits:

• You can match the software to your exact business needs
• You can start using new technologies
• You have a bigger hiring pool for engineering talent because you’ll usually modernize to more widely used technologies.

But the downsides are also significant:

• New applications take a long time to build, often at least a year if not more.
• New applications require hiring new engineering talent, especially if you’ve been using long, out-of-date technologies.
• New applications require additional infrastructure resources
• New applications may still require integration with existing systems

The upsides and downsides of reimagining the application will depend on your situation, context, resources, budget, and other important factors. This may be the right approach for you if you can take advantage of the new technology and develop more efficient business processes.

Things to Consider

Here are some things you need to consider when building a new application to replace the old one fully.

• The overall cost of the project.
• Who needs to be involved on the business side?
• If you have a team capable of building new software.
• Time commitment from the existing team.
• Need to hire additional software engineers, product managers, designers, and ops engineers.
• Who are your SMEs (Subject Matter Experts)? You will need a business expert to help you re-imagine how the business processes might look.
• How can you make a minimum viable product to explore new ideas?
• Who will make product decisions?
• Understand what processes negatively impact your business and design the changes needed to improve them.
• Training required for the new product.
• Where will the new application be deployed?

Rebuild: Rebuild an Existing Application.

When your business processes remain largely unchanged, and your existing software continues to meet most of your requirements, rebuilding the application is often the preferred approach. Mission-critical applications typically fall into this category; they form the foundation of an organization’s business model and don’t require extensive process updates. Because they are essential, they need to be rebuilt to minimize impact on business operations.

For example, you have an application that manages railroad traffic. It controls traffic lights, switches rails, communicates traffic conditions to trains on all its lines, and relays this information back to the control room.

The application has been running your rail system for over a decade, and you’ve noticed that the traffic light controls have been giving you more problems over the past year or so.

You know you need to replace the whole system, but it will take a long time. But the downtime you experience because of current problems costs you a lot.

The solution is to rebuild the existing application in sections. This way, you can keep your operations going and work on replacing the most troublesome part of the application. Building it in sections will also prevent your team from over-committing and being unable to deliver because of budget constraints.

First, you’d build the traffic lights management system. It would have one job, ensuring that traffic is moving properly. Once it was ready, you would redirect that functionality from the old application to the new one. Then, you would continue to build the next slice of the application and so forth.

In technical terms, this approach is called The Strangler Fig Pattern, named after the strangler fig tree. Like the fig tree strangling its host tree, your new application strangles your old application bit by bit with this pattern.

The benefits of this approach are:

• Build one piece of application at a time.
• You can validate each piece before building the new one.
• It may create a smaller application because you can throw out parts that are no longer used by the business.
• It could take less time to build.

The downsides are:

• You have to keep the old application running at the same time.
• You need to sync data between the old application and the new one.
• You will likely have to build integration points between the old and new applications.
• Too many business processes are running side by side. This happens when the new section of the application you are building requires a change in business process. However, you still use other parts of the application and follow older, established practices.

The decision to build the application side-by-side is down to the business needs. If the mission-critical application needs a small piece replaced because it has been failing often, then this could be how to build the application.

Things to Consider

Here are the things you need to think about when building a side-by-side application:

• The cost of the project
• Who needs to be involved on the business side
• If you have a team capable of building new software
• Time commitment from the existing team
• Need to hire additional software engineers, product managers, designers, and ops engineers.
• Who are your SMEs (Subject Matter Experts)? You will need a business expert to help you re-imagine how the business processes might look.
• Building a Minimum Viable Product to prove that the new application will create enough value for the business to justify the bigger outlay.
• Who will make product decisions?
• Understand what processes negatively impact your business and design the changes needed to improve them.
• Training required for the new product
• Where will the new application be deployed
• How will you integrate with the existing application
• Will you have the resources to run two applications side by side
• How will you sync the data between applications?

Replace: Buy an Off-The-Shelf Solution.

Sometimes, the application you are currently using can be replaced with a customizable, commercial off-the-shelf solution (COTS). More and more, these are SaaS applications.

For example, If you have a custom-built inventory management system or customer relation management platform, you can often modernize it by switching to customizable Enterprise Resource Planning software.

This solution is often chosen by large enterprises that have standardized their operations and follow generally accepted frameworks for doing work.

For example, large businesses follow a GAAP (Generally Accepted Accounting Principles) accounting system. In this case, it makes sense for these companies to buy customizable ERP software from someone like SAP and customize it to fit their needs. SAP makes its accounting software highly customizable for this reason.

The decision to use customizable ERP software depends on what functionality you are trying to replace, the cost of the software, and how easily it could be integrated into your existing ecosystem.

ERP software isn’t the only customizable enterprise system you can use to replace aging applications.

Depending on your business processes, you can get away with simple workflow management tools like Asana, Basecamp, or a shared spreadsheet. It would require some policy changes and a few business process adjustments. In these cases, the application you’re replacing was originally written because software to run common business processes like collaborative, multi-site project management did not yet exist.

What are the benefits of going with the customizable, off-the-shelf option?

• You don’t have to build it.
• It can be customized to fit your business needs.
• Support and consulting are readily available.
• Usually, it’s quick to get started.

The downsides are:

• It may be just as expensive as building side-by-side.
• Long-term vendor lock-in.
• Customizations lock you into the software’s preferred way of doing things, limiting your ability to change once your business processes change. Customization limits your business processes.
• Integrations with other systems will require software development work.

If the off-the-shelf solution solves most of your business needs with little to no customization, then this route might be the preferred one for you.

Things to Consider

Here are some things you need to consider when buying and integrating a customizable off-the-shelf application.

• Does the application perform most functions out of the box? What is the cost of installation?
• What is the cost of integration?
• What is the cost of support?
• Who will do the integration?
• What happens when integrations stop working?
• What is the cost of scaling the solution?
• Where will you host the solution?
• What happens if the vendor goes out of business?
• Can it easily integrate with your systems?
• How difficult is it to customize the system?
• What training and change management is required?
• What other risks are there with committing to one vendor?

Conclusion

All businesses now are technology companies, whether we like it or not. Technology has gone from being a butler in the service of business needs to being a partner in business operations and growth.

Legacy applications can break companies and cost tens of millions of dollars. The choice is yours.

You can be part of the many and spend millions of dollars every year just keeping your lights on, or you can spend a fraction of that money and either make, refurbish, or buy new lights for your business.