The three Yardi data and content products serve different downstream environments and operate under different constraints. The table below summarizes how they actually work, not how they are marketed.

YDC begins at the Yardi live database, the same database that Voyager and its ancillary products (leasing, accounting, maintenance, the Cafe portals) read and write to during normal operation. From that database, YDC uses SQL-style scripted reports as its data-extraction primitive. This is the same construct as YSR reports, which means existing standard reports can be repointed through YDC rather than rewritten.

Reports flow through an API user with administration controls applied. The API user is the governance boundary; access scope, refresh cadence, and audit are all controlled at this layer. From there, data lands in Power BI dataflows, which feed a semantic model. The model publishes as visual reports, paginated reports, and dashboards. Other connectors, Salesforce, finance systems, files, and applications can be added to the same workspace and joined into the same model.

Per Yardi's product documentation, YDC honors Voyager's property-level security and adds row-level and workspace-level protections in Power BI. The Voyager security model is preserved, and the Microsoft layer adds finer-grained controls on top of it. For multi-portfolio operators with overlapping access requirements, this two-layer model is materially different from a generic data-extract-and-transform approach.

Once data sits in the Microsoft Power BI / Fabric workspace, the broader Microsoft AI stack becomes available against the same model: Microsoft Copilot, Power Automate, machine learning workloads, and Fabric data agents. The semantic model built for dashboards serves as the grounding layer for AI agents, the same artifact used twice.

Replicate exists for a specific class of operators: those who have already invested in Snowflake, AWS, or Microsoft Azure and want raw Voyager data within those environments without rebuilding their analytics stack on Microsoft.

Per Yardi's official product documentation, Replicate is powered by Qlik and Microsoft Change Data Capture. The Qlik replication engine, combined with Microsoft SQL CDC, detects row-level changes in Voyager and streams them in near-real time to the destination warehouse. After an initial bulk load, only changed records flow downstream.

Operational characteristics

•  First-load throughput is large by design; billions of rows can be moved within a small number of hours, depending on portfolio size

•  Steady-state load is low, only deltas are streamed, which means no nightly batch window and minimal production impact

•  Replication tasks are configured per-table with control over schedule, target endpoint, and operational mode (real-time, batch, or hybrid)

•  Tasks can be started, paused, or stopped; logs capture lag, errors, and exception conditions

Supported endpoints

Per Yardi's official product documentation, Yardi Replicate works with Snowflake, Amazon Web Services (AWS), and Microsoft Azure. The underlying Qlik replication engine supports a broader range of targets in other Qlik deployments. Still, any target outside Yardi's published list should be scoped directly with Yardi before client commitments are made.

Replicate is available exclusively to Yardi private cloud clients. Operators on standard hosting cannot deploy it.

In the Yardi data strategy session, the segment that drew the most attention from consultants in the room was on ontology, a concept few of them had encountered in the context of real estate technology. The argument is straightforward and consequential.

A relational schema specifies that a tenant table joins a lease table via a foreign key. It does not tell a Large Language Model that anchor tenant implies a specific lease type with concentration-risk implications, that lease termination triggers downstream GL entries and audit obligations, or that CAM reconciliation is a year-end calculation governed by lease-specific clauses. Ontologies encode that semantic context.

Microsoft Fabric IQ Ontology: the practical implementation

Microsoft has implemented this concept in Fabric IQ Ontology (preview), part of the Fabric IQ workload. Per Microsoft Learn, the implementation flow is:

1. Build (or import) a Power BI semantic model

2. Generate an Ontology item from the semantic model, or build directly from OneLake-backed lakehouse tables

3. Bind entity types (Property, Lease, Tenant, GLEntry, etc.) to data, define properties, and configure relationship types

4. Once bound, downstream tools, Fabric data agents, Copilot, and custom AI agents query the ontology in natural language and return answers grounded in the underlying data

Microsoft documents specific constraints that should be flagged with clients: ontology supports managed lakehouse tables only (not external tables), and there are column-mapping limitations on delta tables with certain special characters in column names. The feature is in preview, not general availability.

