CRM migration
Field-level mapping, validation, and rollback between Yardi and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Yardi
Source
Odoo CRM
Destination
Compatibility
11 of 12
objects map 1:1 between Yardi and Odoo CRM.
Complexity
BStandard
Timeline
3–7 days
Overview
Yardi organizes real estate data around properties, units, and leases — not CRM-style leads and opportunities. When migrating to Odoo CRM, FlitStack AI treats Yardi tenants and owners as res.partner records, converts lease stage values (New, Under-Review, Renewed, Terminated) into Odoo's crm.lead.stage_id pick-list, and stores property references as custom fields on the contact so Odoo users can trace any Yardi relationship back to its source. Yardi's export mechanisms — ySQL queries, Voyager custom reports, and the 7S API — feed a sequenced migration where contacts land before their associated lease records, owner resolution runs by email match against Odoo users, and a delta-pickup window captures any Yardi changes made during the cutover window. Workflows, rent-roll automations, and property-specific rules cannot migrate and must be rebuilt using Odoo Studio or server actions. FlitStack delivers a field-level diff against a sandboxed Odoo instance before committing the full run. FlitStack AI also preserves original creation timestamps on migrated contacts by storing them in a custom field, allowing reporting continuity. The migration process includes a sandbox validation run where data is loaded into a test Odoo environment, a field-level diff is generated, and any discrepancies are corrected before the production cutover.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Yardi object lands in Odoo CRM, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Yardi
Tenant / Contact
Odoo CRM
res.partner
1:1Yardi tenant records map directly to Odoo res.partner. Each tenant's name, email, phone, and address fields translate to partner fields in the same structure. Unmatched tenants without an email are flagged for manual review before insertion. FlitStack also tags each partner as 'Tenant', stores the original Yardi contact ID in a custom Char field, and checks for duplicate emails before insertion.
Yardi
Owner
Odoo CRM
res.partner
1:1Yardi owner records map to res.partner with a custom tag or partner_category set to 'Owner' so Odoo users can filter the partner list by role. Owner email is used for user resolution if the owner is also an Odoo system user.
Yardi
Property
Odoo CRM
Custom Char fields on res.partner
1:1Yardi properties have no direct Odoo CRM equivalent — the property name and Yardi Property ID are stored as custom Char fields on each associated res.partner record. This preserves the relationship without requiring Odoo Real Estate modules. FlitStack also creates a custom Char field for the property manager name when present in Yardi, allowing additional context to be retained on the partner record.
Yardi
Unit
Odoo CRM
Custom Char fields on res.partner
1:1Yardi unit references (unit number, building) are stored as custom Char fields (Yardi_Unit_ID__c, Yardi_Building__c) on res.partner. Units without a linked tenant become placeholder partner records with role 'Unassigned Unit' for reconciliation. These custom fields enable quick filtering of partners by unit or building, and they are indexed for reporting in Odoo's kanban and list views.
Yardi
Lease / Lease Status
Odoo CRM
crm.lead
1:1Each active or historical Yardi lease becomes a crm.lead record in Odoo CRM. The lease status (New, Under-Review, Renewed, Terminated) is mapped value-by-value to a corresponding crm.lead.stage_id. Lease metadata — rent amount, start/end dates, escalation clause — is stored in custom fields on the lead.
Yardi
Lease Status (value mapping)
Odoo CRM
crm.lead.stage_id
1:1Yardi lease status pick-list values are mapped to Odoo crm.lead.stage_id records: 'New Lease' → 'New', 'Under-Review' → 'Qualified', 'Renewed' → 'Won', 'Terminated' → 'Lost'. The mapping is configured before migration so stage_id is set correctly on lead insertion. If a lease status does not have a matching stage, FlitStack creates a new stage record in Odoo before loading leads, ensuring no foreign‑key errors.
Yardi
Vendor / Contractor
Odoo CRM
res.partner (with category)
1:1Yardi vendors map to res.partner with vendor_category_id set from Odoo's default vendor category. Vendor type (plumber, electrician, etc.) is preserved as a custom Selection field since Odoo stores vendor role as a category rather than a typed attribute. FlitStack also adds a tag 'Vendor' to each partner record to differentiate them from tenants and owners in list views and reporting.
Yardi
Work Order / Service Request
Odoo CRM
No equivalent in Odoo CRM
1:1Yardi work orders and service requests are property-maintenance records with no direct Odoo CRM equivalent. They are exported as a reference CSV for manual re-entry in Odoo Maintenance or a custom module if your plan includes that application. They do not migrate as CRM data.
Yardi
Rent Payment / Ledger Entry
Odoo CRM
No equivalent in Odoo CRM
1:1Financial ledger entries and rent payment history from Yardi do not map to Odoo CRM. They belong in Odoo Accounting if you are also deploying that module. FlitStack exports the payment history as a reference archive; the accounting module requires a separate migration run.
Yardi
Custom Table (Voyager)
Odoo CRM
Custom field or ir.model.fields
1:1Yardi Voyager custom tables are exported via ySQL and mapped to Odoo custom fields on the relevant model (res.partner or crm.lead). For each custom table row, FlitStack creates the ir.model.fields entry in the target Odoo database before loading data. The field definitions are applied through Odoo's XML‑RPC API, and any pick‑list values are also created as selection options to maintain data integrity.
Yardi
Yardi User / Staff
Odoo CRM
res.users (resolved by email)
1:1Yardi staff users are matched against Odoo res.users by email address. Unmatched Yardi staff are flagged as inactive Odoo users pending account creation. Owner assignment on migrated records uses this resolved user map. FlitStack records the mapping in a JSON file for audit purposes, and retries email matching after any bulk user import to capture newly created accounts.
Yardi
Association: Tenant ↔ Unit ↔ Owner
Odoo CRM
res.partner + custom fields
many:1Yardi's N-ary association chain (Tenant linked to Lease, Lease linked to Unit, Unit linked to Property, Property linked to Owner) is collapsed into a single res.partner record per tenant with Yardi_Property_ID__c and Yardi_Owner_ID__c stored as reference fields. No junction object is required in Odoo CRM.
| Yardi | Odoo CRM | Compatibility | |
|---|---|---|---|
| Tenant / Contact | res.partner1:1 | Fully supported | |
| Owner | res.partner1:1 | Fully supported | |
| Property | Custom Char fields on res.partner1:1 | Fully supported | |
| Unit | Custom Char fields on res.partner1:1 | Fully supported | |
| Lease / Lease Status | crm.lead1:1 | Fully supported | |
| Lease Status (value mapping) | crm.lead.stage_id1:1 | Fully supported | |
| Vendor / Contractor | res.partner (with category)1:1 | Fully supported | |
| Work Order / Service Request | No equivalent in Odoo CRM1:1 | Fully supported | |
| Rent Payment / Ledger Entry | No equivalent in Odoo CRM1:1 | Fully supported | |
| Custom Table (Voyager) | Custom field or ir.model.fields1:1 | Fully supported | |
| Yardi User / Staff | res.users (resolved by email)1:1 | Fully supported | |
| Association: Tenant ↔ Unit ↔ Owner | res.partner + custom fieldsmany:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Yardi gotchas
Lease fine print spans multiple related tables
No public REST API for data export
Chart of Accounts migration risk on Voyager
Yardi Breeze and Voyager use incompatible export formats
Posted period locks prevent retroactive edits
Odoo CRM gotchas
Odoo.sh version gating blocks assisted migrations from trial
Enterprise modules fail to install on Community after database restore
Custom module view inheritance breaks between Odoo major versions
Custom fields risk losing their application context on Community
API access for Community is gated behind the Custom Plan
Pair-specific challenges
Migration approach
Audit Yardi export surface and extract schema + data via ySQL or Voyager API
FlitStack connects to Yardi Voyager via read-only ySQL access or the 7S API to enumerate the full schema: all standard tables (Contact, Owner, Property, Unit, Lease), any custom tables defined in Custom Tables, and pick-list values for lease status. We export the full rowset into a staging directory, flag tables that have no Odoo CRM target (work orders, rent ledger), and produce a data-map document that names every Yardi field and its Odoo destination before any transformation code is written.
Pre-create Odoo custom fields and stage records via ir.model.fields and crm.stage API
Before any data loads, FlitStack creates the missing crm.lead.stage_id records that match Yardi lease statuses (New Lease, Under-Review, Renewed, Terminated). Then it creates the ir.model.fields entries for every Yardi custom table field targeting res.partner or crm.lead — using Odoo's xmlrpc/jsonrpc API so the fields are schema-visible immediately. This step is sequenced first because Odoo's import rejects records that reference fields not yet defined in the database.
Resolve Yardi users and owners to Odoo res.users by email match
FlitStack reads Yardi staff user emails and attempts to match them against existing Odoo res.users records by login (email). Unmatched users are listed for your Odoo admin to create before the migration run. Tenant and owner email matches are used to set the user_id on migrated records, preserving accountability in Odoo's activity log. This step is completed before any lead or partner records are inserted so every migrated record lands with a valid owner.
Migrate res.partner records (tenants, owners, vendors) with flattened Yardi associations
FlitStack inserts Yardi tenants, owners, and vendors as res.partner records in the correct order: vendors first (they have no inbound dependencies), then owners, then tenants. During tenant insertion, property ID, unit ID, and owner ID are written as custom Char fields on the partner record to preserve the full Yardi association chain. The migration runs in batches against Odoo's XML-RPC API, with a 429-retry backoff respecting Odoo's rate limits (typically 1 request per second per connection).
Migrate crm.lead records (leases) with stage_id and rent metadata, then run field-level diff
Each Yardi lease becomes a crm.lead record linked to the tenant's res.partner.id via partner_id. stage_id is set by value-mapping against the stage records created in Step 2. Rent amount, start/end dates, and deposit are written to custom fields on the lead. After the batch completes, FlitStack generates a field-level diff comparing source values against Odoo's read-back via the XML-RPC API, surfacing any mismatches for your review before the delta window opens.
Open delta-pickup window and capture in-flight Yardi changes before final reconciliation
With the full migration committed to Odoo, a delta-pickup window of 24–48 hours captures any Yardi records modified during the cutover — new tenants signed, lease renewals processed, owner contact updates. FlitStack re-runs the extraction against Yardi, diffs against the already-migrated records by Yardi_Contact_ID__c or Yardi_Lease_ID__c, and applies upserts (update if exists, insert if new). An audit log records every operation. One-click rollback reverts the Odoo database to the pre-migration snapshot if reconciliation uncovers unexpected data divergence.
Platform deep dives
Yardi
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. All 8 core objects map 1:1 between Yardi and Odoo CRM.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Yardi and Odoo CRM.
Object compatibility
All 8 core objects map 1:1 between Yardi and Odoo CRM.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Yardi: Not publicly documented. Yardi tunes rate limits per portfolio against the customer's licensing and usage controls and does not publish a request-per-minute figure. We confirm the throughput envelope with the customer's Yardi account team during scoping..
Data volume sensitivity
Yardi exposes a bulk API — large-volume migrations stream efficiently.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Yardi to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Yardi to Odoo CRM migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Yardi
Other ways to arrive at Odoo CRM
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.