In an era where digital transformation is both a necessity and a challenge, the topic of legacy systems continues to dominate strategic conversations within financial services businesses.
During a recent panel discussion featured at our Future of Insurance 2025 event, panellists offered a frank exploration of what legacy truly means for today’s financial services businesses, and how their organisations are navigating the complex intersection of outdated infrastructure, emerging technologies, and evolving customer expectations.
This session brings together three insurance industry leaders – Nigel Hawtin, GM of Transformation, Business at QBE, Harpreet Dhillon, GM of Enterprise Architecture and Technology at industry super fund Rest, and Lisa Zhu, GM of Technology at insurtech Open – each offering a unique perspective shaped by the nature and scale of their organisations.
From deeply entrenched legacy environments of traditional players to the nimble architectures of insurtechs, our featured panellists delved into the practical and cultural barriers to change, the trade-offs of transformation, and what it truly takes to future-proof technology in a dynamic marketplace.
Moderated by Luke Hannon.
Hannon (Mod): Looking at legacy systems but also the consideration of budget constraints, is there anything that keeps you up at night?
Hawtin (QBE): I think they’re completely tied. The cost of replacing a legacy system is really high. They’ve been sweated to death… with CIOs having kicked the can down the road, we’re now at that inflection point. But you have to make space for it in the budget to replace the legacy platform, and if you don’t, you can’t change as quickly as you need to.
Dhillon (Rest): We’re in superannuation, not directly in insurance, and we have quite a distributed ecosystem relying on a number of different partners. Our greatest challenge is therefore data silos and the integration issues – bringing that whole ecosystem together from different partners, getting the data together and those insights on our members that we need. In saying that, however, yes, legacy is always in the picture.
Zhu (Open): For those who don’t know us, we [Open] are an insurtech. We had the privilege of starting fully in the cloud rather than having to work with a legacy on-premise system or somewhere in between.
Speaking to one of our technology leaders earlier, we discussed this idea of legacy, that sometimes you’d write a line of code, release it tomorrow, and you’d already consider it legacy. So, how you define legacy is quite interesting in that regard. For us, it’s more about the question of why legacy is causing a problem. Is it really an enablement hindrance for your business?
In terms of budget, in the start-up/scale-up universe, there’s always a question of how we are spending that money. Is this project getting the best return on investment? And how do we manage that trade-off, in terms of: Is this thing really worthy of us tackling or should we spend that money opening up the funnel and bringing in new customers and bringing capabilities?
Basically, I’m going to give the typical engineering answer: it depends.
Hannon (Mod): So then, what causes such problems with legacy? Or is this question, in your case Lisa [Zhu], more applicable to organisations with a deeper heritage?
Zhu (Open): It really depends on what is important for the organisation. I’ve definitely worked in businesses where we talk about the idea of, ‘Let’s not touch the legacy!’. There is a fear that, if I touch this, change that or do a transformation on top of it, I may be about to bring the whole house down. So, what is the risk that we’re managing?
Hannon (Mod): Do we think that legacy is taking the lion’s share of attention in our organisations when it comes to our change programs?
Hawtin (QBE): Certainly for us right now it is. We recognise that it is really hard to change on a legacy stack, and we’re being asked to change at a faster rate of knots, to react faster; with a legacy platform, it’s really hard to push change through in a way that is nimble – and I wouldn’t use the word ‘agile’.
You need to have a nimble technology stack these days, and it’s really important that your architecture is able to swap out best-in-class technologies as they change; legacy makes it really difficult to have the integrations that work seamlessly.
So you can either replace it or just keep it as a system of record, but you have to do something that allows you to be able to modernise faster than you are or that your legacy allows you to do.
Hannon (Mod): Harpreet, I know you do many integrations with Rest. So I suspect the nimble stack that Nigel [Hawtin] mentioned, having that ability to swap out and change quickly and seamlessly, resonates with you.
Dhillon (Rest): Legacy really inhibits those quantum leaps forward, those transformational technologies like AI, that digital automation readiness, that big data readiness.
It’s really a competitive disadvantage if you’re harbouring legacy.
You may not actually realise that now, but when the transformation hits or the disruption hits, you’ve got so much weight behind actually being able to transform.
Hannon (Mod): Now this may be difficult for some of you, but let’s talk frequency of change. What does it look like currently in your organisation? And what do you think it needs to look like in terms of the ability to iterate and change these systems?
Dhillon (Rest): It’s really that idea of, how long is a piece of string? You could spend millions and millions of dollars trying to go for multiple releases in a single day or features on a platform. But, again, it comes back to the question of ROI. What are we actually trying to achieve? What’s our product stack? What is sensible?
It’s really important to have that ability to deliver change quickly – so your CI/CD [Continuous Integration/Continuous Delivery] pipelines, your actual deployment infrastructure, should allow you to move quickly – but not necessarily that you need to go to market with new features every week. There’s a real trade-off, because the amount of money and organisational focus and intent to get to that point is significant.
At Rest, we’ve taken more of a pragmatic approach. It depends on what application we’re talking about, what channel we’re talking about. Our mobile app is our most significant channel; we’ve got one million members on our mobile app, and it’s our most engaged channel for our superannuation members. As such, we’ve really prioritised our investment in releasing and our ability to move quickly into that channel.
Hawtin (QBE): I tend to agree. I don’t think we need to release as often as, say, a consumer software company does.
Insurance tends to move relatively slowly, so there’s no point in investing so much in the aim to release on demand.
That said, it’s really important to have that ability to put things into production and to test things. And if your releases are hampered by six-week test cycles, you’re deterred from testing anything with your customers, either through a dark launch or A/B testing. While it’s really important to have the ability to release perhaps more frequently than we do, it’s also fit for purpose for what we’re trying to achieve.
And if you’re trying to achieve market testing or consumer testing, you need to build that in to your release cycles, which again, is something that makes legacy so difficult, especially when it’s all tied together; you’re almost having to do end to end testing every time you want to make a small change. And again, it comes back to your architecture.
Zhu (Open): We currently release once a week. And I’m quite amazed that neither of my counterparts here mentioned a specific number of how frequently you release. Well played.
Hawtin (QBE): [Laughs] We have a six-week test cycle before release.
Zhu (Open): I come from a universe where we can release multiple times a day. When I joined the business, we thought about that, and it doesn’t actually make sense for what we need to do, nor for the quality of the product build that we want to accomplish for our customers. This is especially so in a regulated industry like insurance, where there are a lot of dates and checks that we need to sign off on – for instance, the nuance of wording, how we term certain things – is so critical to the overall experience and to compliance that we don’t really want to rush through that process.
Right now, for us, a once a week [release cycle] is beautiful.
In the long run, would we want to do multiple daily releases so that we can perform different experiments and quickly integrate with potential partners and new channels? One hundred per cent! And that’s where we want to work towards.
But that’s one of the beauties about starting at an insurtech: we don’t have this large legacy system that we have to deal with, and we do have some of that dynamism from new technologies that we can adopt as well.
Hannon (Mod): Moving onto partnerships now. Nigel [Hawtin], let’s explore the broader insurance value chain and how these relationships are changing, because it’s no longer just QBE on its own, there are partners, different integrations – not just from a tech perspective, but also from a frontline perspective.
Hawtin (QBE): This is huge. If you look at it from a sales and service perspective, especially in the intermediated space, which we’re a large insurer in, it used to be a much more personal relationship base, with underwriters using the phone solely to do business. Now, the relationship needs to be at both that level, but also the technology level.
And talking about release cycles, if you’re not up to speed and can’t push through the changes that your partners – who put a lot of GWP [gross written premium] through you – want or expect, ultimately you start breaking the ecosystem. So, the relationship there has had to evolve.
In terms of the claims supply chain, that really is the moment of truth. This is the point in time where your customer experiences someone turning up to their house, looking at their car or looking after their injury; we’re expecting someone who is traditionally a builder or mechanic to also be tech-savvy. There are obviously platforms that help here, but the supply chain platforms then need to be integrated, so you need to be able to have the technology relationship as well as the personal relationship.
Even from a tech stack perspective, it’s changed a lot. We probably used to rely on one or two vendors to do most of what we wanted.
Now, we actually should expect, and our partners should expect, for us to be able to cheat on them and say, ‘Look, we want to bring this in, and you need to be able to facilitate that integration, and probably have it already set up’.
Dhillon (Rest): At Rest, we value our partners a lot. We have quite a distributed ecosystem of partners and, traditionally, we’ve done a lot of outsourcing provided by partners. We were initially just a superannuation fund with a head office; all the actual operations happened with our partners. Over time, we are starting to insource more, but we’re also very deliberate about what we use our partners for.
We certainly see in the superannuation and insurance space, key partners like TAL continue to play a very, very significant role, with the scale and the size and the economies available and the expertise some of our partners bring, it doesn’t really make sense for us to internalise. That will continue.
What’s really interesting is the partnership between our partners as well as the partnership between corporate entities. For example, Rest and AustralianSuper are collaborating on an initiative, along with TAL and UFG (our strategic partners for both of our organisations), to build some common technology layers and common technology solutions that benefit both organisations; this is in a space where we’re not competing with each other. Through this partnership, we’re really trying to bring the cost down for our members in terms of operational efficiencies and back-end operations.
I think the industry should look at opportunities like that, where we’re not competing on every aspect and where there are opportunities for us to leverage and scale partnerships with partners who are really good at certain things.
Let’s create that ecosystem where you can build common foundations and then compete on areas of differentiation.
Hannon (Mod): I think super in general fascinating industry in that your primary objective is the custodian of super. There’s a real balance that you need to strike between efficiency and investment as well.
Dhillon (Rest): And there’s a big focus on superannuation funds, especially industry, member-owned super funds like Rest, in making sure that you’re spending the money in the interest of members. We exist only to make members money and invest in our corporate entity with a focus on making profits. It’s therefore really important for us to be prudent and very smart in how we use our ecosystems and resources to ultimately deliver value for the member. We need to make our dollar go further.
Hannon (Mod): Another question from the floor, back to legacy. How do we stop new systems from becoming legacy, and probably the underlying question is, how do we define legacy? Is legacy when a system becomes a drag or impedes us from competing with partners or keeping up to date with partners?
Hawtin (QBE): In terms of a definition of legacy? I mean, it’s not even something that’s obsolete.
You could take the view that as soon as it’s gone in, technology becomes legacy. But you can obviously continue to iterate and improve upon it. So, I would say ‘not new’ is pretty much legacy. And if you look at AI, it’s moved so quickly. Predictive AI, for instance, many think is now legacy, but it still has enormous value!
Hannon (Mod): Legacy has certainly got a bit of a bad rap.
Hawtin (QBE): It’s not useless! Depending on what you want to use it for, these systems still provide a really good system of record. They still have really good integrations into your general ledger, which allow you to produce your financial reports. We need to respect that. It’s just what you’re asking it to do that’s really important. If it can’t fulfil the rest of what the organisation needs, then it probably has become legacy.
I’d say probably that goes towards my definition: It’s unable to fulfil what the organisation or the market requires you to do as an organisation, then it’s probably legacy.
Dhillon (Rest): It really comes back to your business strategy and your risk appetite. If you set your risk appetite at a certain level, it allows for a certain amount of legacy to exist as well.
Zhu (Open): I wanted to add one thing in terms of, how do you stop something from becoming legacy? Legacy as a word in English, from my perspective, is relative. That’s why a technology or system, almost as soon as it’s out of the gate, becomes legacy in that regard. But if we think about it pragmatically, why do we have these systems? Why do we maintain capabilities and platforms in our business? It’s there to enable a certain activity or speed that we want to operate in.
One of the things I talk about with my team is framing. We frame a particular service as legacy, and we want to think about how we innovate and iterate on top of that. Sometimes, as leaders, we’re quite intentional about framing certain things in a certain way so that we can paint a better future and a picture that we want to take the team on the journey on; not that the legacy system is necessarily bad, but we are thinking about challenging ourselves to bring something newer, more modern and more effective than what we want to do into the future. But it may be that v1 is legacy, but v2 is a shiny new thing until v3 arrives.
To another point that I wanted to call out is, if you want a system to not become a legacy system – one that you really hate and want to throw away because it’s just a heavy backpack that you’re carrying everywhere – it comes with intentionality.
That’s a challenge in many industries. If you really care about a particular system not becoming legacy, that is something that you, as a leader, have to pay attention to. But, at the end of the day, it comes back to this question of, ‘Is it really worth your attention?’.
Hannon (Mod): You’ve all described legacy from a system perspective, but one of the things that underpins any change regime, the move from legacy, or the extracting value from legacy, is the culture within the team. What underpins a great change culture within organisations?
Hawtin (QBE): Leaders. The first thing I look out for when I’m trying to enact business change is how resistant the leader of that business is to change. If there is a resistance there, you’ll never get buy-in at the next level down or right down to the frontline staff. That’s key.
If you want to build a change culture, you build it with them and for them. I don’t know a single frontline staff member who says, ‘Give me a worse system’. They want this, but they don’t want it just dumped on them and built in a way that they’ve had nothing to do with. Bringing them on the journey and getting their buy-in is key. And they’re also the ones who’ll tell you what the risk of the system is that you’re putting in. You’ve got to listen to them. That’s a really important part of the change culture.
As well, big bang doesn’t work. You really need to work on this concept of testing using a small group, who will become your champions.
And I think the HBF example, which Sanjiv Gupta discussed earlier in his presentation, is quite phenomenal. What he did was amazing; having all those squads being business-led probably enabled that organisation to move at that pace without the rejection of the new organ.
Dhillon (Rest): One more key ingredient, and certainly one that works at Rest, is the question of, as an employee, why are we here? What is our purpose? What is our mission?
Our strategy at Rest is around making super simple. Some of you might have seen our ads. That really resonates throughout the organisation, and we’ve spent a lot of time embedding that ethos, that mission and that purpose in our employees. ◾
This is an edited extract from the ‘Adapting to Change: Driving IT Transformation, Innovation and Modernisation in Insurance’ panel featured at the 2025 Future of Insurance event.
