Questions lenders should ask when planning a mortgage or loan portfolio migration – Mortgage Finance Gazette

How much of your current portfolio’s data is integrated?

All of this is the best answer. However, some vendors may tell you that they cannot migrate closed books at all, others may tell you that they only load 12 months of data into their transactional application and keep the rest 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 data migrated, you should look for a provider that can do it.

How do you want to migrate the data?

The main options are Feature Driven, Rate Driven or Big Bang.

For example, based on the test strategy for a portfolio with 20,000 accounts, do you want to migrate tranches of 5,000 accounts simultaneously with full system functionality?

Or do you want tranches of 20,000 accounts with tricked-down functionality? For example, an initial migration may not include delinquent accounts until a subsequent phase.

Alternatively, do you want a big bang of 20,000 accounts migrated at once with full system functionality?

You could potentially 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 is the first step in facilitating data migration and bridging the differences between the two systems.

It’s a tricky subject to be aware of, because when data is moved from the source, it needs to arrive exactly at the destination. Ask questions like: will the new application be able to store key data in the same format as the old system, and if not, how will you link back to the previous system?

Things like account numbers, customer references, and products are important. Likewise, most applications have transactions as the basis of how they work, and different applications manage transactions in different ways. How will you map your existing transactions to transactions in the new system?

1:1 mappings are simple, 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 bit more complex because data needs to be consolidated. For example, the source system has multiple sub-accounts that add up to a “total balance” and the target system contains a value for “total balance”. The mapping is of medium complexity to add the values ​​to complete the sum.

1: Many assignments is similar to the above but reversed and far more complex. Let’s say the source system only contains values ​​for “Total Balance” and the target system requires that “Total Balance” be broken down into individual subaccounts. You may need to go through the source system to identify all of the transactions that went into the “grand balance” and reassign them to the target system’s sub-accounts. You must then ensure that all balances match appropriately.

Test, test, test

Crucial to any migration or boarding activity is that what you start with and what you achieve after migration must be identical. Ask the questions:

What is the documented test strategy?

This should be a detailed plan outlining 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 potential problems 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, where an extensive simulation of the entire onboarding is performed as if it were the actual migration.

How can you verify that the migration was successful?

That’s a really important question. You need a series of reports or checks to confirm that the number of accounts onboarded matches those extracted; the number of transactions is exactly as expected; the book balance is exactly the same; the total number of securities/properties is the same; the total number of customers is the same; the total number of lawyers and other third parties is the same; etc.

What are your acceptable tolerances for trial runs and dress rehearsals?

If some data and/or accounts are not migrated during testing, what is your acceptance level? Do you agree that the accounts are within 0.5%, or within an absolute number of 5, 10, or 50, or do you need 100% accuracy?

Roll back, roll back, roll back

Another critical aspect of your migration or onboarding plan is what you do when things don’t go quite as planned. What happens if the recorded portfolio is incorrect or outside of the tolerances described above?

A strong recommendation is that you always have a boarding exit plan to give you the opportunity to “fix” minor issues and redo the boarding process; or cancel the process to give you the time to properly analyze any issues and try boarding again at a later time.

The typical rollback strategy is to take a snapshot or copy of the system before any boarding activity begins so you can revert to that snapshot.

Timed coordination

Understand how long your boarding process will take and plan accordingly. Make sure your schedule is relevant to the specific demographics of the portfolio being boarded.

For example, just because a provider boarded 10,000 accounts in two hours, does that mean your 10,000 accounts are also boarded in two hours? It is unlikely that you will need to load 100 transactions per account and the previous provider only boarded accounts with 20 transactions per account.

Knowing how long the migration will take, can you schedule it for an evening, weekend, or long weekend?

security and privacy

Any migration or portfolio boarding activity requires the transfer of data, including customer personal data, between systems and prospective organizations. Understand how this data is transferred, at the very least it should be done over a secure protocol like SFTP or a site-to-site VPN.

What permissions do you need (data consent) and what controls need to be in place over the data? Does the data have to be anonymized? If the data is anonymized, what will be the testing strategy?

List of events

A detailed event plan is absolutely crucial for a successful migration or embarkation. This should list the following:

• All critical resources and their contact details

• Any critical milestones during the migration and, if possible, the exact time when they are expected.

• All critical milestones and no-go meetings when for some reason the project cannot proceed, likely causing delays.

• A fallback strategy to a previous milestone in case something goes wrong, rather than redoing the entire migration.

• Forms of communication to ensure that all stakeholders are informed of the progress during the migration.

• A detailed schedule of all events and checks performed as part of the migration to include the results of the checks. Events should be updated by the migration team as they complete.

• The final acceptance should take place at the end of the process by a nominated stakeholder.

Neil Dyke is Chief Technology Officer at Phoebus