From spreadsheet to system: migrating a brokerage without losing a week

Most brokerages delay changing systems for the same reason: the pipeline can't stop. There's never a quiet fortnight in which to move, and the risk of dropping a live file during a cutover feels far more vivid than the ongoing cost of the spreadsheet.

That instinct is right about the risk and wrong about the remedy. The remedy isn't to find a quiet fortnight. It's to design a migration that never requires one.

Migrate by stage, not by date

The single decision that de-risks a migration is to stop thinking about a cutover date and start thinking about a cutover point in the deal lifecycle.

• New enquiries start in the new system from day one
• Live files continue to completion where they already are
• The old pipeline drains naturally over a few weeks
• Nothing is moved mid-flight

This costs you a period of running two systems in parallel, which feels inelegant. It buys you the elimination of the single biggest failure mode: a half-migrated deal where nobody's certain which record is authoritative.

A migration should be a series of small reversible steps, not one risky cutover.

Sequence the data by need

Data follows the same principle. Move what the next new file will need, in the order it will need it, and leave the rest until it's genuinely required. This is easier when client onboarding and company data are captured once and reused throughout the file, rather than re-keyed at every stage.

First: contacts and companies

Every new file touches these, so they go first. This is also the right moment to deduplicate. A migration is the only time a firm ever willingly cleans its contact data, and the effort pays back immediately in reporting quality.

Second: lenders, products and pipelines

Configure the stages that match how the desk actually runs, not how an old system forced it to run. This is a rebuild, not a copy. The most common migration mistake is faithfully recreating workarounds that existed only because the previous tool was inflexible.

Third: historic documents and closed files

Archive and index rather than reprocess. You need to be able to find a closed file and answer a question about it; you don't need it to be a fully structured record in the new pipeline. Reprocessing history is where migrations lose their weeks.

Who does what

Migrations stall on ownership more often than on technology, a point covered in more depth in our piece on operational discipline as a competitive edge. Three roles need to be explicitly assigned before anything moves.

• A process owner who decides what the stages are and settles disagreements about them
• A data owner who is accountable for what gets moved, cleaned and archived
• A day-one champion on the desk who fields the small questions in the first fortnight

The third role is the one most often skipped, and the one that most affects adoption. In the first two weeks, the difference between a broker asking a colleague and a broker quietly reverting to their spreadsheet is whether someone visible is available to answer a thirty-second question.

A realistic sequence

Weeks one and two: define

Map the real workflow for your highest-volume product with the people who work it. Define stages, required documents and compliance gates. Resist the urge to design all products at once.

Week three: configure and load

Stand up the pipeline, load contacts and companies, and configure templates and document generation. Run two or three historic deals through the new stages on paper to test whether the model holds.

Week four: switch the front door

New enquiries begin in the new system. Live files stay where they are. This is the only irreversible step, and it affects nothing already in flight.

Weeks five to eight: drain and extend

The old pipeline empties as live deals complete. Meanwhile, add the second and third product pipelines, informed by what the first taught you. By the end of this period, the old system is a read-only archive.

Choosing what to migrate into

The migration plan above works whatever you're moving to, but the target matters. A customisable CRM built around commercial lending stages will absorb far more of this work than a generic sales tool retrofitted with broker terminology. Our guide to choosing a CRM for mortgage and commercial finance brokers sets out what to look for before you commit.

Integrations decide how much re-keying survives

A system that connects to Companies House, open banking and e-signature providers removes entire categories of manual entry rather than just tidying them. Check this before migration, not after. Retrofitting integrations onto live pipelines is far more disruptive than including them in the original build.

• Companies House lookups for incorporation, filing history and PSC data
• Open banking for income and expenditure verification
• E-signature for engagement letters and application documents
• Accounting package links for firms that also handle invoice finance or asset finance referrals

The point of a migration is not to have a new system. It is to have fewer places where a fact can go stale.

Common mistakes worth naming

A handful of failure patterns recur across migrations, regardless of firm size:

• Migrating history in full instead of archiving and indexing it
• Recreating every old field without asking whether anyone still reads it
• Running one big training day instead of short sessions timed to each go-live
• Leaving compliance checks as a manual step instead of building them into the pipeline stages
• Underestimating how long deduplicating contacts and companies actually takes

What to leave behind deliberately

A migration is a chance to stop doing things. Every spreadsheet has accumulated columns nobody reads, statuses nobody sets and a tab that one person maintains for a report that was cancelled two years ago.

Interrogate each field before recreating it. Ask who reads it, what decision it changes, and what would happen if it disappeared. Fields that survive that question are worth configuring. Fields that don't are the reason the old system felt heavy.

Reporting and dashboards during the transition

One awkward truth about any migration is that reporting gets harder before it gets easier. For a few weeks, some deals sit in the old spreadsheet and some sit in the new pipeline, and a single view of the business doesn't exist yet.

The practical fix is to accept a manual combined report for the transition period rather than trying to automate a merge of two systems that won't exist together for long. Once the old pipeline has drained, dashboards built on the new system give a cleaner and more current picture than the spreadsheet ever produced, because the numbers are pulled from live records rather than compiled from memory once a week.

Firms that track deal volumes against sector data, for instance the lending statistics published by UK Finance or the business finance figures in the ONS releases, find this a natural point to set up that comparison properly, since the new system usually exports the underlying numbers far more easily than the old spreadsheet did.

Knowing whether it worked

Set the measures before you start, so success isn't a matter of opinion three months later:

• Zero live deals lost or delayed by the migration itself
• Time from enquiry to submitted pack, compared against the pre-migration baseline
• Proportion of new files created in the new system in week one, and again in week six
• Number of shadow spreadsheets still in use after a month
• Time to answer a question about a closed historic file

That fourth measure is the honest one. Shadow spreadsheets aren't a discipline failure; they're a signal that the new system doesn't yet do something the desk needs. Treat each one as a requirement you missed rather than a rule someone broke.

The point of the exercise

Run this way, a migration isn't a leap. It's a series of small, reversible steps, each one small enough that a bad week doesn't become a bad quarter, while the desk keeps trading throughout. The pipeline never stops. It simply moves house one new deal at a time.