Field notes

June 2026 · 7 min read

Key takeaways

• Rip-and-replace is the wrong path for institutional real estate: the system of record is load-bearing, and migrating it trades a known workflow for a year of avoidable risk.
• The right model is read-then-write-on-approval: read the systems of record continuously, reconcile them, and write back only what a human signs off on.
• A layer that reads rather than replaces onboards in weeks, not quarters. A large book, on the order of several hundred assets, can be live in about a week.
• Co-existence beats migration because there is no flag day, no frozen quarter, and no single point of failure. Argus and Yardi keep doing their jobs.

The pitch to replace your system of record always sounds like progress and almost always means a year of danger. Argus holds the cash-flow models the whole firm underwrites against. Yardi holds the ledgers the accounting team closes on and the rent rolls property management lives in. These systems are not glamorous, but they are load-bearing: people know them, processes are wrapped around them, auditors expect them, and the data inside them is the firm's operating memory. Proposing to migrate all of that is proposing to take the floor out from under a working building to install a nicer floor, and to live on scaffolding while you do it.

There is a better way to think about it. The problem institutional firms actually have is almost never that Argus and Yardi exist. It is that the intelligence layer above them, the reconciliation, the analysis, the reporting, the judgment, is missing, and is done by hand in spreadsheets and email instead. You do not fix a missing top layer by replacing the bottom one. You fix it by building the layer that was missing and letting the systems of record keep doing their jobs underneath.

Why rip-and-replace is the wrong path

Migration projects in institutional real estate fail in predictable ways, and the failures are structural, not a matter of trying harder. The data is messier than anyone admits going in: years of leases, amendments, side letters, ledger conventions, and local exceptions that exist for reasons nobody remembers but everybody depends on. Moving that into a new schema means re-deriving every one of those conventions under deadline, and the edge cases that the old system handled quietly become the new system's production incidents.

Then there is the flag day. A migration eventually forces a cutover, a moment when the old system stops being authoritative and the new one starts, and around that moment the firm has to freeze change, run both systems in parallel, and reconcile them line by line to prove nothing was lost. That window is expensive, nerve-wracking, and lands, inevitably, on top of a close or a reporting deadline. The cost is not only the software and the consultants. It is the diverted attention of exactly the senior people whose judgment the firm needs pointed at deals, not at a data migration.

You do not fix a missing top layer by replacing the bottom one. Argus and Yardi are not the problem. The missing problem is the intelligence layer above them, and it has been done by hand.

And at the end of a successful migration, the best case, the firm has the same data it had before, in a different box, having absorbed a year of risk to get there. The model still has to be re-validated, the auditors still have to re-learn the new lineage, and the people still have to re-build the muscle memory. Migration is a large, certain cost paid up front for a benefit that is, at best, lateral. For a system of record, that trade is almost never worth making.

The read-then-write-on-approval model

The alternative inverts the relationship. Instead of asking the system of record to move, the intelligence layer comes to it, reads from it, and writes back only with permission. The model has two halves, and the discipline is in the second one.

Read continuously

The layer connects to Argus, Yardi, and the rest of the stack and reads them on an ongoing basis: leases, rent rolls, ledgers, debt schedules, cash-flow models. It does not ask anyone to re-enter or re-key anything. The systems of record stay authoritative, and the layer treats them as the source of truth they already are. Reading is non-destructive by construction. Nothing in Argus or Yardi changes because the layer looked at it, so the read side carries essentially no operational risk.

Reconcile into one picture

Reading is not enough, because the systems disagree. The rent roll, the lease documents, and the cash-flow model frequently tell three slightly different stories about the same tenant, and resolving those disagreements is most of the work. The layer reconciles them into a single, consistent picture, on a deterministic engine, so every number it surfaces traces back to the specific record it came from and to the conflict it resolved. This is the layer that was missing, and it is built once, on top, instead of migrated.

Write back only on approval

When the layer has work to push back into a system of record, an updated assumption, a corrected field, a posted reconciliation, it does not push it. It drafts the change, attaches the reasoning and the source, and waits for a human to approve. The write path is gated by a person, every time. That single rule is what makes co-existence safe: the system of record can never be silently mutated by an automated process, so the firm keeps the control it had while gaining the intelligence it lacked.

The asymmetry of read and write

