How to switch property management software without losing data
A migration checklist — what to export, what to verify, and how to move without a gap in rent collection or a hole in your records.
6 min read
Updated July 2026
The fear that keeps landlords on software they have outgrown is migration: the worry that moving means losing history or missing a rent cycle. It does not have to. With a short checklist and a little sequencing, you can switch cleanly and keep every record.
Export everything before you touch anything
Before you set up anything new, pull a complete export from your current tool. You want your properties and units, your active leases and tenant contacts, your ledger history, and any documents on file. Keep these exports as your source of truth for the move — and as a safety net if anything looks off later.
Sequence the cutover around the rent cycle
Time the switch so it does not fall across a rent due date. Set up the new system and get tenants onto it after one month's rent has cleared on the old one and before the next cycle begins. That gap is your clean cutover window — no tenant pays into two systems, and no cycle is missed.
Verify, then run in parallel briefly
Once your data is in the new system, spot-check it against your exports: do the balances match, are the leases right, did the documents come across. Running both systems in parallel for a short overlap lets you confirm the first rent cycle collects correctly before you fully retire the old tool.
Build a field map and record authority before importing
List each source field, its meaning, format, identifier, sign convention, allowed values, null behavior, target field, transformation, and acceptance test. Similar labels can mean different things: “balance” may be an amount due, lifetime net, deposit liability, or owner cash position. Preserve stable source IDs in a crosswalk so two people or units with similar names do not merge.
Decide which system is authoritative for leases, tenant contact details, ledger history, documents, vendor records, bank state, and communication during each cutover phase. Freeze or log changes after the export cutoff. If both systems remain editable without a defined owner and delta process, parallel operation creates divergence rather than safety.
Reconcile totals and record-level detail before release
Compare population counts, control totals, and individual records. Tenant receivables, credits, security-deposit obligations, cash, vendor payables, owner balances, recurring charges, and open work orders each need their own schedule. Equal portfolio totals can conceal one omitted receivable and one omitted credit or balances attached to the wrong lease.
Tie bank balances to reconciled external statements, not merely old and new internal reports. Sample active, inactive, zero, negative, future-dated, transferred, and document-heavy records. Every exception needs a reason, affected records or amount, consequence, owner, correction method, due date, and retest result. Unexplained cash or deposit differences and missing active obligations should block release.
Design rollback, archive access, and the first live-cycle test
Before cutover, define who can stop the release, how payment and message entry points will be controlled, which source remains available, and how changes made during rollback will be reconciled. Preserve immutable exports, checksums or integrity records, reports, field maps, exception logs, approvals, and retrieval instructions. Test the archive with someone who did not perform the migration.
During the first live cycle, trace a rent charge, payment, return, vendor invoice, adjustment, owner transaction, document retrieval, and resident communication from initiation to final record. Reconcile opening balance plus live activity to ending balance. Retire the old system only after blocking exceptions clear, the archive is retrievable, and the responsible owner signs the release packet.
Give residents, owners, and staff one controlled transition path
Prepare role-specific communication that states what is changing, the effective date, the one approved sign-in and payment destination, how existing autopay authorization is treated, what action the recipient must take, how identity will be verified, and where to report a problem. Do not ask residents to trust an unexpected bank-detail change based only on an email; use previously established channels and anti-fraud verification.
Track delivery, failed invitations, incomplete enrollment, payment-method status, and support ownership without exposing private records across households. Reconcile every tenant and owner to a transition state before the old portal closes. A clean data import can still fail operationally if a resident pays through an obsolete link or a staff member continues entering leases in the retired system.
Frequently asked
See it in the product