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.

Walk into almost any real estate operator running Yardi Voyager, and you'll find the same picture: data scattered across Voyager, Salesforce, Procore, and Excel exports living on someone's OneDrive; documents in shared folders no one has opened in two years; and a leadership team asking why they don't have an “AI strategy” yet.

You cannot bolt a Copilot onto that. Or rather, you can, and you'll get hallucinations, broken citations, and a very expensive disappointment.

The ABC framing introduced by Nagesh Nagaraj in his Yardi Data Strategy session addresses this directly. Before AI does anything useful on Yardi, three layers must be in place:

•  A — AI-ready architecture and integration (how data leaves Voyager and reaches your warehouse, lake, or BI tool)

•  B — Business Intelligence (semantic models and the ontology that lets a model actually reason about your portfolio)

•  C — Content management (documents, leases, and contracts in one searchable, governed place)

Get ABC right, and artificial intelligence on Yardi starts to behave more like absolute intelligence answers grounded in your data, your documents, your portfolio. Skip ABC, and no model Virtuoso, Copilot, Claude, Gemini, or otherwise, can save you.

What it is: Yardi Data Connect is a secure, query-driven API that pipes Voyager data into Microsoft Power BI and the Fabric ecosystem. It aggregates Voyager data alongside third-party sources (Salesforce, Procore, Excel, finance systems) into a single semantic model.

Why it matters for AI: Once data lands in Power BI / Fabric, the entire Microsoft AI stack opens up Copilot, Power Automate, machine learning, and crucially, ontology. Modern AI doesn't reason well over raw tables; it reasons over ontologies relationship graphs that describe how properties relate to leases, leases to tenants, tenants to GL entries. Fabric can convert a tabular model into an ontology with a click. That ontology gives a Copilot the context to answer questions like “which anchor tenants in Ontario are within 90 days of expiry and below market rent?”

Practical strengths:

•Works with existing Microsoft Azure / Power BI / E5 licensing, with no new platform fees.

•Inherits both Yardi security (property-level, object-level) and Microsoft security (Entra, audit logs).

•Supports incremental, ad-hoc, and scheduled refreshes; you hold the keys.

•Comes with a starter pack of pre-built dashboards.

•Does not require a private cloud, a major reason it's the pragmatic starting point for most clients.

When to pick YDC: Microsoft-shop clients, query-driven analytics, multi-source aggregation (Yardi + non-Yardi), executive dashboards, and any client whose end goal involves Copilot or Fabric AI.

What it is: Yardi Replicate, powered by Qlik, performs real-time Change Data Capture (CDC) from Voyager into the data warehouse of your choice, Snowflake, AWS, BigQuery, Databricks, or Azure. Instead of nightly batch exports, only changed rows stream to your target. The first load can move billions of rows in a couple of hours; after that, updates are near-instant with negligible production impact.

Why it matters for AI: Many large operators have already invested in Snowflake or Databricks and built medallion-architecture lakehouses. They don't want to rebuild in Microsoft. Replicate gives them raw, table-level Voyager data inside their existing warehouse, where data science teams can run feature engineering, ML pipelines, and LLM-grounded retrieval.

Important constraints:

•  Private cloud only. Replicate is exclusive to Yardi private cloud clients because Qlik runs inside the Yardi-managed environment.

•  Raw data, no built-in security layer. Replicate the ships table-level data; security and governance are downstream on the client (or their consulting partner).

When to pick Replicate: Existing Snowflake / AWS / Databricks investment, large lakehouse architecture, real-time analytics needs, data science teams that want native control of the schema, and private-cloud Voyager clients.

Most operators don't have to choose forever. We routinely see hybrid architectures, YDC for the BI / Copilot layer, and Replicate for the data-science layer.

This is the part the market still under-appreciates. There is no clean line between BI and AI. Under the hood, a Power BI semantic model and an AI-ready ontology are the same artifact viewed differently. The relationships, calculated measures, and security boundaries you build for a dashboard are the exact context an LLM needs to answer questions about your portfolio without making things up.

That means every dashboard built today on YDC is double-duty: an operational deliverable and a grounding source for tomorrow's AI agents. Investing in a clean Power BI semantic model now is investing in your AI roadmap, even if “AI” isn't on this quarter's plan.

This is also where Nagesh's Token Improvement Plan matters, only half a joke. Sending every operational question through a frontier LLM is the equivalent of eating at a fancy restaurant three meals a day. Cached BI dashboards, mobile alerts, and pre-computed KPIs handle 80% of recurring questions at zero token cost. Reserve LLM-driven analysis for the genuinely novel questions.

What it is: YDMS replaces Yardi's proprietary document repository with Microsoft SharePoint Online as the storage backend, while preserving full Yardi-side context. Property codes, lease addresses, anchor-tenant flags, and account references all flow through as SharePoint metadata automatically. Yardi property-level and object-level security stamps onto SharePoint sites, libraries, and folders without manual configuration.

Why it matters for AI: This is where the often-quoted truth lands hard: AI is only as good as your documents. Leases, MSAs, board decks, audit packs, vendor contracts. If those documents live in five silos with no metadata, no AI agent can retrieve them reliably; garbage in, hallucinations out.

YDMS solves this by:

• Auto-tagging every document with Yardi metadata at ingestion (property, lease, GL account, vendor, lifecycle status)

• Auto-applying security so a user who can't see a property in Voyager can't see its documents in SharePoint either

