Skip links

How to Improve Legacy Systems

How to Improve Legacy Systems

What is a Legacy System?

Now, when we say ‘legacy system’, the first question is, “What really is a legacy system?” A big mistake we tend to make is assuming that a “legacy” system is 10, 15 or 25 years old.

But what if I told you there are legacy systems that are only 5-6 years old?

Consider BlackBerry. In 2012-2013, BlackBerry was the mainstay mobile device of the enterprise market. They had their own operating system and enterprise mobile device management suite.

But in the subsequent years, the likes of Apple, Google, Samsung, etc., started offering a range of features that people wanted, but Blackberry didn’t offer.

As a result, businesses adopted bring-your-own-device (BYOD) policies to respond to their employees’ use of personal iPhones and Android devices. Over time they began to phase-out Blackberry devices.

By 2016 or so, Blackberry was a “legacy” platform.

A “legacy” system isn’t necessarily “old”, it can also be quite recent.

Multiple factors can turn current systems into legacy systems, not just technology becoming outdated. Even a shift in end-user tastes and growing end-user expectations can send an application into legacy status.

Are You Struggling with a Legacy Software that Drags Down Your Competitiveness?

Get an Application Migration Assessment

The Operational Issues Behind Legacy Systems

Legacy systems cause various operational issues.

If your legacy system suffers from outdated technology, you struggle with fewer people in the market having the necessary skills to maintain the platform.

When you’re managing a legacy system that struggles with declining adoption of the platform – like Blackberry – it becomes costlier to maintain the system and earn a profit.

Let’s look at two approaches that address the risks of legacy systems: Replace or Modernize.

What Does it Mean to ‘Replace’ a Legacy System

Replacing an application involves finding and swapping your current system with a commercially available solution off the market. For example, moving from a homegrown time tracking solution to a cloud-based SaaS product.

Is replacing legacy systems your only option?

It depends on the number of staff you have and the scope or scale of your organization in relation to the application you’re looking to replace.

For example, let’s look at an insurance company.

They have fixed procedures used by in-house staff, as well as insurance agents in the field.

So, on the one hand, you have many people who are very comfortable with what they have, and while modernizing the entire system is beneficial, it requires a big learning curve for the staff.

On the other hand, you can’t necessarily change everything. Some of their rules and procedures must be maintained, so as a result, you may not be able to change the linked systems.

Modernizing Specific Parts versus Replacing the Whole Thing

So in that scenario above, replacing the whole system would not be a good idea.

What’s best is we look at each individual component one at a time and we modernize bit by bit.

We start working with one component, make the users comfortable with it, and then move on to another.

We keep doing this over and over again until a point where they can maintain existing internal policies with fully updated systems, or, transform operations to innovate new, more competitive processes and service models.

How Do You Identify What Needs to be Modernized?

Modernization should be tackled with an incremental approach.

1. Start with Infrastructure

Infrastructure incurs the highest costs for most companies, but it’s an area which has a high potential for optimization.

So as a business owner, you need to consult your software architects.

You need to have them identify areas that will not work in a modern technology stack and how you can leverage public cloud-hosted infrastructure and cloud-native technologies.

You should start looking at it from the infrastructure perspective. Once you have a complete understanding of your infrastructure needs, you can start looking at your resources.

2. Review Your Resources

Verify if you have enough of the right people.

If you don’t have the necessary skills to carry the project, you should first try to understand how quickly you can get those resources. It may not seem like a big issue, but it really is.

Let’s say architects decide that they want to use React or Angular. If you lack the in-house talent to use that software, you’ll need to incur added costs for the project.

This means that you have to invest a lot in terms of hiring, onboarding and equipping new teams with tools and technology.

So, identifying your current capacity is the next big step in order to modernize.

Read More About Modernization:

3. Identify Crucial Factors for Your Business

Next, you need to identify what areas are crucial to your business.

  • Is security a crucial factor in your business?
  • Is user experience a crucial factor in your business?
  • Are correctly following rules and regulations key for your business?
  • Is networking or production support crucial for your business?

You need to start looking at those crucial areas one by one and see the past history of what has been done before. Assess which areas you’re having more trouble with, and in which areas are you spending too much money and not getting enough revenue.

It’s not a very good idea to ask your own organization’s people to review your infrastructure.

Since they’re already accustomed to the existing system, they won’t think outside of the box.

It’s much better if you ask an external party to conduct this review. Look for someone with the capacity to look through and asses each individual system in relation to your business needs and resources.

For 15 years, Architech has helped its clients modernize their legacy systems. Contact us today to discuss how our team of veteran software engineers and business experts can execute your legacy modernization goals.

Murat Guvenc

Business Development Manager

Murat is a Business Development Manager at Architech and specializes in working with DevOps and cloud-native technologies, such as Kubernetes, PaaS (platform-as-a-service), private clouds and Microservices.

Cloud Native Insights