Mortgage broker technology adoption plan

Changing systems in a brokerage is unlike changing systems anywhere else, because your cases are long-lived, legally significant and half-finished at the moment you switch. A client who applied in March under one process and completes in July under another still has to receive a coherent service and leave behind a coherent file.

This is a sequenced plan for making that change without breaking live cases.

Phase one: decide what problem you are buying against

Write one sentence describing the constraint, before you look at any vendor. Not "our CRM is old" but something testable: administrators spend two hours a day rekeying data that already exists, or we cannot tell which cases are waiting on the client, or file checks keep coming back with the same three gaps.

Then quantify it roughly. Count how many times last week someone asked "where is that case up to" in the team chat. Time an administrator doing the rekeying for three days. You do not need precision, you need a baseline you can compare against in six months.

Without this, every demo looks impressive and you will buy on feature count.

Phase two: shortlist against your actual constraints

Three constraints eliminate more options than any feature comparison.

If you are an appointed representative, your network may mandate or prohibit specific systems and will certainly have a view on where client data sits. Ask them first, not last.

Second, integrations. Sourcing, criteria search, lender submission routes, identity verification, open banking, credit reports, e-signature, protection providers and your accounting system all need to work. A platform that does everything except talk to the one tool your advisers use hourly is not a saving.

Third, data export. Ask, in writing, what you get if you leave: which fields, in what format, including document attachments and audit history. Vendors who answer that clearly are usually easier to work with in every other respect too.

Phase three: run a pilot on real cases

Pick a small, contained slice of work and run it properly for a defined period. Good candidates are new enquiries only, or one adviser's new cases, or a single case type such as remortgages where the journey is short enough to complete inside the pilot.

Two rules make a pilot useful. First, the pilot cases must be genuine, with real clients and real deadlines, because a demo dataset never surfaces the problem where the system cannot handle a joint application with three income sources. Second, someone has to be responsible for writing down every friction point as it happens, including the small ones. The accumulation of small ones is what decides whether advisers adopt the system or quietly keep using the spreadsheet.

Set a decision date in advance and hold it. Pilots that drift become permanent parallel systems, which is the worst possible outcome.

Phase four: migrate the data honestly

Data migration is where most of these projects go wrong, and the failure is nearly always that nobody looked at the data before moving it.

Extract your existing records and inspect them. You will find duplicate clients, missing consent records, product expiry dates that are wrong or absent, cases marked open that completed two years ago, and contacts whose lawful basis for marketing you cannot evidence.

Fix that before migration, not after. Moving bad data into a new system produces a new system full of bad data and a team who conclude the new system is unreliable. It is also a genuine data protection question: migration is a good moment to delete records you no longer have a reason to hold.

Migrate in stages where you can. Contacts and completed history first, then live cases, then documents. Reconcile counts at each stage.

Phase five: cut over without stranding live cases

Agree a rule for in-flight work and communicate it once, clearly. The usual choice is that cases past a defined stage finish in the old system while everything new starts in the new one. That means running both for a period, which is annoying but far safer than mid-application migration.

Set the date the old system becomes read-only, and the date it is decommissioned, and put both in the calendar. A read-only period of several months is sensible: you will need to retrieve things.

Check your retention obligations before switching anything off. Advice files, suitability evidence and communications need to remain accessible for the periods your compliance framework requires, and "we cancelled the subscription" is not a defence.

Phase six: training that survives contact with a busy week

Train on your own workflows using your own case types. Generic vendor training teaches the software; it does not teach how your firm handles a gifted deposit or a case that needs a second lender.

Write a short internal guide covering the ten things people do most, and name one person as the internal expert who fields questions. Expect a productivity dip for a few weeks and do not schedule the cutover for your busiest period. For most UK firms that rules out the run-up to spring and any month with a large block of fixed-rate maturities.

Judging it afterwards

Return to the baseline you wrote in phase one and measure the same thing again. If administrators were spending two hours a day rekeying, are they now?

Watch for the failure that looks like success: a system that produces more tasks, more fields and more dashboards while nobody's day gets easier. If adviser hours have not moved and file quality has not improved, the workflow was the problem and the software has simply given it a new interface.

Review the whole thing at six months and again at twelve, and be willing to conclude that you configured it badly rather than that you chose wrong. Reconfiguration is usually cheaper than another migration.