Migrate from Yardi to Microsoft Dynamics 365 Sales

Yardi API access requires Voyager 7S or Yardi Breeze REST authentication, not a standard OAuth flow

Yardi does not expose data via a conventional REST or Graph API with OAuth 2.0. Voyager uses ySQL queries against the database, and Yardi Breeze uses a proprietary REST interface with per-user API key authentication. FlitStack AI connects to the Yardi tenant via ySQL for Voyager setups (requiring read-only database credentials) and via Breeze REST endpoints with API key for Breeze tenants. API rate limits in Yardi Breeze are per-user and throttled during business hours; we schedule bulk exports during off-peak windows to avoid hitting quotas. If the Yardi tenant lacks API access, FlitStack can use Yardi's custom report export feature with CSV extraction, but this requires Yardi admin involvement to configure the export template. The read access limitation is disclosed upfront during the discovery call.

Custom Dataverse entities for RealEstateAsset and RealEstateLease require Dynamics 365 Sales Enterprise licensing

Dynamics 365 Sales Professional caps custom table creation at 15 tables total across the environment. Yardi migrations that require a RealEstateAsset custom entity plus a RealEstateLease custom entity plus supporting custom fields will exceed the Professional limit. FlitStack AI surfaces this during discovery — if the destination tenant is on Sales Professional licensing, we recommend either upgrading to Sales Enterprise (required for more than 15 custom tables) or collapsing property references into custom fields on the Account entity. The Dynamics 365 Licensing Guide confirms that Sales Enterprise ($105 per user per month) removes the custom table ceiling and enables unlimited Power Platform extensions. We do not begin migration until the licensing tier is confirmed.

Lease data has no operational equivalent in Dynamics 365 Sales — it becomes a reference record, not a working object

Yardi lease records contain rent escalation clauses, security deposit tracking, and renewal options that have no native field in Dynamics 365. Migrating them as custom fields on the Contact or as a RealEstateLease custom entity preserves the data for reference but does not create working lease management functionality. Dynamics 365 Sales is not a lease management tool — if the team needs rent reminders, escalation automation, or lease renewal workflows, those require Power Automate flows built post-migration. FlitStack exports the complete lease data structure from Yardi as a JSON audit file alongside the migration run so the Dynamics admin can reference the full lease schema when building flows. We do not claim to replicate Yardi's lease management logic in Dynamics 365.

Yardi contact-to-property associations require N:1 resolution in Dynamics 365's AccountId model

Yardi allows a contact to be associated with multiple properties simultaneously (an owner with five buildings, a tenant who rents two units). Dynamics 365 Contacts have a single primary AccountId lookup. We resolve the N:1 constraint by assigning the most recent lease or highest-ownership-percentage property as the primary AccountId and linking remaining property associations via the RealEstateAsset custom entity's lookup field on the Contact record. This preserves the full property association history while satisfying Dynamics 365's schema requirement. Teams should verify that the primary account assignment rule aligns with their sales process before the migration runs.

Payment history and accounting data cannot populate Dynamics 365 financial records without a separate ERP integration

Yardi payment history (rent received, late fees, security deposit transactions) is accounting data. Dynamics 365 Sales does not contain a GL, accounts receivable, or payment tracking module — those belong to Dynamics 365 Finance or Dynamics 365 Business Central. We migrate payment history as records in the custom LeasePayment entity for reference and reporting purposes only. The data cannot create invoices, post to the GL, or trigger Collections Cases without a separate Business Central integration. We disclose this limitation in the migration plan and can recommend a Power Automate flow that creates a Task on the Contact when a payment record indicates a delinquency flag.