Migrating a portfolio's compliance records into new software

Deciding when to switch from spreadsheets to a dedicated platform is the easier part. The harder, less glamorous part is actually getting years of scattered certificates, dates, and tenancy files into the new system accurately — and it's worth planning for properly rather than treated as an afterthought once the contract's signed.

Auditing what you actually have before migrating it

Before moving anything, it's worth a genuine stocktake of what records currently exist and where — some properties will have clean, complete files; others will have gaps, expired certificates nobody chased, or evidence that technically exists somewhere but nobody can immediately locate. Migrating gaps into a new system doesn't fix them; it just gives them a cleaner-looking home. Migration is a good moment to also run something close to a proper file audit alongside it.

Prioritise by risk, not by ease

It's tempting to migrate whatever's easiest first — the cleanest files, the most organised landlord's properties — but it's usually more valuable to prioritise by compliance risk instead: properties with certificates due soon, or with a history of near-misses, benefit most from being in the new system's tracking early, even if their underlying records are messier to bring across.

Running two systems in parallel, briefly and deliberately

A short overlap period, where the old spreadsheet and the new system both hold current data, reduces the risk of a renewal date falling into a gap between the two — but this needs to be a short, clearly bounded period, not an indefinite state where nobody's sure which system is actually authoritative. An open-ended parallel run tends to become its own quiet source of drift.

• –Audit what records actually exist and where, before deciding what to migrate and how
• –Prioritise migrating properties by compliance risk, not by which files are easiest to move
• –Keep any parallel-running period short and clearly bounded, with one system named as authoritative
• –Confirm data after migration against the original source, not just trust that the import worked
• –Use the migration as a natural point to also audit tenancy files more broadly

Checking the migration actually worked

It's worth spot-checking a sample of migrated records against the original source rather than assuming an import process worked cleanly across every field for every property — a date that imported in the wrong format, or a document that didn't attach correctly, is far better caught during a deliberate check than discovered months later when a renewal notice doesn't fire.

Factoring this into the overall cost decision

Migration effort is a real cost that's easy to underweight when comparing the sticker price of different systems — see our guide to what compliance software actually costs for the broader point that the invoice is rarely the whole cost of a switch.

Migration is where the gaps become visible

Every agency discovers the same thing during migration: properties with missing certificate dates, tenancies whose documentation stops at the original term, deposits with no record of exactly when the later steps happened, and a number of entries nobody can explain. The migration did not create any of it — it simply required the data to be internally consistent for the first time.

Which is why carrying everything across is usually the wrong instinct. Migrating what is current and verifiable, and archiving the rest somewhere readable, produces a system people trust from day one rather than one that inherits every existing gap.

Common mistakes

• –Migrating everything rather than what is current and verified
• –Treating data cleanup as a task for after go-live
• –No agreed rule for which source wins when two disagree
• –Losing document attachments by migrating records without them
• –Retiring the old system before confirming everything transferred
• –Going live with gaps that then look like the new system's fault