How to Map Properties Units and Tenant IDs Before a Software Migration

Moving property records into new software is a relationship problem before it is a spreadsheet problem. A property can contain multiple units, a unit can have different occupants over time, and a person can appear in more than one role. If those relationships are flattened into a list of names and addresses, the new system may receive familiar information without receiving the structure that makes it useful.

A mapping worksheet gives each record a clear identity and shows how records connect. This guide describes a planning method you can use with a software provider or migration specialist. It does not prescribe a vendor's import format. Use the provider's current templates and instructions for the actual transfer, and treat the worksheet as a way to ask better questions and verify the result.

Start with record types rather than columns

List the kinds of things your existing system stores. Common examples include properties, units, contacts, owners, leases, vendors, and documents. Describe each type in ordinary language. A property might be a building, while a unit is a rentable space inside it. A contact is a person or organization, while a lease record describes a relationship for a particular period. Your current product may use different terms, so document its definitions before translating them.

Ask the destination provider which record types it expects and how it represents connections between them. Buildium's onboarding page describes assistance with property, unit, lease, owner, resident, and vendor data, illustrating why a migration may involve several related categories. The existence of an import service does not remove the need to explain your records. Confirm what the service includes and which details must be supplied, reviewed, or entered separately in your particular implementation.

Give every source record a stable reference

Use the existing system's record identifier when one is available and appropriate for export. If you must create a temporary reference for planning, label it as your own mapping reference and keep it unchanged throughout the exercise. A display name alone is a weak reference because names can be repeated or edited. An address alone may also be insufficient when multiple records use the same building address but refer to different units or relationships.

In a fictional example, property P104 contains units U104A and U104B. Contact C207 is associated with a lease record L301 at U104A. These invented codes are simply illustrations of separate identities, not a required naming convention. The useful feature is that changing the contact's display name would not change the unit's identity. Your mapping worksheet should preserve that separation even if the destination system generates completely new identifiers after import.

Build a crosswalk between old and new

Create a worksheet with source record type, source identifier, source display label, destination record type, destination identifier when known, and review status. Add an explanation column for exceptions. Before migration, the destination identifier may be blank. After a test import, fill it with the assigned value and verify the connection. This old to new crosswalk lets you trace a record without relying on someone to remember how it was renamed during cleanup.

Keep the crosswalk separate from the original export and from the file prepared for import. The original is evidence of what you started with. The import file reflects changes required by the destination. The crosswalk explains the relationship between them. Combining all three purposes into a single constantly edited spreadsheet makes it harder to tell whether a difference originated in the source, in your preparation, or in the receiving software.

Resolve property and unit boundaries

Review buildings that share an address, properties with multiple entrances, and units with similar labels. Write down whether your operational records treat them as one property or several, then ask how that structure should appear in the new system. Do not merge records merely because a mailing address matches. Conversely, do not create additional properties simply because staff have used different abbreviations for the same building in separate spreadsheets.

Rentec Direct's property setup documentation distinguishes adding properties and notes that user permissions can affect access to that action. That is a reminder to confirm both the destination structure and who can create it during your project. A migration review should include an authorized person who understands the buildings, not only someone who can manipulate a file. A technically valid import can still represent the portfolio incorrectly if the underlying boundaries were misunderstood.

Separate people from occupancy history

A person and an occupancy record answer different questions. The person record identifies a contact; the occupancy or lease relationship explains where and when that contact belongs. Ask how the destination handles a returning resident, a roommate change, and a person connected to multiple units over time. You are evaluating data organization, not deciding anyone's legal status. The provider should explain the record model so you can map your existing history accurately.

Use fictional examples to reveal these distinctions. One sample contact might leave a unit and later return to another unit. Another example might involve two contacts associated with the same occupancy period. Check whether the proposed mapping preserves both the shared relationship and the separate identities. If you create a fresh person record for every event without understanding the system, you may make future contact searches and historical reviews unnecessarily confusing.

Preserve original labels during cleanup

Standardizing labels can make records easier to read, but keep the original value in the crosswalk or supporting notes. If Apt Two becomes Unit 2, document the change and the reason. Do not silently remove punctuation or leading zeros from identifiers merely because the new display looks cleaner. A field used as an identity reference deserves different treatment from a field used only as a human readable description.

Set simple rules for ordinary cleanup before several people start editing. Decide how to represent missing values, how to record a disputed match, and who can approve a merge. When a record cannot be confidently mapped, place it in an exception list rather than assigning the most plausible destination. An unresolved row is visible work. A confident looking but incorrect match can spread the mistake into documents, communications, and later exports.

Map relationships explicitly

For each unit, identify its parent property. For each occupancy record, identify the associated unit and contacts. For each document, identify the record it belongs to and any period it describes. These links may appear as identifiers in a file, as separate association tables, or as fields managed by the vendor's migration service. Ask for the supported method instead of inventing a spreadsheet layout that merely looks reasonable to your team.

Review records with more than one relationship carefully. An owner may connect to multiple properties; a vendor may serve several buildings. Duplicating the contact for each connection might be necessary in some designs and inappropriate in others. The point is to understand the destination model before choosing. Your mapping notes should say whether the apparent repetition represents duplicate identity, a valid relationship, or an unresolved question that requires provider guidance.

Run a narrow test import

Select a small, representative set of fictional or appropriately controlled records for a trial. Include a simple property, a property with several units, and at least one relationship that previously caused confusion. Agree with the provider on how test records will be isolated and removed. Do not use a live account casually if invitations, notifications, charges, or other actions might be triggered by the import process.

After the trial, inspect the records in the destination interface and export them if possible. Trace a contact to the correct unit and property, then trace a document back to its intended record. Compare the result with your crosswalk. Record the actual destination identifiers rather than assuming they match the source. A successful import message is useful evidence that a file was accepted, but it is not sufficient evidence that every relationship is correct.

Reconcile exceptions before the full transfer

Count records by type and compare expected relationships. A total number of contacts cannot tell you whether one contact was connected to the wrong unit. Review missing parent references, unexpected duplicate identities, and records that were skipped. Ask whether the import process updates existing entries, creates new ones, or behaves differently depending on a field. That answer matters if you need to correct and rerun part of the transfer.

Maintain an exception log with the source identifier, issue, proposed resolution, reviewer, and final outcome. Resolve ambiguous identities with the appropriate source documents or knowledgeable staff. Avoid treating a software vendor as the authority on who your records represent. The vendor can explain the product's structure and import behavior, while your team must verify the meaning and accuracy of the underlying operational information.

Keep the crosswalk after migration

Once the move is complete, preserve the mapping worksheet with the original exports, import files, and review notes under appropriate access controls. Record the transfer date and the scope of included history. If a question arises later about an old identifier, the crosswalk can point to the corresponding new record. Without it, staff may have to reconstruct the migration from display names that have already changed again.

The practical test is straightforward: can another authorized person start with an old record and locate its correct destination without guessing? If the answer is yes across your representative cases, the mapping is doing its job. Good migration preparation makes identities and relationships explicit, keeps uncertainty visible, and gives the receiving system a structure that reflects the portfolio you actually manage.

If Buildium is on your shortlist, use the crosswalk to discuss your migration scope with its team. Ask which relationships the proposed import will preserve and how you will review exceptions before committing to a transfer.