Legacy systems: should they stay or should they go?

A legacy system overhaul is not for the faint of heart, writes Bhanu Singh, SVP of Product Development and Operations at OpsRamp.

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.  The survey that our company conducted in October has showed that technology spending hasn’t taken a terrible hit: in fact, 60% of IT leaders report that they have either significantly or moderately increased their IT budgets in the last six months. Other research from 2020 has mirrored those findings.

Yet there are significant challenges: three top ones reported in the OpsRamp fall 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 reprioritisation 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 are a burden when the UI and the UX is starting to look dated, they are slow or difficult to upgrade and integrate with other applications and costly to maintain.  Many legacy systems were built for on-premise 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 organisations 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 an onerous mission to replace;
• Long-standing 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 is currently meeting your business need, it’s important to understand where the competition is going, what your customers are asking for and ensure that you’ve got a future-proof strategy. Consider the Slacks of the world, 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.

If you take IT operations, the space in which our company sells, if the customer is receiving less IT alerts due to filtering and correlation capabilities, that’s a good thing.  But the greater value is: does the software proactively manage those alerts, filtering out the high-priority items to the right person and suggesting 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 and if 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 that they needed to go to the cloud. The knowledge of 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 where not only did companies not achieve the savings they expected but the environment became even more expensive to support than their on-premise infrastructure.
• New skills. In lockstep with the gap in strategic understanding of new technologies is the fact that it’s hard 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 optimisation and cloud-native development.
• Cultural changes. People don’t like change, especially if they’re not upset with the status quo.  IT leaders are improving here, but there’s still ample work in helping convey the reason for change, benefits and in designing a frictionless path to adoption.

The 3-step plan to modernisation

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 which doesn’t commit the organisation to a gargantuan, tangled overhaul.  Make sure you pick the right 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 socialise the outcomes across the organisation and explain how you did it.
2. Make the leaders your champions. If you are 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.  Whom on the executive team can really create some 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 whom 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 like 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 organisation is ready to take on transformational change or if an incremental change– such as customisation 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.