The Biggest Operators Did Not Pick a PMS. They Picked a Warehouse.

A director of IT at a multifamily operator put it to us this way. The company had a lot of silos, and the job was to bring the data together so the business could slice it, dice it, and make decisions on it. Not build a dashboard. Not pick a system. Bring the data together, because it was sitting in several places and the whole portfolio existed as one number nowhere except in whichever spreadsheet someone had reconciled most recently.

Every article about what the biggest multifamily operators run gets written from the outside, and from the outside the answer looks like a platform. The biggest operators scale with systems, the articles say, with standardized workflows and centralized reporting and technology that supports repeatable processes. That is true and it is also empty, because it never names the systems, and the moment you name them the picture changes. The biggest operators did not standardize on a property management system. They could not. They standardized on the thing that sits above all the property management systems they ended up running, which is a warehouse they own.

There is no dominant system

The data is why the question is usually asked wrong. Our 2026 count of units under management puts MRI Software at 15.6 million, Yardi at 15 million, AppFolio at 9.5 million, and RealPage (OneSite, Buildium, and Propertyware combined) at 9 million. Rent Manager holds 5.75 million, Entrata 2.5 million, ResMan 900,000. The top four are within a 2x spread of each other, and no vendor is anywhere near a majority.

The full unit-count analysis carries the source and as-of date for every figure, and its limitations too: the counts mix US-weighted and international unit bases, and vendors define a unit differently. Read it as directional. Even so, it says something most “what do the biggest operators use” content quietly assumes away. In a market where the leader holds well under a third of the footprint, there is no default. There is a tier.

Footprint is not the same as depth, either. Entrata holds about a quarter of AppFolio’s units and earns roughly twice the revenue per unit, about $230 a year against $110, derived from each company’s Q1 2026 revenue. One went deep into enterprise portfolios and one went wide into the long tail, and both are on the same unit chart. A large operator reading that chart for a default is reading it for something it does not contain.

The tier is small. Our residential proptech market map counts 49 full property management systems across the US and Canada. Twenty-one serve small landlords, sixteen are DIY or freemium tools, six target the mid-market, and six are built for enterprise portfolios. Yardi, RealPage, Entrata, and MRI Software are in that tier. If you run 15,000 units or more, your shortlist is essentially that tier, and the interesting fact about the tier is not which member is best. It is that most large operators run more than one.

How a portfolio ends up with three of them

Nobody designs a stack with three property management systems in it. Portfolios acquire one.

The common path to 15,000 or 20,000 units is buying other management companies, and every management company arrives with a PMS that its site teams have used for a decade. The acquiring operator now has a choice. Migrate the acquired properties onto the house system, which means re-training every site team, re-keying every lease, reconciling every ledger, and accepting a year or two of reports nobody fully trusts while it happens. Or leave the acquired portfolio on its existing system and reconcile at the reporting layer.

Migration is the textbook answer and the rarer one, because the risk sits in the wrong place. A PMS migration puts operational risk on the leasing office and the accounting team, the two functions that cannot pause, in exchange for a reporting benefit that lands on the executive team. At 2,000 units the trade is often worth it. At 20,000 it frequently is not, and the operator who has done one migration is the least eager to do the next. So the acquired systems stay, and the vice president builds the spreadsheet.

At 15,000 units and above, running Yardi, RealPage, and Entrata at the same time is not a transitional state waiting for a consolidation project. It is the steady state, and any technology decision that assumes one system of record is planning for a company that does not exist.

What “standardize” means at that scale

Large operators standardize the layer above the systems, not the systems.

Each PMS keeps its own data model. A unit in Yardi is a unit. In RealPage it may be a space. In Entrata it is a unit again, with different sub-fields. Lease status codes differ, charge codes differ, work order priorities differ. None of that gets standardized at the source, because the source is a leasing office’s daily tool and the vendor has no reason to reshape it for your reporting.

What gets standardized is the table the board number comes from. Each system lands in a warehouse the operator owns, in its own shape, and one modeling layer on top decides that a Yardi unit and an Entrata unit are the same thing for the purposes of occupancy. That decision is the standardization. It is a set of business rules, it is written in dbt or SQL by someone who understands both the data and the business, and it lives in one place where it can be versioned, tested, and argued about.

Connect does the part underneath. It extracts and loads raw data from Yardi, RealPage, Entrata, MRI Software, AppFolio, and the rest of the operational stack into the warehouse, and keeps it flowing as the source APIs change. For the property management systems the Unified API supports there is also a normalized layer, which is what an application builder wants. Everything else arrives raw, on purpose, because the operator’s rules are the operator’s to write. The multi-PMS how-to walks through the five steps.

“Standardize” means something narrower, and more achievable, than the articles imply. It does not mean every property on one system. It means every system in one warehouse, and one model on top.

The case for consolidating anyway

There is a real argument for the migration. Three systems means three vendor relationships, three sets of API credentials, three training curricula, and three places a process can drift. Every acquired portfolio left on its old system is a permanent tax on the operations team. Consolidation removes the tax, and the operators who have done it successfully tend to be the ones who did it early, when the acquired portfolio was small and the house system was already the majority.

The argument fails at scale for a reason that has nothing to do with software. The migration’s cost is certain and lands this year on the people who run the buildings. Its benefit is a cleaner reporting layer, which the warehouse delivers anyway at a fraction of the disruption. An operator choosing between a two-year migration and a two-quarter warehouse project, both of which produce one portfolio-wide occupancy number, will pick the warehouse almost every time, and then discover that the warehouse also holds the leasing CRM, the maintenance platform, and the payments data, none of which a PMS migration would have touched.

Consolidate when the acquired portfolio is small enough that the migration is cheap. Otherwise, standardize above the systems and keep the leasing offices on the tools they know.

What to do if you manage over 15,000 units

Choose the warehouse first. Snowflake, BigQuery, Databricks, Fabric, or whatever your finance team already queries. The decision that compounds over the next decade is where the portfolio’s data lives, not which vendor runs the leasing office at any one property, and the warehouse outlasts every PMS you will run.

Then evaluate the enterprise tier on the criteria that decide satisfaction later: which objects the API exposes, whether extraction is incremental or full-refresh only, what egress costs and whether it can be written into the contract at no incremental charge, and what leaving would cost. Our evaluation guide covers the questions. Ask them assuming you will run this system alongside two others, because you will.

Then stop trying to make the systems agree with each other and make them agree in one place. One managed pipeline per system, into the warehouse, and one model on top that encodes how your company counts a unit.

The biggest operators did not find the one system. They stopped looking for it, and built the layer that made the question stop mattering.