Every software demo covers data migration. Properties, owners, tenancies, documents, photographs — the vendor will show you a tidy import and a timeline, and most of the time they will deliver exactly that.
What the demo does not cover is the part that actually goes wrong. Your trust account has to stay reconciled, balanced and auditable across the cutover, and it has to do so 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 photograph is an annoyance. A migration that leaves your ledgers a few hundred dollars out of balance is a trust account discrepancy, and it will still be there when your auditor arrives.
Here is what to get right.
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. Immediately after a completed end of month, the picture is as close to 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 must be finished, not nearly finished. That means the final month is fully reconciled, the bank reconciliation agrees, disbursements have run, and there is no unallocated money sitting in a suspense or holding ledger waiting to be worked out later. Whatever you have not resolved in the old system, you will inherit in the new one — with less information to resolve it.
Aligning the cutover to your audit year end is a nice-to-have, not a requirement. A mid-year migration is perfectly normal and perfectly auditable, provided 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 sits 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 sum of all ledger balances must equal the trust bank balance, adjusted for unpresented items, on day one. If that three-way agreement does not hold on the first day, it will not hold on the thirtieth, and you will 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 the treatment before the migration, not after. The cleanest approach is to clear as many as possible before cutover; whatever remains 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 is no central bond authority at all and deposits stay in your trust account for the life of the tenancy, so an NT portfolio carries a large balance of trust-held bond money that a New South Wales portfolio simply does not. Bonds mid-claim at cutover deserve a list of their own, tracked manually until each one lands.
4. Paid-to dates and part payments. If rent paid-to dates arrive wrong, your arrears report is fiction from day one — either inventing arrears that do not exist, which your property managers will chase and your tenants will resent, or hiding 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 mode 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 must be able to show an auditor a continuous record of every trust transaction, including the ones that happened in software you no longer subscribe to. Before the old system is switched off — and read-only access after cancellation is a courtesy, not a guarantee — 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 is not your record-keeping obligation. That obligation 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 it does not 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 here: changing software is not changing your trust account. If the account itself stays open, there is no regulator notification to make. If you are also opening a new trust account, or closing an old one, that is a separate regulatory event with its own forms and its own deadlines — and it is worth doing as a distinct project rather than bundling it into a software migration.
The first month in the new system
Reconcile daily for the first cycle, even if your normal rhythm is monthly. This is the single highest-value 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. Sum of ledgers agrees to the bank, adjusted for unpresented items.
- 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 received 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 doing neither properly. The version worth doing is a reconciliation-only parallel — verify balances and 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 in the middle of that trail, and the auditor will look directly 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 do not sum to the bank, unpresented items nobody could explain, and documentation stranded in a system the agency no longer has access to. 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 is very often the time agencies are. The trust accountant is learning a new system while running the old one, end of month arrives regardless, and the project is competing with the day job it is supposed to improve.
That is the actual reason migrations go wrong — not the software, and rarely the data. It is that 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 as part of our trust accounting service, including the reconciliation either side of the cutover and the first month in the new system while your team finds its feet. If you have a migration coming up, or you are part-way through one that has not gone to plan, we are happy to take a look.