Document AI in real estate fails for the same reason most real-estate AI fails: the underlying content estate is fragmented, untagged, and ungoverned. YDMS addresses this at the architectural layer rather than the application layer.

Microsoft 365 enforces multi-factor authentication on every interaction. YDMS includes a designed authentication handshake that completes the auth flow once and maintains the session, allowing users navigating from Voyager into a SharePoint-stored document to bypass repeated re-authentication. Without this handshake, document access becomes a friction point that drives users back to email attachments and shared drives.

Metadata stamping

Per Yardi's official YDMS brochure, every document automatically inherits Voyager-side context: property code, unit, tenant, lease, vendor, job, and other object types. OCR runs on stored documents; full-text indexing makes them searchable by tenant name, address, system code, or content. For multi-jurisdiction operators (Canada, Australia, the Middle East, Europe, the United States), localization settings flow through automatically.

Security stamping

Yardi user roles, property-level restrictions, and object-level permissions push to SharePoint sites, libraries, and folders from Voyager. The same model governs access in Voyager and access in SharePoint. A user without visibility to a property in Voyager cannot see that property's documents in SharePoint.

The compliance dividend

SharePoint sits inside the Microsoft 365 audit log, which records every document interaction: view, edit, share, search. For operators in regulated jurisdictions, including Canada (PIPEDA), the European Union (GDPR), Australia (Privacy Act), and the United Arab Emirates (data residency requirements), the audit log produced by YDMS is the difference between defensible compliance and a remediation project.

Each of the three Yardi data products carries a distinct engagement profile. Treating them as interchangeable is the most common scoping error. The categorization below reflects how engagements typically shape up across the Assetsoft delivery experience and is intended as a planning guide rather than a fixed quote.

Centered on semantic model design, DAX expression authoring, dashboard craft, and Copilot grounding. Smaller delivery teams, design-led typical duration of 6 to 12 weeks for a defined-scope deliverable. The most common pitfall is treating the dashboard as the goal rather than the semantic model. The dashboard is replaceable; the model compounds in value.

Replicate engagements

Centered on lakehouse architecture, schema-on-read patterns, downstream security configuration, and data engineering rigor. Larger delivery teams, architecture-led, with a typical duration of 3 to 6 months for the initial implementation, with ongoing engineering activity afterwards. The most common pitfall is underestimating the volume of downstream work. The warehouse landing zone is the start of the engagement, not the end.

YDMS engagements

Centered on SharePoint information architecture, retention policy configuration, eSignature workflow design, RPA via Power Automate, and SPFx custom application development. Hybrid delivery teams bridging IT and operations, with a typical duration of 8 to 16 weeks for the initial deployment, with ongoing optimization activity. The most common pitfall is treating YDMS as a storage migration rather than as a content governance project.

Yardi Data Connect (YDC) is a query-driven API that exposes Voyager data into Microsoft Power BI and Microsoft Fabric through a semantic model. Yardi Replicate is a real-time, table-level Change Data Capture stream that delivers raw Voyager data into Snowflake, AWS, or Azure (per Yardi's published support). YDC is the right fit for Microsoft-stack analytics and Copilot use cases. Replicate is the right fit for lakehouse and data-science workloads. Replicate requires Yardi private cloud; YDC does not.

As of early 2026, the Ontology item within Microsoft Fabric IQ is in preview, not general availability. Production rollouts should review Microsoft Learn's documented constraints, including the limitation to managed lakehouse tables and column-mapping restrictions on delta tables with special characters in column names.

Yes. Mature architectures combine YDMS as the content layer, YDC as the BI and Copilot layer, and Replicate as the raw data layer that feeds a non-Microsoft warehouse for data science teams. The three products serve complementary purposes and are commonly deployed in stages over a 12- to 24-month roadmap.

Virtuoso is Yardi's native AI platform that operates within Voyager. The three data and content products extend AI capability outside Voyager into the Microsoft Power BI and Fabric ecosystem (via YDC), into client-owned data warehouses (via Replicate), and into the SharePoint document estate (via YDMS). Virtuoso and the ABC stack are complementary deployments, not competing platforms.