Migrate from Yardi to Pipedrive

Yardi API access and export limitations affect extraction scope

Yardi Voyager's API access (7S API) requires licensing and technical configuration that not all customers have enabled. Breeze users may rely on report exports that cap field counts and do not expose all custom table data. If your Yardi setup uses custom tables (e.g., custom fields on tenants or properties defined in Custom Tables under the admin menu), those records require Yardi consulting engagement to expose via export. FlitStack AI audits your Yardi export capabilities before mapping begins and flags any custom table that cannot be reached via API or standard export — those objects surface in the migration plan as requiring manual data preparation or Yardi admin assistance.

Pipedrive custom fields use hash-key identifiers, not user-facing names

When you create a custom field in Pipedrive's UI (Settings > Data fields > Add field), Pipedrive assigns it a hash-key identifier (e.g., 3a2b1c8e4f5d...) that the API uses instead of the field name. Migrations that reference custom fields by name will fail — field mapping must use the Pipedrive field key, which requires querying Pipedrive's field metadata endpoint (/dealFields, /personFields, /organizationFields) to retrieve before data loads. We fetch Pipedrive field keys during the pre-migration audit, create destination custom fields programmatically, and use the returned keys in the load step so field assignment is accurate.

Yardi lease data has no native Pipedrive pipeline equivalent — custom stage mapping required

Pipedrive's Deal model assumes a sales pipeline with stage progression (e.g., Appointment Scheduled > Proposal Sent > Negotiation > Closed Won). Yardi lease lifecycle (Lease Sent > Signed > Active > Expiring > Expired) does not map to any built-in Pipedrive sales process. We model Yardi lease status as custom fields on the Deal (Lease_Status__c) and create a dedicated Pipedrive pipeline (e.g., 'Lease Pipeline') with stages that mirror your Yardi lease lifecycle — but this requires your team to configure the pipeline and stage names in Pipedrive before migration runs, since the stage values drive which records land in which stages during the load.

Pipedrive's per-seat pricing means migration costs scale with team size, not record count

Pipedrive's pricing model charges per user seat, not per record migrated. When migrating from Yardi — which charges per unit managed — teams often find that Pipedrive's per-seat cost diverges from their original budget assumption, especially if they plan to add CRM users beyond their current Yardi user count. We disclose this in the migration plan scope call and recommend confirming your Pipedrive seat count with your Pipedrive account manager before migration so the total cost of ownership estimate is complete.

Yardi's accounting ledger has no Pipedrive equivalent — rent payment history requires separate handling

Yardi maintains a full rent ledger: charges assessed, payments received, balances outstanding, late fee assessments, and concession applications. Pipedrive's CRM model has no accounts-receivable or ledger equivalent. We preserve a snapshot of each tenant's current ledger balance as a custom field on the Person record (Outstanding_Balance__c) and attach a formatted Note containing the last 12 months of payment history as reference text. However, ongoing rent accounting must remain in Yardi or move to dedicated property accounting software. FlitStack AI does not migrate the full Yardi accounting ledger — this limitation is disclosed upfront and reflected in the migration scope agreement.