Property management field mapping before a migration or integration

Updated July 2026

Start with entities and relationships: property, unit, owner, tenant, applicant, lease, recurring charge, ledger transaction, vendor, work order, document, and bank account. Name the authoritative system for each. Then map fields inside those objects. This prevents a convenient spreadsheet shape from becoming the data model.

For example, one platform’s “rent” field may store the current lease charge while another report’s “rent” column stores cash received. Copying between them without a definition can make the destination look complete while changing the meaning. Record the source report date and calculation rule before deciding where it belongs.

Use stable source identifiers and a crosswalk rather than matching only on names or addresses. Two tenants can share a name; units can be renamed; owners can hold multiple entities. Preserve old and new IDs so a later adjustment or document can still be traced to the correct record.

Dates need their own rules. Lease signing, commencement, possession, charge effective date, payment date, settlement date, and posting period answer different questions. Test month-end and amended leases explicitly. A destination default should never invent a business date merely to make an import pass.

Reconcile recurring rent, open tenant balances, unapplied credits, security-deposit liabilities, owner balances, unpaid bills, and bank or clearing accounts at a named cutoff. Compare totals by property as well as portfolio-wide; equal portfolio totals can conceal a value moved between properties.

Keep rejected rows in an exception file with source identity, reason, proposed repair, reviewer, and outcome. Do not silently turn blanks into zero, discard negative balances, or create a new vendor because a name did not match. Those shortcuts make the migration “complete” by hiding the records most likely to matter later.

The final mapping workbook or machine-readable contract should have an owner, version, approval date, source and destination versions, and change history. Freeze uncontrolled source edits during the final extraction window or record the delta that must be replayed.

After import, sample ordinary and difficult records: a simple active lease, an amended rent amount, a credit balance, an inactive resident with history, a returned payment, and a work order with attachments. Trace each backward to source evidence. Keep the prior system read-only until the reconciliation packet and open exceptions are accepted.

A one-time migration map can be frozen after acceptance, but a live integration needs monitoring for schema and business-rule changes. Record provider release notes, mapping version, last successful job or event, rejected-record count, and the owner of each change. Re-run a small fixture set before enabling a changed destination or transformation.

Schedule a periodic trace of one lease, one payment, one vendor bill, and one corrected record. Compare the destination with current source evidence and confirm that removed fields are not still retained downstream. Drift is easier to repair when the map and sample show exactly which version first changed the result.

A blank can mean unknown, not collected, not applicable, intentionally cleared, or inherited from another record. Those meanings are not interchangeable. For every nullable field, record whether the destination may stay blank, apply a documented default, derive a value, or stop the row for review. Preserve the source value and rule used so a reviewer can distinguish missing evidence from an intentional empty state.

Controlled values need the same discipline. Map lease status, payment method, charge type, work-order priority, and account class through approved crosswalks rather than free-text similarity. Define what happens to an obsolete or destination-only value. An unknown enum should create a source-identified exception; it should not fall into the nearest category merely because the import requires one.

Design correction before cutover. Keep the import batch identity, source extract, mapping version, created destination IDs, and before-state needed to reverse or replace a bad transformation. Financial corrections should use linked entries under the accounting policy rather than deleting history. For nonfinancial records, document whether rollback means removing newly created test records, restoring a prior value, or loading a corrected version after approval.

Identity and financial-control fields deserve first attention: property and unit IDs, lease parties and dates, recurring charges, open balances and credits, deposits, vendors, bank mappings, and source transaction IDs.

Names are useful for human review but weak as the only identity. Use stable source IDs and an approved crosswalk, then validate names, addresses, relationships, and dates as supporting checks.

Completeness requires more than every destination column having a source. Counts, control totals, relationships, edge cases, transformation rules, rejected records, and sampled provenance traces must also be accounted for.

It should define the meaning of the source state and an explicit destination action: preserve blank, apply a supported default, derive with a recorded rule, or hold the record as an exception. It should never convert missing evidence into zero or another plausible value silently.