Yardi to Yardi (Y2Y) Migration: Onboarding Acquired Properties

What Is a Yardi to Yardi (Y2Y) Migration?

A Yardi to Yardi (Y2Y) migration is a conversion that maps and moves a property's records from one Yardi database into another. The usual trigger is a property changing owners or managers when both sides already run Yardi. You'll also see it written as Y-to-Y or called a Yardi to Yardi conversion, and it comes up a lot on multifamily deals, where a buyer can inherit hundreds of resident records on the day of closing.

The appeal is how much can come across. A Y2Y file can include work orders, prospects, historical lease information, view-only tenant ledgers and other data that's less likely to come through an ETL load. Tenant attachments follow as a separate step after the file is loaded. That step depends on the seller signing a transfer request, so it's worth raising long before the week of closing.

A Y2Y also takes cooperation from more than one company. The seller or prior manager has to release the data, and you have to decide what you want and how it should land in your setup. The mapping and load work can sit with your own staff, with Yardi or with a consultant, depending on how the project is scoped. No matter who does the work, your team has to operate from the result, so the sign-off stays with you.

This guide covers moves between two companies' Yardi databases. Moving your own company from one Yardi product to another, such as Breeze to Voyager, raises different questions, and our Yardi data migration services page covers those projects along with moves from other platforms.

Y2Y vs ETL: Which Method Fits Your Acquisition?

Use a Y2Y when the seller runs Yardi and you want history to come with the property. Use Yardi ETL import templates when the seller doesn't run Yardi or you'd rather start clean. ETL, short for extract, transform and load, refers to templates that mirror Yardi's data tables, so you can import records from a spreadsheet no matter where they came from.

The table makes this look tidier than it is. Most decisions come down to how much the history is worth to you and how many more properties you expect from this seller.

When a Yardi to Yardi Migration Makes Sense

History is the first reason to choose a Y2Y, and it tends to matter more than anyone expects until a resident disputes a charge from before you owned the building. With lease history and view-only ledgers in your own database, your on-site team can answer that question on the spot. Otherwise, they're tracking down the seller's old property manager, who has probably moved on to other things.

Documents strengthen the case. If the prior management company was diligent about attaching leases and notices to resident profiles, a Y2Y is the better fit, since those attachments can transfer after the file loads as long as the seller has signed the transfer request. The staff inheriting the building will thank you, because nobody enjoys rebuilding resident files from a banker's box.

The second reason is a repeat seller. The mapping can be time-consuming on the first property, but the same mapping applies to each file after it, so the next acquisition only needs property-specific items such as unit types. If you're buying a portfolio in stages, that first slow build becomes a head start on every property that follows.

It also helps that both databases already speak the same language. That doesn't mean they're set up the same way, since two operators can run the same software with very different charge codes and account structures.

When ETL Imports Are the Better Choice

The obvious case for ETL is a seller who isn't on Yardi at all, because a Y2Y needs Yardi on both sides. If the property runs on another platform, our RealPage to Yardi migration checklist and Skyline to Yardi migration guide walk through how those moves work.

ETL can also be the better call when the seller does run Yardi. You might only need current residents and open balances, or the seller's data might have enough problems that you'd rather not inherit them, since a Y2Y brings the old setup's habits along with the history. A one-off property can tip the math as well, because the mapping never gets a second file to pay off on. Then there's the seller who won't release the data or sign the paperwork, which leaves you building from reports and spreadsheets whether you planned to or not.

Planning a Y2Y Migration Around the Close

A Y2Y goes best when you plan it backward from the closing date, because the property has to be ready for rent and month-end as soon as it's yours. The order below is where we'd start, though every deal bends it a little.

1. Ask for the data before closing. Get the seller's agreement to release it into the deal paperwork or transition plan while you still have some leverage, along with the signed transfer request if you want attachments.
2. Decide what comes across. Agree on how much history you need and who at your company signs off on each area.
3. Build the first mapping. Translate the seller's setup into yours, starting with charge codes and accounts, and note which items are specific to this property.
4. Run a test load. Have your team review the results before the real cutover, while a bad mapping is still easy to fix.
5. Time the final load. Set the cutoff around the closing date and your month-end, so the last payments and charges land in the right place.
6. Validate and reuse the mapping. Tie out the reports, go live and save the mapping for the next property from that seller.

The awkward part is that the seller keeps operating right up to closing, so the data you tested with goes stale while rent keeps coming in. Plan for a final pull at the cutoff, and make sure someone owns the transactions that land in that gap. A payment posted to the seller's ledger the day after closing won't find its own way to yours. If closing falls mid-month, work out how the partial month gets handled before the load, since rent prorations and your first close both depend on that answer.

How to Validate a Y2Y Migration

Validate a Y2Y by comparing reports from the seller's database with the same reports in yours as of the same cutoff date, starting with the rent roll, the receivables aging and the security deposits. Trace any difference to a mapping or data issue and fix it before your team starts posting to the property.

Ask for more reports than you think you'll need while the seller is still taking your calls, because you can't tie out to a report nobody saved. In a purchase, your opening balances usually come from the closing statement rather than the seller's trial balance, so the deposits and prepaid rent on your ledger should agree with the credits you received at closing. Old receivables need a decision too, since the purchase agreement usually spells out who keeps rent owed from before closing. That answer changes what belongs on a live ledger and what stays in the view-only history.

Reports only go so far, so have someone who knows the property review a sample of resident ledgers as well. A report can balance to the penny while the resident in 204 gets billed for someone else's parking space. Affordable properties add another layer, because compliance data has to hold up after the transfer, so confirm early how it'll move and who'll check it.