Reading a system of record is safe and can be continuous and automatic. Writing to one is consequential and must be deliberate and human-approved. Collapsing that distinction is how integrations cause incidents. Keeping it is how a layer can sit on top of Argus and Yardi for years without ever being the reason a ledger is wrong.

Onboarding in weeks, not quarters

Because the model reads rather than migrates, the onboarding curve is completely different. There is no schema to design, no data to move, no parallel-run to reconcile, no cutover to survive. The work is connecting to the systems, mapping their fields, and reconciling the existing data, and that work scales with connections, not with the heroics of a migration.

In practice this means a large book onboards in the time a migration spends on its kickoff. A portfolio on the order of several hundred assets, the kind of book that would anchor a multi-quarter migration plan, can be read, reconciled, and live in about a week. That is not a smaller version of a migration. It is a different category of project, because nothing is being moved and nothing has to be frozen while it happens. The firm keeps operating in Argus and Yardi the entire time, and the new layer simply comes online above them.

Two onboarding paths

Migrate the system, or sit on top of it

• Rip-and-replace
  Design a new schema, migrate years of leases and ledgers, run in parallel, survive a cutover, re-validate the model. Quarters of risk for a lateral result.

• Connect
  The layer reads Argus, Yardi, and the rest of the stack. Non-destructive by construction.

• Reconcile
  Resolve the disagreements between rent roll, lease, and model into one cited picture.

• Go live
  A several-hundred-asset book read and reconciled in about a week. No freeze, no flag day.

• Write back on approval
  Changes flow into the systems of record only when a human signs off. The control stays with the firm.

The top row is the migration nobody enjoys. The rest is the layer that sits on top: connect, reconcile, go live, and write back only with permission.

Why co-existence beats migration

Co-existence is not a compromise the firm settles for because migration is hard. It is the better architecture on the merits, for three reasons.

• No single point of failure. Because the systems of record remain authoritative and untouched, the layer cannot take them down. If the layer were unplugged tomorrow, Argus and Yardi would carry on exactly as before. That is a property migration can never offer, because a migration deliberately makes the new system the only one that works.
• No frozen quarter. There is no cutover, so there is no window where the firm has to stop changing things and reconcile two worlds. The close happens on schedule, the reporting goes out on time, and the layer comes online around the existing rhythm instead of interrupting it.
• Vendors keep their strengths. Argus is good at cash-flow modeling and Yardi is good at property accounting, and neither is trying to be the firm's intelligence layer. Letting each do the thing it is best at, and adding the missing layer on top, is a cleaner division of labor than asking one new system to be everything at once.

The deeper point is about risk symmetry. Migration concentrates all of its risk at one moment and bets the firm's operating continuity on getting that moment right. A layer that sits on top spreads almost no risk at all, because the load-bearing systems never stop bearing load. For an asset class where a botched close or a lost lease record has real consequences, the conservative architecture and the modern one turn out to be the same architecture.

For an asset class this consequential, the conservative choice and the modern choice are the same choice: leave the systems of record load-bearing, and add the intelligence that was always missing on top.

What "sits on top of your stack" means technically

The phrase gets used loosely, so it is worth saying what it actually means. Sitting on top is not a dashboard that screen-scrapes a few reports. It is a knowledge graph that ingests the full detail of the systems of record, leases, rent rolls, ledgers, debt, models, and links those records to each other and to the entities they describe, so the firm's data finally has a single connected representation rather than a dozen disconnected exports.

On that graph runs a deterministic engine that does the reconciliation and the analysis, so every figure the layer produces is reproducible and traces to the source record it came from. The integrations into Argus, Yardi, and the rest are first-class connectors, read on a schedule and on change, write only through the approval gate. And the whole thing can run single-tenant, so the firm's data is isolated and the layer never becomes a place where one firm's records could touch another's. That is the technical content of sitting on top: ingest everything, connect it, reason on it deterministically, and write back only with a human's signature.

The instinct to modernize is right; the instinct to migrate is usually a trap. Argus and Yardi are not what is holding an institutional firm back. The missing layer above them is, and that layer can be built without moving a single record out of the systems the firm already trusts. Built AI sits on top of the existing stack: it reads the systems of record continuously, reconciles them on a deterministic engine, writes back only on human approval, and brings a several-hundred-asset book live in weeks rather than quarters, with no flag day and no frozen close.