CIO Insights: Legacy systems – love them or leave them?

It is likely most organisations have some kind of legacy systems that they rely on. They usually stick around because they contain important business processes and data. Introducing new technologies into the business that need to integrate with the legacy systems can be a nightmare, but replacing them could prove to be an even bigger nightmare.

In this fourth instalment of CIO Insights, we talk to three leading Australian technologists about whether or not to hold onto legacy systems for as long as possible, different approaches to modernising them, and how to go about making a business case for replacement.

Scenario: The current legacy systems in place do their job, but the CIO is concerned that it’s only a matter of time before support and the skills needed to maintain the systems will be near impossible to obtain. Also, the CIO is concerned that these systems might restrict the business’s ability to rapidly innovate in the future. However, it’s not exactly a no-brainer decision as the risk of failure and potential hidden costs associated with replacing business-critical legacy systems, as well as the time needed for testing and end user training, could end up hurting the business.

What would you do in this situation?

Alex Jones, CIO at Synergy

I’m actually in a similar situation, which I’m doing something about now, with our contact/telephony call centre system that’s about 15 years old. Finding replacement hardware for that can be quite challenging and a number of vendors that actually have people who can support it is diminishing. So what I’m doing in that case is running a very significant project to put a new system in.

In the context of ageing off-the-shelf systems – not custom-built legacy systems – because over time the organisation did not invest in keeping it up-to-date with the latest version, you get past a point where trying to get it to the latest version is effectively equivalent to just re-implementing it.

For example, with our core business SAP system, we did a major upgrade a year ago because we saw this problem was coming and it hasn’t come yet but we still had the opportunity to do something about it. And now, every three months we just apply the small fixes and small improvements. As long as we keep doing that, that problem won’t occur.

One thing you can do is look at cross-skilling within your team. You might just never have the time and money to replace every single legacy system, so cross-skilling is an option.

One of the things that I’ve been looking at recently, which I haven’t done yet but I’m considering, is outsourcing. Sometimes there are larger IT services vendors where their whole business is providing IT resources to support systems. One of the reasons you engage the vendors is because they have a broader skills base to draw upon, so you might be able to create a greater pool of potential support people. By having that agreement with you, the vendor might invest in maintaining that skill set within their staff.

I think the other thing that needs to be done in this situation is make sure the assessment of the risk is a realistic assessment because I think sometimes people can overblow the risk. The sky doesn’t necessarily fall just because something has gone out of support.

In my personal experience – not a general rule – I often hear a lot more concern about this risk than I actually see the risk being a problem. A lot of times I see people within IT trying to say that because you have gone past a supportable version that this is a reason why you have to invest in a whole new system. I don’t think that’s always true.

You can spend an awful lot of money upgrading something that will work to something that still works. But at what point is it working enough? I suppose I’m disclosing my age a bit here when I say I used to use Word 95, and I have to say Word 95 did just as good a job as Word 2013. And if you send a document from the current version to a person who is using Word 95, they can't even open it. So is it [of] any worth then? No.

I think that’s the point: There’s a lot that’s fit-for-purpose that goes out of support, and often a deliberate strategy pursued by the vendors is they want you to upgrade when in fact it is fit-for-purpose and will stay that way.

If you invest small amounts in maintaining, then you never have to do anything drastic and it just keeps going, versus if you leave it completely alone you eventually, one way or another, have to do something bigger. I think that day can be postponed longer than people think. But ultimately if you have got a system that just cannot be upgraded and not supported but you still need what the system does, then you will have to replace it.

Grahame Coles, executive director of digital government, Department of State Development and Business Innovation

When I was at the Department of Human Services, we had old Lotus Notes applications – most departments in Victoria have Lotus Notes apps that they are looking to migrate. Effectively what we did was cull most of them, and we got them down to around 20. The approach was to try to get rid of them as much as we could, come down to an absolutely set we couldn’t get rid of. Then, we put a business case together to try to get them swapped over.

One way is to take a piecemeal approach. Gradually modernising is the best way to go if you can. No-one likes to have a great, big migration plan; it’s better to do things almost as agile as you can. I think we are all adverse to big projects, big ‘go lives’.

If your core legacy system supports it, it’s also quite useful to have a different user interface on top. For example, iPad and Android applications can generally be a wrapper talking to an old legacy back-end. It’s quite good because you get a nice, new interface without having to do much work at the back-end.

However, if you have legacy applications that have been custom written or written completely internally (not a package), then it’s harder to put a wrap around them because they don’t typically have Web services or APIs that you can actually use in the wrapper layer.

