Migrate your Yardi data

Properties are the top-level container in Yardi. We migrate property records with address, type, and classification. Breeze stores basic property metadata; Voyager stores extended asset-level fields. Both are well-structured and export cleanly via the standard query interfaces.

Units belong to Properties and carry fields like unit type, sq footage, market rent, and occupancy status. We map Units 1:1 and preserve the parent Property linkage during migration. The unit-level rent and status history requires a separate table extraction.

Yardi calls tenant records Residents. We extract contact details, lease association, payment history, and balance. Resident screening results stored in Yardi Breeze originate from third-party integrations and may not always be in the primary tenant record.

Leases are migration-critical and complex. Base lease terms (start/end dates, rent amount) are straightforward, but escalation clauses, concessions, addendums, and renewal options are stored across multiple related tables that must be joined. We explicitly scope which lease sub-records to include during the planning call.

Owner records vary significantly between Breeze and Voyager. Voyager stores ownership percentages, investor classifications, and capital contribution histories that Breeze does not. Where the destination does not have a native Owner object, we map Owner data into a Company or Contact record with a custom Owner flag property.

Vendor records include company name, contact info, W-9 status, and categories. We migrate vendors and preserve vendor-to-property associations. Voyager vendors with multi-entity access require mapping which entities they are permitted to bill against.

Work orders are supported in both Breeze and Voyager but have different field sets. Voyager tracks work orders at both the property and unit level with detailed cost tracking; Breeze uses a simplified workflow. We map to the destination work order object and flag extended Voyager fields that may not transfer.

The Chart of Accounts is enterprise-critical and migration-sensitive. Voyager supports complex multi-entity accounting; accounts may be entity-specific or consolidated. We flag accounts with non-standard naming or inactive status before migration to prevent chart-of-accounts bloat in the destination system.

Rent payments, charges, and vendor payments are stored with GL implications. Historical transactions require careful sequencing because Yardi locks posted periods. We scope the transaction date range during planning and flag any open AP/AR that must be reconciled before migration.

Custom Tables are defined in the Admin menu and house customer-specific fields not part of the standard schema. These require manual schema inspection before migration because there is no auto-discovery endpoint. We treat each Custom Table as a unique mapping exercise.

User accounts carry role assignments and property-level permissions. Voyager's Dynamic Ownership feature allows granular field-level access that most destination systems cannot replicate natively. We map users and role names but note permission granularity as a post-migration configuration item.