Legacy Systems: Should They Stay or Should They Go?

Digital transformation requires new technologies. But does that mean legacy systems should be replaced?

Survey after survey has shown that IT and business leaders have had to drastically rethink priorities, strategies and spending in the wake of the global pandemic. A survey our company conducted last October showed that technology spending hasn’t taken a terrible hit—in fact, 60% of IT leaders reported they had either significantly or moderately increased their IT budgets in the last six months. Other research from 2020 mirrors those findings.

Yet, there are significant challenges. Three top ones reported in the OpsRamp survey include business and IT alignment, available technology solutions and economic uncertainty. Executives want to move forward, yet they need to be cautious with budgets and develop strategies that can flex with the unpredictability of 2021.

And this is how we arrive at the topic of legacy systems. As part of the reprioritization effort, IT leaders are wise to take a hard look at their technology portfolio and determine which systems should go and which should stay—factoring in economics, business needs, customer demands and change management requirements. Progressive IT leaders know that if they don’t adopt the right technology at the right time, continued business success (and even survival) is at risk.

Defining Legacy Systems

We tend to associate a legacy system with a technology that’s been around a long time, yet it could also be a three-year-old system. Legacy systems can be a burden when the UI and the UX look dated, are slow or difficult to upgrade and integrate with other applications, and costly to maintain. Many legacy systems were built for on-premises environments and don’t migrate easily to the cloud. Finally, because some systems are built on languages and technologies that are 10 to 20 years old, IT organizations struggle to find people with the requisite skills to maintain them. These are all red flags.

On the other hand, there are valid reasons why enterprises maintain legacy systems:

  • The technology technically isn’t broken and satisfies a core business process, industry requirement or customer need.
  • The system integrates with many other applications and core processes, making it difficult to replace.
  • Longstanding vendor relationships make it politically or culturally challenging to abandon.
  • Influential stakeholders love it, despite any negative impact on customers and revenues.

How to Evaluate a Change

Even if a system still currently meets your business need, it’s important to understand what your competition is doing and what your customers are asking for to ensure you’ve got a future-proof strategy. Consider Slack, Amazon, Google and Netflix: These innovators have redefined what experiences software can provide and thereby have changed expectations for all users regardless of the sector.

In IT operations, if a customer is receiving fewer IT alerts due to filtering and correlation capabilities, that’s a good thing. But does the software proactively manage those alerts, filtering out the high-priority items to the right person and suggesting the best next steps for a quick resolution before users are affected?  From the executive and business view, you need to demonstrate efficiencies and cost savings from moving to a new solution as well as revenue-generating impacts.

Mitigating Snafus With Legacy System Replacements

When you decide it’s time to make the big move and replace a major system, consider the top factors that can ruin these projects or needlessly delay the time to value:

  • Gaps in knowledge and mindset. Look at what happened when every CIO got a mandate from the CEO to move operations to the cloud. Understanding how the cloud works and how to manage cloud-based assets was a struggle, so most early cloud migrations were simply lift-and-shift. That led to a common scenario in which not only did companies not achieve the savings they expected, but also the environment became even more expensive to support than their on-premises infrastructure.
  • New skills. In lockstep with the gap in strategic understanding of new technologies is the fact that it’s difficult to acquire or build the associated new skills fast enough to keep pace with changes in the market. This is why still today, more than 10 years after the advent of public cloud, there are significant talent gaps in the areas of cloud architecture, cloud optimization and cloud-native development.
  • Cultural changes. People don’t like change, especially if they’re not unhappy with the status quo. IT leaders are improving here, but there’s still ample work in helping convey the reason for change and the benefits to designing a frictionless path to adoption.

The 3-step Plan to Modernization

There’s nothing especially new about how to avoid a marred enterprise software implementation, except for the fact that tolerance levels are at an all-time low. Executives don’t want to see one-year rollouts and two-year time-to-value cycles anymore. Here’s how to simplify and speed up the benefits when moving to new platforms:

  1. Start with a small, powerful punch. You can gain momentum with a small project that doesn’t commit the organization to a gargantuan, tangled overhaul. Pick a project that’s not going to stress out your team and has a specific, predictable ROI. Truth is, people love innovation and want to be part of the “next new thing” as long as it doesn’t require too much pain all at once. Make sure to socialize the outcomes across the organization and explain how you did it.
  2. Make the leaders your champions. If your executive team doesn’t feel motivated to promote a new system internally, you might want to investigate whether it’s the right solution. Be sure to get that buy-in before you sign any vendor contract. Communication style matters. Who on the executive team can really create excitement around the future and effectively demonstrate the need for change? You want a salesperson personality for this job.
  3. Foster an evangelist committee. In the trenches, you also need a team of people who understand how to use the new solution and are eager to share their tips. I’ve seen leaders take on a full internal campaign prior to a new system being launched, from rebranding and relabeling an enterprise software package, developing an internal PR strategy around it and creating really effective tools such as short videos to help users get up to speed.

Balancing Continual Innovation and Lower Complexity

A legacy system overhaul is not for the faint of heart. You must carefully consider whether your organization is ready to take on transformational change or if an incremental change, such as customization or a new integration to your existing platform, is enough for now. But if incremental change is just going to help you survive another day, it can make the necessary change you really need much more painful later on.

Content By DevOps.com

Leave a Reply

Your email address will not be published. Required fields are marked *