When it comes to outsourcing this, if you have a legacy system and you are struggling to find resources to look after it, it makes sense to find a company that can do that. They might have a whole lot of customers using the same technology so they can create a pool of resources that you might not be able to do yourself.

You can also partner with consultancies or system integrators, so you can do a mixture of internal IT plus external consultancies for support. You can partner fully, partly, or not at all. And you can use partners as a pool of resources when you need to ramp up quickly for something.

Remember if you are going to modernise your systems, it’s best to use as little customisation as possible. Otherwise, it costs a lot to upgrade. You really need to work with the business to get their processes as standard as possible to minimise the need for customisation. With your human capital and financial systems, for example, you really want to try and not customise any of that. But with CRM I think you have to customise to some degree because businesses usually have some unique things that give them a competitive advantage that they would want their CRM to do.

Page Break

Simarjit, CIO at Xtralis

The scenario can be discovered in most organisations but most of us are challenged to increasingly ‘justify’ the need. Is it due to the ‘C’ word (cloud)?

Most of us stick on the path of putting a business case together for review and approval, but somehow not everyone seems to appreciate it. So should we consider taking a different approach, more from a business point of view?

Instead of just stating the obvious risks, highlighting hidden costs to the business, lack of skills, availability of resources, etc., it may make better sense to lay out different scenarios.

For example, instead of stating that ‘if we don’t invest now, here are the risks and possible impacts’, we could instead define various ‘what if’ scenarios.

• Scenario 1: ‘What if’ the decision is made.
• Scenario 2: ‘What if’ the decision is deferred. Say by six months, one year, two years, etc.
• Scenario 3: ‘What if’ if the decision is not made.

There is no doubt that we all aim for Scenario 1, but somehow the organisation seems to aim for Scenario 3 while it is forced to go for Scenario 2 at some stage.

In order to develop such a plan, there are several approaches one can take. A certain approach can work in one organisation, while a different one may work in another; there is no right or wrong approach. For those reporting into the finance function, it may help to associate the cost of such an impact. For those reporting to the CEO or into the board, it may make sense to know what the competition is doing and how a lack of decision would impact the business.

There is no hiding a fact that each of us has seen one or more approvals go through without even having a proper business case in place. And while you invest hours putting together a plan with associated risk/impact matrixes, in certain cases the senior executives seem to miss the plot. Why is that?

It may be due to a lack of visibility of your point of view on the top. It may be due to the perception that IT seems to overhype every requirement to seek funding. It may be due to the fact that the risk/impact you have associated [with a scenario] is not part of the organisation’s risk register.

While this may seem a lot of work for a common sense requirement, we need to remember Thomas A. Edison’s famous quote: He said in order to achieve anything worthwhile, there are three great essentials — hard work, tenacity and common sense.

You also may be in an organisation where it is willing to ‘risk it out’ and wait until the very last moment for making the decision. That is just acting ‘reactively’ rather than ‘proactively’, and the same goes for its market approach as well.

You can make a difference by being persistent. Remember Franklin D. Roosevelt said, “If [one method] fails, admit it frankly and try another. But above all, try something.”

Tim Thurman, CIO at ASX

Replacing legacy/end-of-life applications is always a challenge and more so an issue if they have been around for a long time and have a great track report. The appetite for change is very difficult – this is internal to the organisation but also external to your clients and vendors.

The objective when replacing legacy software is never recommend a one-for-one swap-out, you need to build a business case to support an enhanced service with better technology. But more importantly, always drive the business case towards enhancing the business experience for your customers with additional functionality – you need to make it a win-win journey.

We have this exact dilemma at the ASX. We have an awesome product which has been functioning for 24 years, extremely reliable and well engrained into our customer’s back-office applications. The net-net is it needs to be replaced for a number of reasons but the challenge is where to start. We’ve dedicated the first several months of the project to simply talk to our customers to understand their current and future needs. This is through technical forums where we invite our customers as well as vendors to participate.

One very clear message is the industry does not want a one-for-one replacement. So we are taking the opportunity to source a state-of-the-art global platform to enhance our service offering as well allow our customers to create efficiencies within their own businesses. This is the win-win scenario I’m looking for. The transition will be difficult and risky but when it’s all done, it's very rewarding.

Are you facing a particular challenge and need some advice? Contact Rebecca Merrett at rebecca_merrett@idg.com.au.

For more articles in the CIO Insights series, be sure to check out:
How to approach innovation
IT offshoring/outsourcing – how much is too much?
Dealing with shadow IT
What not to do when hiring talent