Every software demo covers data migration. Properties, owners, tenancies, documents, photos. The vendor will show you a tidy import and a timeline, and to be fair, most of the time they deliver exactly that.
What the demo doesn’t cover is the part that actually goes wrong. Your trust account has to stay reconciled, balanced and auditable across the cutover, on a day when your team is learning a new system, your bank feed has just been rebuilt and the old software is about to be switched off. A migration that loses a photo is annoying. A migration that leaves your ledgers a few hundred dollars out is a trust account discrepancy, and it’ll still be there when your auditor turns up.
Here’s what to get right.
The short version
- Cut over straight after a completed end of month, never during one, and finish the old system first.
- Seven things break: opening balances, unpresented items, bonds, paid-to dates, recurring fees and rules, the audit trail across the boundary, and the bank feed.
- On day one, every ledger has to match the old system exactly, and the three-way reconciliation has to balance.
- Reconcile daily for the first month. A variance found on day three is a data question. On day thirty it’s an archaeology project.
- Changing software isn’t changing your trust account. Opening or closing an account is a separate regulatory event.
Pick the cutover date before you pick anything else
Cut over immediately after an end of month, never during one.
The reason is simple. Mid-period, your ledgers are full of part-paid rent, invoices raised but not disbursed, and money received but not yet allocated. Every one of those is a judgement call that has to be made twice, once in each system. Straight after a completed end of month, the picture is as clean as it ever gets. Owners have been paid, fees have been taken, statements have gone out and the account has been reconciled.
Before anything moves, the old system has to be finished, not nearly finished. The final month fully reconciled. The bank reconciliation agreeing. Disbursements run. No unallocated money sitting in a suspense or holding ledger to be sorted out later. Whatever you haven’t resolved in the old system, you’ll inherit in the new one, with less information to resolve it.
Lining the cutover up with your audit year end is nice, not necessary. A mid-year migration is perfectly normal and perfectly auditable, as long as the trail across the boundary is intact. The audit year matters most in Western Australia, where the trust account year runs to 31 December rather than 30 June, so a December cutover there lands right on top of a year end and is worth avoiding.
The seven things that actually break
1. Opening balances. Every owner and tenant ledger has to arrive in the new system at exactly the balance it left the old one. Not close. Exactly. Then the test that matters, the three-way reconciliation: the sum of all ledger balances must equal the trust bank balance, adjusted for unpresented items, on day one. If it doesn’t balance on the first day, it won’t balance on the thirtieth, and you’ll spend the first month chasing a variance that was baked in before you started.
2. Unpresented items. Payments and cheques issued in the old system that clear after cutover are the classic source of a first-month variance. Decide how you’ll treat them before the migration, not after. The cleanest approach is to clear as many as you can beforehand. Whatever’s left has to be carried into the new system as an unpresented item, not quietly ignored because the opening bank figure “looks right”.
3. Bonds. Bonds are where jurisdiction bites. Money you hold as a bond, money lodged with the authority, part-lodged bonds and claims in progress all need to land correctly and be distinguishable from each other. This matters far more in some places than others. In the Northern Territory there’s no central bond authority and deposits stay in your trust account for the life of the tenancy, so an NT portfolio carries a big balance of bond money that a New South Wales portfolio simply doesn’t. Bonds mid-claim at cutover deserve a list of their own, tracked by hand until each one lands.
4. Paid-to dates and part payments. If rent paid-to dates come across wrong, your arrears report is fiction from day one. Either it invents arrears that don’t exist, which your property managers will chase and your tenants will resent, or it hides arrears that do, which is worse. Part payments and rent credits are the usual casualties. Spot-check paid-to dates against the old system for a sample of tenancies before you go live, weighted towards the ones with irregular payment histories.
5. Recurring charges, fees and disbursement rules. Management and admin fees, recurring invoices, water usage arrangements, owner disbursement rules, withheld amounts and minimum balances are all configuration rather than data, and configuration is what migrations drop. The failure is silent. Nobody notices a fee that stopped being charged until somebody reconciles income three months later.
6. The audit trail across the boundary. You have to be able to show an auditor a continuous record of every trust transaction, including the ones that happened in software you no longer pay for. Read-only access after cancellation is a courtesy, not a guarantee. So before the old system is switched off, export and archive full transaction listings, receipt and payment registers, audit trail reports, bank reconciliations and owner statements for the whole retention period. The vendor’s data retention policy isn’t your record-keeping obligation. That stays with the licence holder, and it runs for years.
7. The bank feed and the trust account itself. Rebuilding the feed takes time and doesn’t always come across cleanly. Expect a gap, and plan to import statements manually for the first cycle rather than discovering at end of month that a fortnight of transactions never arrived.
One important distinction: changing software isn’t changing your trust account. If the account itself stays open, there’s no regulator notification to make. If you’re also opening a new trust account, or closing an old one, that’s a separate regulatory event with its own forms and its own deadlines. Run it as a separate project rather than bundling it into the software migration.
The first month in the new system
Reconcile daily for the first cycle, even if your normal rhythm is monthly. It’s the single most valuable habit available to you during a migration. A variance found on day three is a data question. The same variance found on day thirty is an archaeology project across two systems, one of which you may no longer be paying for.
Three checkpoints are worth diarising:
- Day one. Ledger balances agree to the old system. The three-way reconciliation balances.
- Week one. Receipting is landing on the right ledgers. Arrears looks sane. The bank feed is actually delivering.
- First end of month. Fees have charged correctly, disbursements have run, and owner statements match what those owners got last month in the old system. Compare a sample side by side.
On parallel running: fully processing a month in both systems is usually more risk than it removes, because your team is doing everything twice and neither properly. The version worth doing is a reconciliation-only parallel. Verify balances and the reconciliation at the cutover point in both systems, rather than duplicating every transaction.
What your auditor will ask
Auditors test transactions from receipt to disbursement and expect to follow the trail without gaps. A migration puts a seam right through that trail, and the auditor will look straight at it. Expect to produce the final reconciliation from the old system, the opening balances in the new one, and evidence that the two agree.
The findings that come out of a bad migration are the ordinary ones, arriving all at once: unreconciled balances carried forward, ledgers that don’t add up to the bank, unpresented items nobody can explain, and documents stranded in a system the agency can no longer open. Those are exactly the red flags that produce an adverse finding, and a migration is the most efficient way to generate several of them in a single afternoon. If your cutover is landing close to your deadline, our guide to preparing for a trust account audit is worth reading alongside this one.
The staffing problem nobody plans for
A migration is the worst possible time to be short-handed, and it’s very often the time agencies are. The trust accountant is learning a new system while running the old one. End of month arrives regardless. The project competes with the day job it’s supposed to improve.
That’s the real reason migrations go wrong. Not the software, and rarely the data. The work doubles for six weeks and nobody has six spare weeks.
We run trust account migrations between PropertyMe, Property Tree, Console, Ailo, Palace and REST, including the reconciliation either side of the cutover and the first month in the new system while your team finds its feet. If you’ve got a migration coming up, or you’re part-way through one that hasn’t gone to plan, get in touch and we’ll take a look.