The new system is live, and the balances are wrong
The agency chose new lettings software after a long search. The supplier imported the data over a weekend. On Monday, some tenants show arrears they do not have, some landlord balances are off, and the first rent run on the new system produces statements that landlords query. Compliance dates came across, but some were in the wrong field. The old system's contract ends at the end of the month.
Staff spend weeks fixing records while also learning the new software.
Why migrations go wrong
Lettings software holds money, not just records. A migration has to carry over opening balances for every tenant and landlord, deposits and their registrations, outstanding invoices, and the history that explains them. Suppliers' import tools handle standard data well, but every agency has its own habits: custom fields, fees set up unusually, workarounds in notes.
The most common mistake is checking the new system against the export, rather than against the old system itself. If the export dropped something, both look the same.
| Data | Typical migration problem |
|---|---|
| Tenant and landlord balances | Do not reconcile after import |
| Deposits | Scheme references and amounts mismatched |
| Compliance dates | Mapped to the wrong fields |
| Fee settings | Custom arrangements lost |
| Notes and documents | Detached from records |
What a bad migration costs
Wrong balances mean wrong statements, wrong arrears chasing and wrong payments to landlords, which your client money process will not tolerate for long. Staff time goes into fixing records rather than serving landlords. Some errors surface months later, when the old system has gone and the evidence with it.
There is a people cost too. A migration that goes badly makes staff distrust the new system from the first week. They keep private spreadsheets as a safety net, double-enter data and work around features, and the benefits that justified the switch never arrive. Getting the data right before go-live is what makes the team willing to rely on the new platform.
The migration we build
- Inventory: we list what the old system holds, including custom fields and how your team actually uses them, not just the standard export.
- Mapping: each field is mapped to the new platform, with decisions recorded for anything that does not map directly.
- Trial runs: the migration is run into a test copy of the new system more than once, so problems are found before cutover.
- Reconciliation: tenant and landlord balances, deposit totals and references, and compliance dates are compared between the old system and the new one, record by record, and differences are explained or fixed.
- Cutover plan: a short, agreed freeze, a final run and a final reconciliation, with sign-off by your accounts lead before the new system goes live.
- Read-only archive: the old system, or a searchable archive of it, stays available afterwards, because questions about history keep arriving.
We work alongside your new supplier's own migration team, filling the checking and reconciliation gaps rather than duplicating their tools.
What you get
A new system that starts with balances your accounts team has signed off, deposits that match the schemes, and compliance dates in the right fields. Staff learn the new software without also fighting bad data. And when someone asks about something from before the switch, there is somewhere to look.
Signs you need help with this
- You are planning to change lettings software.
- Your current system has custom fields or unusual fee set-ups.
- Nobody has planned how balances will be reconciled after import.
- The old system's access ends soon after cutover.