Mortgage broker CRM migration checklist

Migrations go wrong in predictable ways. Data arrives incomplete, nobody agrees what the new statuses mean, live cases fall between two systems during the switch, and six weeks later half the team is back in the old tool "just for a couple of things".

This is a checklist you can work through in order. It assumes a firm of two to fifteen people moving from a spreadsheet, a generic CRM or another broker platform.

Eight weeks out: decide what travels

Not everything should come across. Migration is the one chance you will get to leave rubbish behind.

• List every field in the old system and mark each as essential, useful or dead. Expect a third to be dead.
• Decide the cutoff for historical clients. Many firms bring across everyone with a mortgage completed in the last six years and archive the rest to a read-only export.
• Decide whether documents migrate or stay in an archive. Bulk document migration is the most expensive and most failure-prone part of the job, and for closed cases an exported archive is often sufficient.
• Confirm your retention position for what you are archiving, and write down the justification. You need this anyway.
• Identify anything the old system holds that nobody has ever exported: call recordings, portal messages, audit logs.

Seven weeks out: agree the language

Do this before configuration, not after. It is the step firms skip and the one that causes the most rework.

• Write a one-line definition of every case status. Argue about them now.
• Define when a lead becomes a client, and when a case becomes dead rather than dormant.
• Agree who owns a case: the adviser, the administrator, or both with different roles.
• Decide what the mandatory fields are, and keep the list brutally short. Every mandatory field is a future workaround.

Six weeks out: clean the source

Cleaning after migration is far harder than cleaning before.

• Deduplicate. Joint applicants entered twice are the usual culprit.
• Standardise phone numbers and postcodes to one format.
• Fix rate expiry dates, which are the field most often wrong and the field the new system will act on.
• Remove records where you have no lawful basis to hold the data and no live relationship. This is a good moment to get that right rather than carry the problem forward.
• Nominate one person to own data quality. Shared ownership means none.

Four weeks out: test with real data

• Run a trial import of a representative sample, not the tidy records. Include a joint application, a case with a deceased client, a client with an apostrophe in their surname and a case with fifteen documents.
• Check dates specifically. Day and month transposition is the classic import failure and it will not announce itself.
• Check that empty fields imported as empty rather than as a default value that looks like data.
• Have two people who were not involved in the import spot-check thirty records against the old system.
• Confirm what the export from the new system looks like, before you depend on it. Ask for a sample export now.

Two weeks out: prepare the people

• Train on your own migrated data, never on the vendor's demo environment. People learn the shape of their own records.
• Write a one-page process note covering the five things each role does daily. Not a manual; a page.
• Agree a freeze date after which nothing new goes into the old system.
• Tell your network or compliance oversight if the change affects where advice evidence is stored.
• Decide what clients need to be told, particularly if a new portal means new login emails from an unfamiliar sender.

Cutover week: handle live cases deliberately

This is where most of the pain lands. Cases mid-flight belong to whichever system your team is actually looking at, and ambiguity here loses documents.

• Move every live case manually, one at a time, with a human checking each. Automated import is for the back book.
• Keep the old system open but read-only. Read-only is the important word.
• Assign one person as the arbiter for the week. Any question about where something lives goes to them.
• Expect reduced output. Plan the week when nothing else demanding is happening, and avoid quarter end.

First month after: watch for silent failure

• Check that automated reminders actually fire, by seeding a test rate expiry a week out.
• Check that inbound enquiries reach the new system and nothing is still routing to the old address.
• Sit with each person for thirty minutes and watch them work. You will find at least one task everybody is doing in the old way because the new way was never explained.
• Look for records created since go-live with missing key fields. That pattern tells you a form is wrong or a step is unclear.

Three months after: close it properly

• Confirm the old system is exported in full and the export is stored somewhere you can actually read it.
• Cancel the old subscription only once the export is verified, not on the promise of one.
• Delete the old spreadsheet copies scattered across desktops. This is genuinely a data protection matter and it is universally forgotten.
• Write down what went wrong. You will do this again in five years.

Confirm import formats, document handling and export terms with your new vendor before signing, since these vary and change.