The biggest barrier for lenders to move their mortgage book to a new software provider is their fear of the migration process. A substantial amount of work goes into onboarding loan portfolios and Neil Dyke, chief technology officer at Phoebus, suggests some of the questions lenders should ask as you plan your migration strategy.
How much of the data of your current portfolio will be onboarded?
All of it is the best answer. However, some providers may tell you they cannot migrate closed books at all, others may tell you they will only load 12 months of data into their transactional application, with the remainder in an archive.
Any of these answers may work for you, but you should ask the question and be aware of any limitations. If you want all of the data migrated you should seek a provider that has the capability to do this.
How would you like the data migrated?
The main options are functionality driven, quantity driven or big bang.
For example, based on the testing strategy, for a 20k accounts portfolio do you want tranches of 5k accounts migrated at a time with full system functionality?
Or do you want tranches of 20k accounts with trickled down functionality? For example, an initial migration may not include accounts in arrears, until a subsequent phase.
Alternatively, do you want a big bang of 20k accounts migrated in one go with full system functionality?
Potentially, you could decide to load all redeemed accounts in one phase, followed by live accounts in a subsequent phase.
Data mapping
Different systems store similar data in different ways so data mapping is used to transform data from one system to another. It’s the first step to facilitate data migration and bridges the differences between the two systems.
It is a thorny topic that you need to be aware of because when data is moved from the source, it must arrive accurately at the destination. Ask questions such as: is the new application able to hold key data in the same format as the old system, and if not, how will you cross reference back to the previous system?
Such things as account numbers, customer references and products are important. Equally, most applications have transactions as a fundamental to how they work, and different applications manage transactions in different ways. How, will you map your existing transactions to the transactions in the new system?
1:1 mappings are easy, for example, you map the customer’s name, address, account number, etc, from the source system to the same fields in the new system.
Many:1 mappings are a little more complex as it involves consolidating data. For example, the source system has multiple sub accounts adding up to a “total balance”, and the destination system holds one value for “total balance”. The mapping is of medium complexity to add up the values to complete the total.
1:Many mapping is similar to the above but in reverse, and far more complex. Let’s assume the source system only holds value for “total balance”, and the destination system requires the “total balance” to be divided into individual sub accounts. You may need to go through the source system to identify all the transactions which went into the “total balance” and re-allocate them into the destination system’s sub accounts. You then need to make sure that all balances reconcile appropriately.
Testing, testing, testing
Critical to any migration or boarding activity, what you start with and what you end up with after the migration have to be the same thing. Ask the questions:
What is the documented testing strategy?
This should be a detailed plan that outlines the approach, goals, objectives, and methods for the migration.
How many dry runs will there be?
The purpose of dry runs is to identify and address any potential issues or risks, gaps in the plan, unforeseen technical or logistical issues before the actual migration takes place.
How many dress rehearsals will there be?
The dress rehearsal is the final step in the process, which involves running a comprehensive simulation of the entire onboarding as if it were the actual migration.
How will you validate that the migration has been successful?
This is a really important question to ask. You will need a series of reports or controls to validate that the number of accounts boarded is equal to those extracted; the number of transactions is exactly as expected; the book balance is exactly equal; the total number of securities/properties is equal; the total number of customers is equal; the total number solicitors and other third parties is equal; etc.
What are your acceptable tolerances for dry runs and dress rehearsals?
During testing if some data and/or accounts does not migrate over, what is your acceptance level? Are you okay with the accounts being within 0.5%, or within an absolute number of 5, 10 or 50, or do you require 100% accuracy?
Rollback, rollback, rollback
Yet another critical aspect of your migration or onboarding plan, is what do you do if things do not quite go as planned. What happens if the portfolio which is boarded is errant or outside of the tolerances described above?
A strong recommendation is that you always have an exit plan for the boarding process, to give you the chance to “fix” minor issues and re-run the boarding process; or to abandon the process to allow you the time to properly analyse any issues and re-run the boarding at a later date.
The typical strategy for rollback is to take a snapshot or copy of the system before any boarding activity starts to allow you to recover back to that snapshot.
Timing
Understand how long your boarding process will take and plan for it. Ensure that your timing plan is relevant to the specific demographics of the portfolio being boarded.
For example, just because a provider has boarded 10,000 accounts in two hours, does that mean that your 10,000 accounts will also board in two hours? It’s unlikely if you have 100 transactions per account to load, and the previous provider only boarded accounts with 20 transactions per account.
Once you know how long the migration will take you can plan it to take place in an evening or a weekend or a long weekend?
Security and Data Privacy
Any migration or portfolio boarding activity will necessitate the transfer of data, which includes Personally Identifiable Customer data between systems and potentially organisations. Understand how this data will be transmitted, at a minimum this should be via a secure protocol such as SFTP or a site-to-site VPN.
What permissions do you need (data consent), and which controls have to be in place with regard to the data? Does the data need to be anonymised? If the data is anonymised, what will the testing strategy be?
Schedule of events
Absolutely critical to a successful migration or boarding is a detailed schedule of events. This should list the following:
Neil Dyke is chief technology officer at Phoebus
