PMS migration reconciliation: prove the balances survived the move
A field-level, balance-level, and evidence-level cutover method for small landlords moving leases, ledgers, deposits, documents, and operating history into a new property-management system.
11 min read
Updated July 2026
A software migration can be technically complete and operationally wrong. Rows arrive, totals look close, and the team starts using the new system—then an old concession reappears as rent, a deposit loses its tenant allocation, or a post-cutoff payment exists in only one place. Reconciliation is the control that separates “data moved” from “the new system can safely become authoritative.” Current PMS routes normalize supported exports into content-bound review staging with recorded hashes and review evidence. Approval does not create or change live portfolio records; a separately implemented, authorized, reconciled cutover is still required. OFX and QuickBooks Web Connect (.qbo) files can be parsed locally for format, date, amount, duplicate-ID, and unsafe-markup review. That preflight does not import, post, match, retain, or establish a QuickBooks Online API connection.
Define the controlled position before exporting anything
Write one migration sentence that a reviewer could test: “Move the active operating records for these legal entities and properties through 11:59 p.m. Eastern on July 31, including the listed history and attachments.” Name what is excluded, how post-cutoff activity will be handled, and which system is authoritative during the freeze, delta, and stabilization windows.
Build a record inventory before a field map. Count properties, units, active and future leases, open balances, refundable deposits, vendors, recurring charges, open work orders, documents, and event history. Counts are not reconciliation, but they expose missing categories and make it harder to discover after cancellation that a legacy export omitted attachments or inactive records.
Map meaning, not just column names
A source “balance” field can mean current amount due, all-time net charges, or a display figure after credits. A target field with the same label may calculate something else. For every high-risk field, record the source definition, target definition, transformation, null behavior, accepted values, effective-date rule, and reconciliation control.
Treat identifiers separately from labels. Tenant names, unit labels, and vendor names can repeat or change; stable source IDs and a crosswalk make corrections traceable. Keep old IDs in a migration reference field or retained crosswalk so a later dispute can connect the new record to its origin without guessing.
Use a three-way bridge for cash and deposit obligations
Compare the old system’s controlled closing balance with the new system’s opening balance for the same scope and time. Then connect the result to independent evidence—usually a reconciled bank statement plus documented outstanding items. Two systems can agree with each other and still be wrong, so the external leg matters.
Refundable deposits need both a control total and tenant-level detail. In a five-unit example, the source and bank may both support $6,840 while the target shows $6,740. The missing $100 could be unapplied cash, a deposit allocation, or a mapping defect. Record the exact tenant or transaction, cause, correction, and retest; do not post a portfolio-level $100 adjustment that makes the total look clean while leaving the resident record wrong.
Sample records by consequence, not convenience
Random samples help find ordinary defects, but a small landlord can often inspect every active lease and every open balance. Add risk-based samples: recently renewed leases, mid-month changes, concessions, partial payments, returned payments, roommates, transfers, deposit changes, open notices, recurring vendor bills, and records with attachments.
Test the target as a workflow, not only a database. Generate a tenant ledger, rent roll, owner statement, deposit report, payment batch, renewal list, open-work-order list, and export. A value can exist in a table yet be absent from the report or workflow the landlord will actually use.
Turn differences into an exception log
Each exception should name the source record and value, target record and value, effect, suspected cause, correction owner, correction method, retest evidence, and disposition. Grouping everything under “migration cleanup” destroys accountability and makes the same transformation bug look like dozens of unrelated manual errors.
Correct the earliest reliable layer. If the field map is wrong, fix the map and rerun. If the source record is wrong, document and approve the source correction before re-exporting. Use a target-side adjustment only when it represents a legitimate opening entry with durable supporting evidence—not as a way to force a control total.
Release, rollback, and stabilize deliberately
Define a rollback trigger before production: for example, an unexplained cash difference, missing active lease, inaccessible deposit detail, or failed payment-provider connection. Rollback may mean extending the legacy read-only window and pausing new activity rather than trying to reverse every imported row.
After go-live, perform a stabilization close using the first real payment, invoice, owner transaction, work order, and reporting cycle. Compare opening-to-closing movement in both operational and accounting records. Sign and retain the source export, target reports, bank evidence, exception log, approvals, and archive instructions as a single migration release packet.