A property management database accumulates history. Former residents, sold properties, inactive owners, expired vendors, closed work orders, and completed leases remain because they explain what happened and may still be needed for reporting, disputes, tax work, or retention obligations.
The problem is not that historical records exist. It is that a move-everything migration can place them into the same active workflows as current residents, owners, and vendors.
The new PMS starts with a complete row count and an unclear operating model.
Historical data becomes pollution when lifecycle context is lost
A former resident with a closed balance is different from a former resident with an unresolved deposit. A vendor with no invoices in eight years is different from a vendor attached to a current warranty claim. A sold property may be operationally inactive while its financial and legal history remains important.
The issue is not age alone. It is whether the target can distinguish retained history from records that should drive current workflows.
“Active” is not one field
Legacy status flags are often incomplete or inconsistently maintained. Lifecycle classification should combine evidence from the entity and its relationships.
| Entity | Signals that may keep it operational | Signals that support historical treatment | Reasons to hold for review |
|---|---|---|---|
| Resident | Active lease, balance, deposit, open work order, pending notice | Move-out complete, zero balance, no open relationships, retention met | Unreturned deposit, dispute, conflicting move-out status |
| Owner | Current property interest, payable balance, active management agreement | No current properties or balances, closed relationship | Pending distribution, ownership transfer, unresolved tax reporting |
| Vendor | Open invoice, current contract, warranty, insurance requirement | No recent activity and no open obligations | Duplicate tax identity, incomplete payment history, active claim |
| Property or unit | Managed portfolio, active residents, financial activity | Sold or decommissioned with closed books | Historical balances, ongoing litigation, incomplete handoff |
Lifecycle strategy has three outcomes—not delete or keep
A defensible migration typically needs at least three classifications:
- Active: load into the target’s operational model because the record participates in current workflows.
- Historical: retain through a target archive, read-only legacy environment, governed repository, or another approved access path.
- Review: hold when evidence conflicts or a financial, legal, or operational obligation remains unresolved.
“Exclude from active migration” must never be interpreted as “safe to delete.” The archive location, access method, retention period, security controls, and eventual disposition need explicit owners.
Rules should be entity-specific and explainable
A simple rule such as “last activity older than three years” is easy to run and easy to get wrong. A resident can have no recent activity but an outstanding deposit. A vendor can be inactive but attached to records required for financial reporting. A property can be sold while related documents remain under retention.
Rules should reflect how each entity participates in the business. For example, a former resident might qualify for historical treatment only when the lease is closed, the move-out workflow is complete, balances and deposits reconcile to zero, there are no open disputes or work orders, and the approved retention rule allows it.
Each classification should carry the evidence that triggered it. That allows a reviewer to understand and override the decision without reverse-engineering a script.
The archive must remain usable
An archive is not successful merely because files or database dumps exist somewhere. The organization should know how an authorized user can locate a historical resident, retrieve supporting documents, reconstruct a ledger, and connect archived records to their original source IDs.
Before go-live, test representative retrieval scenarios. If an accounting team cannot answer a historical owner or resident question without restoring a database backup, the archive plan is incomplete.
Summary migration can preserve totals while losing evidence
Some targets support opening balances or summarized historical entries. These can be useful when detailed transactions do not belong in daily operational views.
A summary is not a replacement for source history. It should reconcile to the archived detail and retain a reference to the source period, entities, and calculation. Otherwise, the target shows a balance without a defensible explanation of how it was produced.
Reconcile all three populations
Validation should account for every source entity, not only the records loaded actively. The migration manifest should report:
- Source counts by entity and lifecycle state.
- Counts classified as active, historical, and review.
- Financial totals and open obligations in each group.
- Relationships that cross classifications.
- Approved overrides and their evidence.
- The archive destination and retrieval method.
The equation must close: every source record receives a visible outcome.
A clean launch is a scope decision, not a purge
Elvity’s PropTech data onboarding platform evaluates lifecycle signals across entities and relationships, applies customer-approved rules, stages proposed historical records for review, and reconciles active, archived, and unresolved populations before target loading.
The goal is not to migrate less data for its own sake. It is to place each record where it can be retained appropriately without distorting the workflows of the new system.
A fresh start should give current operations clarity while keeping history available, governed, and explainable.
Give every legacy record an explicit outcome
See how Elvity separates active operations from retained history without turning migration scope into silent deletion.