• Eliminating the “final_v3_REAL_FINAL.docx” problem with version history and co-authoring

• Opening the door to Copilot, Power Automate, and SPFx custom apps that search across millions of documents in seconds, with citations back to the source file

The compliance angle is non-trivial. Every click in Microsoft 365 is logged. For operators in regulated jurisdictions, such as Canadian PIPEDA, EU GDPR, Australian Privacy Act, and UAE data residency, the audit trail is the difference between a clean compliance review and a six-month remediation project.

In the Virtuoso deep-dive session led by Aaron Cabelli (Senior Product Manager) and Joe Consolo (Industry Principal), Yardi laid out Virtuoso as a five-layer AI platform: Native AI Agents woven natively into the product, an Assistant for help and actions, Premium Agents for actions and automation, a Composer for build-and-automate workflows, and an Insights layer for ask-and-analyze. It's powerful, native to Voyager, and it's the right tool for many in-Voyager workflows.

But Virtuoso operates inside Yardi. The moment your AI use case crosses out of Voyager into your warehouse, your SharePoint repository, your Salesforce, your Procore, your investor portal, you need the ABC layer underneath. YDC, Replicate, and YDMS are the rails Virtuoso (and any other AI you bring) will eventually run on.

The same point came up in the AI Roundtable that closed the briefing featuring Brian Sutherland (VP), Shivani Kumar (Industry Principal), Joe Consolo, and Aaron Cabelli. The recurring theme across operator questions: AI wins in real estate aren't won at the model layer. They're won at the data, document, and governance layer underneath.

Virtuoso is the fancy restaurant. ABC is the kitchen, the supply chain, and the food-safety regime. You need both, and you definitely need the kitchen first.

This is the gap most real estate operators hit. They license YDC or Replicate, sometimes YDMS, and realize the products are foundations, not finished solutions. Someone has to:

•  Design the semantic model and ontology so it answers the questions leadership actually asks

•  Implement the medallion architecture downstream of Replicate so the lakehouse doesn't become a swamp

•  Configure SharePoint sites, libraries, retention policies, and metadata schemas across jurisdictions

•  Build the Power Automate flows, SPFx apps, and Copilot agents that turn the foundation into productivity

•  Govern the whole thing, security, compliance, audit, and AI usage policy

Assetsoft has been doing exactly this work since 2012. As a Yardi-specialist consulting firm with delivery teams across Canada, India, Sri Lanka, and the U.S., Assetsoft implements the ABC layer end-to-end for clients in Canada, the U.S., Australia, New Zealand, Singapore, the UAE, and APAC, then layers AI use cases on top.

In parallel, companies like KriyaGo — The Operating System for Real Estate sit above Yardi, MRI, Procore, ViewPoint, CMiC, Concur, and Zoho, with 100+ integrations, automating cross-platform workflows that pure Yardi consulting cannot reach. For operators with mixed ERP estates (common after acquisitions), KriyaGo plus the Yardi ABC stack is what an AI-ready operating model actually looks like.

If you're on Yardi and being asked for an AI strategy, here's the sequence that actually works:

1. Start with C. Deploy YDMS first. No AI roadmap survives a chaotic document estate, and this is the highest-leverage, lowest-risk move.

2. Layer in A. Choose YDC if your stack is Microsoft-centric, Replicate if you're on Snowflake / AWS / Databricks. Many operators eventually run both.

3. Build B intentionally. Treat dashboards as the substrate for Copilot and Virtuoso, not one-off deliverables.

4. Then layer AI Virtuoso for in-Voyager workflows, Copilot for Microsoft 365, custom agents (Claude, Gemini, ChatGPT-powered) for cross-system use cases, none of which covers.

ABC before AI. Get the foundation right, and the intelligence artificial or absolute follows.

No. YDC is a query-driven API for Microsoft Power BI and Fabric. Replicate is real-time, table-level Change Data Capture (powered by Qlik) into Snowflake, AWS, Azure, or GCP. YDC works on standard Voyager hosting; Replicate requires Yardi private cloud.

Virtuoso is Yardi's native AI platform inside Voyager, a five-layer stack covering Native AI Agents, Assistant, Premium Agents, Composer, and Insights. The ABC products (YDC, Replicate, YDMS) extend AI capability outside Voyager into your warehouse, BI tools, SharePoint, and Microsoft 365. They are complementary, not competing.

A typical engagement starts with a discovery sprint to map the client's data and document estate, recommends a YDC / Replicate / YDMS deployment plan, builds the semantic model and dashboards, configures the SharePoint architecture, and then layers AI use cases, Copilot agents, Power Automate flows, and custom integrations through KriyaGo on top. Engagements range from focused 6–8 week implementations to multi-quarter transformation programs.

At AssetSoft, we go beyond technology implementation—We help you evolve your data strategy to unlock new value across your real estate portfolio. Whether you're working with platforms like Yardi, MRI, or Procore, our team specializes in seamlessly integrating these systems into the Microsoft Fabric ecosystem.

We design and deploy automated data pipelines, build tailored dashboards, and deliver actionable insights—so your teams can make faster, smarter decisions. By reducing manual processes and unifying your data landscape, we help you build a scalable analytics foundation that supports long-term digital growth.

Microsoft Fabric isn't just another analytics tool—it represents a shift toward centralized, democratized data access. Real estate teams can now collaborate in real time, reduce reporting cycles, and make confident decisions without jumping across platforms or relying on IT for every insight.