Kathy Gibson at Saphila 2014 – South Africa’s banks are well known for their forward-thinking and pioneering application of technology, having been among the first in the world to adopt most modern banking systems.

The downside of this is that most banks are now grappling with a legacy of multiple layers of systems that are hard to integrate or modernise – and even harder to move away from since they often run the very core of the bank’s business.

Standard Bank recognised the challenges and determined to migrate its core banking systems to a modern SAP system in a migration that the bank believes touches as much as 10% of the South African population.

Standard Bank’s Jane Scott explains that the bank has a mass of legacy systems and processes but was challenged to provide a better customer experience.

Through the core banking transformation, the bank hoped to offer easy access and new capabilities to its users, with slick systems and processes that touch all aspects of the value chain.

“So this was a business-led initiative – not an IT project,” Scott says.

The transformation was broken down into eight separate releases, the first is which was to migrate 4,5-million customers from 11 systems rationalised into one.

Among the lessons learnt is that a migration is not just about moving data from one system to another,” says Scott. “You can’t just map data and move it: there are many more things you need to consider. There was plenty we didn’t focus on in the beginning – but with experience and input from other organisations we have learnt a lot.”

First and most importantly, she says, when building a new offering you need to consider the impact it will have on existing customers and users.

“New functionality is easy; and new target offerings can be fun. But if you don’t consider impact on existing customer it will mean new releases might be necessary after the fact.”

Analysing the existing data is important, Scott says, as this will inform as to the impact on customers. “We have many legacy systems and people can’t really keep track of all the data, even if they have a lot of knowledge. But the data in your systems will inform you; you need to interrogate your own data.”

This data can help to show up any potential pitfalls, says Scott, as the possibility of a customer not being able to operate their products efficiently could be a problem.

One of the major considerations for a migration event, she points out, is when it should be run. “For us, we had a specific window when we could do a migration and you might have to consider things like the time of year, month or day when there will be the least customer impact. We had to consider when customers were least likely to be transacting on their accounts since there would be downtime.”

Finding the window will also determine the amount of time you have within the window, Scott adds. “You may have a week – or you may have three hours to execute.”

Logistics needs to be planned up front, Scott says, since the people on the ground will all need somewhere to sit, connect and perform their tasks.

Getting buy-in to the project from the rest of the business is important – and extremely motivating for the team – but it can be counter-productive if you don’t limit how much access and input visitors to the project area are allowed.

“We found we had a lot of visitors,” says Scott. “It was great to have their support but we ended up with a lot of people looking over people’s shoulders and trying to advise teams.

“What we implemented for the second event was an armband system where if representatives from organisation wanted to visit, be part of the journey, they could do so – but we gave them different armband colours so they weren’t allowed to sit next to the tech team.”

Checks and balances are a major part of any big project, and Scott says team leaders need to consider the traceability of the migration. “We have a team do checks and balances and reporting. This makes sure that everything happens and, because there are so many checks and balances in place, management will buy into the project.

“You need to be able to answer what you have moved to the new systems and what you have left behind.”

Teams should also consider aligning data in order to minimise impact on migration. This could involve a team doing data clean-up and simultaneously advising customers on what is happening.

It goes without saying that the right team, with the right skills, needs to be on board. In Standard Bank’s case, different aspects of the migration were with different parts of the team, but the end to end migration was undertaken with the full team.

Partners are an equally important part of the team, Scott says. The bank leveraged a number of partnerships, working with SAP on reviews of the target system and advice on the migration itself. “It’s important to have an outsider’s set of eyes look at the solution; if you are too close to it, you may not notice the holes.”

Partners also helped Standard Bank to talk to other customers. “We would set up conference calls and knowledge sharing sessions with other customers,” says Scott. “This let us soundboard designs, and pick up items we hadn’t focused on yet which could trip us up later.”

Another key to the success of the project was the use of live data. “You need to try to test with real data that is available in the production environment,” Scott says. “If you don’t you may have multiple scenarios arising and you could miss some of the. It also allows you to test the specific volumes you can migrate and informs about the window of opportunity for the migration.”

Before the migration event takes place, the organisation should understand the trade-offs and priorities in order to make informed decision.

This ties in to communication and buy-in, which is vital.

“To create buy-in across the organisation we created an easy aid and did a walk-through with all the representative and executives. This enabled people, even if they weren’t  on the project, to understand what we were trying to do and make them feel part of the process.

“This meant they knew where they were on the project, we gained their trust and we achieved informed group decision-making.”

A lot of preliminary work was undertaken ahead of the actual migration. “With a limited window of opportunity, it is key how much you can do before the actual time,” says Scott. “But doing more things earlier you can execute the critical items during the migration window. We moved the static data a week prior to the migration event so we only had to move live data at the end.”

Change management was vital across the whole project, Scott adds. “Helping to ensure a success migration was our change management team that worked a lot with social media and with our customers. As a result, everyone knew it was happening on that weekend and we didn’t have the customers complaining over social media.

“This helped because we didn’t have to deal with disgruntled customers as well as the live event.”
For the core banking transformation project, Standard Bank performed three migrations.

The first was the “friend of the programme” migration for staff members and numbered fewer than 10 000 accounts; this was followed by the “hundreds of thousands” migration of 500 000 accounts; and then by the “millions” migration where 3,5-million accounts were migrated to the SAP system over the course of a weekend in April 2013.

“There are two things that will make a migration project like this successful: resilience and team work,” Scott concludes.