Migrating PM Software Without the Horror Story
Published 9 August 2026 · 4 minute read
6–10
disconnected platforms commonly run by agencies
Indium market research
7 years
record-keeping requirement under AML/CTF obligations
AML/CTF Act 2006
Every principal knows a migration horror story, and every horror story has the same plot: nobody checked the data until it was live. The industry's response has been to stay on software it hates, which is how switching costs became the incumbent vendors' best product feature.
Why do PM software migrations go wrong?
Migrations go wrong for one dominant reason: the data was worse than anyone admitted, and nobody found out until after cutover. Years of workarounds accumulate in any system — balances "fixed" with manual adjustments, tenancies that ended in the real world but not in the software, bonds recorded in three inconsistent ways. Migration doesn't create these problems. It surfaces them, at the worst possible moment.
The second reason is treating migration as an IT project instead of an operational one. The software vendor moves the data; only your team knows which of it is true. Skip the humans and you get a technically successful migration of fiction.
The horror stories are mostly the same story
Strip the details and the horror stories converge: owner statements went out wrong in month one. Everything else — missing documents, confused tenants, staff overtime — is survivable. Wrong money is not, because a statement that doesn't reconcile converts a software project into a trust problem in the owner's mind.
That tells you where the paranoia belongs. Ledgers, balances and payment details deserve triple-checking; document libraries and historical notes can be tidied after cutover. Teams that spread their checking evenly across everything run out of care before they run out of ledger. Check the money first, the money second, and the money third.
Clean before you move, not after
The single highest-return activity in any migration happens before it: cleaning the source data. Archive dead tenancies. Chase and close phantom arrears. Reconcile every balance. Standardise the contact records that four staff entered four ways over ten years. Every problem fixed pre-migration is a problem the new system never contains.
There's a bonus most principals miss: this clean-up is valuable even if you never switch. Agencies commonly run six to ten disconnected platforms, and the clean-up forces you to discover which one actually holds the truth for each kind of record. Write that down. It becomes your migration map — and your operations manual.
What should a migration importer actually do?
A serious importer does three things: maps your old system's structures to the new one's, validates what it finds, and tells you what it couldn't confidently move — before cutover, in a report a human reviews. The report matters more than the import. An importer that swallows everything silently is moving your problems at high speed.
Indium's migration importer works this way because the platform is ledger-first: every balance has to reconstruct cleanly from transactions, so discrepancies in the source data get flagged rather than papered over. Migration into a ledger-first system is more demanding upfront and dramatically safer after — the system physically can't carry a balance it can't explain.
Run parallel where it counts, briefly
Full parallel running — operating both systems completely for months — is a myth nobody sustains; double entry collapses within weeks and the old system quietly becomes stale. What works is targeted parallel verification: for one or two cycles, generate owner statements and payment runs in both systems and reconcile them line by line. If the money matches for two consecutive cycles, the migration is sound where it matters most.
Keep read-only access to the old system afterwards. Historical questions will surface for months, and with AML/CTF record-keeping obligations running to seven years for agencies with sales operations, retention of the old records isn't optional anyway.
How do you protect owners and tenants through the change?
Tell owners before cutover, briefly and confidently: what's changing, what improves for them, what to check on their first new statement. An owner warned about a formatting change reads it with curiosity; an owner surprised by one reads it with suspicion. Tenants need less — new payment references, clearly communicated, twice — but get that wrong and rent lands in limbo during your most scrutinised month.
Then sequence sensibly: clean, import, verify the money, train the team on real data, cut over mid-month in your quietest period, verify the first statement run line by line. None of it is glamorous. That's rather the point — a good migration is the most boring project your agency will ever run.
Quick answers
How long does a property management software migration take?
The import itself is usually quick. The work is preparation — cleaning source data, reconciling balances, closing dead records — and verification afterwards. Sensible timelines are measured in weeks, dominated by checking rather than transferring.
What data matters most in a PM software migration?
The financial data: ledgers, balances, bonds and payment details. Wrong owner statements in month one are the classic migration disaster. Verify money line by line; documents and history can be tidied after cutover.
Should I keep access to my old software after migrating?
Yes, read-only. Historical questions surface for months, and record-keeping obligations — seven years under AML/CTF rules for agencies with sales operations — mean the old records must remain retrievable regardless.
Keep going
General information for Australian agencies, current at the date above — not legal or financial advice. Verify obligations against AUSTRAC guidance and your own advisers.