No amount of rigorous testing can eliminate all the teething problems when hundreds of thousands of client accounts are being moved
With multiple platforms undergoing technology changes, advisers are having their work disrupted by businesses moving their clients’ data.
Two significant client data migrations have taken place in the past two months, with Aegon moving Cofunds’ non-advised clients to its upgraded platform at the end of December and Aviva shifting all clients to its new platform in mid-January.
Aegon says the main teething trouble from its first phase of migration was having more clients than anticipated calling it. For Aviva, however, the migration resulted in frustration from advisers that they could not carry out certain functions and the platform was closed for an additional day than was planned.
Money Marketing spoke to Aegon and Aviva about their migration processes and how advisers are central to them going smoothly.
According to data from Platforum, there are £237bn worth of assets that will be moved as part of ongoing replatforming or technology projects, and that figure rises to £255bn if Aviva’s assets are included.
As well as Aviva and Aegon, other companies to have either recently replatformed or still to complete their projects include Old Mutual Wealth, Alliance Trust Savings, Ascentric and FundsNetwork.
Aviva’s migration took place over five days in January and involved moving about 350,000 client accounts from its former technology providers, Bravura and Genpact, to its new supplier FNZ. Following the migration period, some of the platform’s features are still being added on a staggered basis.
Aegon moved 79,000 non-advised Cofunds Investor Portfolio Service clients to its upgraded platform between 22 and 24 December. It plans to move about 400,000 advised Cofunds clients to the platform in May.
Both migrations involved rigorous testing of the technology and practice runs before the actual migration of client information took place.
Aegon distribution and marketing director Mark Till says the new platform was built in a test environment where a “parallel processing” trial replicated what the current platform is going through.
Over the migration weekend, the old Cofunds IPS system was taken down and the new one plugged in to the system that clients use before it was subjected to further testing.
Till says: “We move the customer data on to the system because, in the parallel running, it is not the master record, so we move that and then the system comes up and goes live at the end of this process.”
He adds: “We closed on the Friday [22 December] and I had an email on the Sunday saying we had successfully completed the migration and four customers had already logged in to the new customer portal.”
Aviva platform chief executive Tim Orton says that, across the two-year period that the company’s replatforming project has been running, about 200 people have worked on it, including representatives from Aviva, FNZ and Genpact, as well as external analysts and a specialist “migration expert”.
That external company was used so there was a boundary between the two software providers. It mapped the data off Aviva’s old platform and put that information into a central database before mapping it from there on to the new platform.
Orton says: “One of the challenges involves the intellectual property of the different providers. [Platform technology companies] don’t want each other to see their data structures, so we created the bridge to allow confidentiality of information to be passed across.”
Aviva then carried out a series of practice exercises, which tested moving the data from one place to another, followed by dry runs, and then “dress rehearsals” that gave an indication of how long it would take for the different steps to complete.
Despite all the practice runs, Aviva had to extend the amount of time that the platform was down, which it called a “blackout” period, by an extra day, because the migration took longer than it did in testing.
Orton says part of the data mapping process held up the migration.He says: “We had hoped to do it in the four days, but when it came to it, we were not quite complete in terms of the overall process, so we decided to stay closed for the additional day to complete all of the data checks off the back of the migration.”
Because of the number of platforms going through major projects to change or upgrade their technology, Altus senior consultant Ben Hammond admits it will be hard for advisers not to be affected by some form of replatforming activity. He says communication about the migration process and how they and their customers will be affected is their most important consideration.
Hammond says: “The adviser will be expecting to be well communicated with and will want to make sure they have got access to a company’s business development manager – the person at the platform that they have a good relationship with.
“No matter what platform a company uses, the adviser is not going to be able to get away from it, because there are so many going through a transformation of this type.”
Till says clients and advisers need to be clearly told practical information, such as how to access and login to the new system, and being made aware of legal information, such as changes to terms and conditions.
He says communication with advisers about the migration in May started two months ago.
Till says: “What will happen between now and then is the level of content will increase. It will become much more specific, with videos [about how to use the new platform].
“As much as there is a high degree of commonality [with how advisers use the platform], at the moment it is to make sure no one feels exposed or vulnerable.”
Because Aviva extended the blackout period for an extra day, advisers and clients had to be told that access to the platform would be restricted for longer than expected on the morning of the extension.
Advisers complained that the service was not fully operational, which led to Aviva admitting some features would be added on a staggered basis.
Orton says: “It was a decision made over the weekend, so we communicated it out first thing in the morning. We got a communication out on to our website where the advisers could enter into the platform.”
He adds: “We also had all of our operational teams briefed early in the morning when our business was opening, so they could start to communicate the news to the most regular users of the platform.
“That meant we were able to brief some advisers in advance and others had the information clearly posted on our website.”
Communication is absolutely essential. The last thing we want is for the client to get information before us. If we are overseeing systems and processes, we need our support team to know what is going on, too. Our experience is that everything takes longer than expected and, whatever target date we are given, it rarely happens by then. We often don’t get told about bugs or glitches. We often discover them and then are told a fix is needed on a future version of the platform.
Peter Chadborn is a director at Plan Money
Leading up to the migration exercise, there would be a significant amount of testing of the different phases, including dry runs to prove the development and that the migration will deliver the expected results.
At the point of the migration, you will have a scenario where the business will close for a period of time. If you look at what happened at Cofunds, it was geared up to a time of year that would have less impact on the adviser community and less impact on the marketplace when it comes to trading activity.
Then there will be a period of cutover, where the end of day will be reconciled and run and cleared so you have an audit of what needs to happen. The data will be migrated from one system to another and reconciliation routines will be run to prove all the data has come across. It will then be subject to a combination of automated testing scenarios and tools and human oversight.
If it is a bank holiday weekend – a lot of these migrations happen over a bank holiday-type weekend to give more time to mitigate any potential errors and to provide more continuity – you may find there is a test of the reconciliation and then a further migration just to prove everything has landed well.
Post that implementation period, there is often a warranty period when technology teams, not just from the technology organisation, walk the floor making sure that the service is being provided the way it is meant to, that the transactions are flowing through, that all of the daily processes are being reconciled and that any anomalies are monitored quickly should there be any features after the migration that need to be rectified.
A lot of the time, contingency plans for things going wrong will depend on the methodology that has been adopted as part of the transformation.
If you look at the different kinds of projects that have been adopted in the industry, some of the more successful ones have been where the capability has already been proven in production before being moved to a migration.
Having that experience, if you can be disciplined enough to assess the book of business as a data migration that needs to comes across, you can make sure things are working as you would expect after the migration.
David Simpson is GBST Europe, Middle East and Africa head