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.