September 5, 2026

Migrating Lease Data from Excel to Yardi Voyager: Where Lease Abstraction Fits

Every lease data migration starts in one of two places, and it's worth being honest about which one you're actually in before you open Excel.

Either the lease terms already exist somewhere structured — a legacy system export, a spreadsheet someone maintained, an abstract from a prior migration — or they exist only as PDFs: the executed leases and every amendment, sitting in a deal room or a shared drive, with the terms nowhere but the document text. Those are two different problems with two different first steps, and conflating them is the single most common reason a "simple" lease migration turns into a stalled go-live.

The full pipeline, in order

  1. Source leases. Whatever format they're in — PDFs from an acquisition, exports from a legacy ERP, a hand-built spreadsheet.
  2. Abstraction, if you're starting from documents. If the terms live only in lease text, someone has to read every lease and amendment and pull out parties, dates, rent, escalations, recoveries, and options into structured data before anything else can happen. Skip this step and you're not migrating data — you're migrating gaps.
  3. A structured spreadsheet. Whether it came from abstraction or was already structured, this is the handoff point: one clean, tabular representation of every lease's terms, ready to be mapped.
  4. A Yardi-ready import file. This is the ETL mapping step — translating the structured spreadsheet's columns, codes, and formats into exactly what Yardi Voyager's import modules expect.
  5. Validated import. The file is checked against Yardi's rules before Voyager ever sees it, so what lands in production is clean the first time.

The mistake we see most often is treating steps 2 and 4 as the same problem. They're not. Abstraction is about correctly reading a lease document — verifying rent figures against source pages, catching what an amendment changed versus what the original said. ETL mapping is about correctly shaping already-known data for a specific target system's import rules. A team strong at one is frequently weak at the other, which is exactly why this pipeline tends to break at the seam between them.

The mechanics that make step 4 hard

Assume you're at step 3 — clean, structured lease data, whether from abstraction or a legacy export — and you're ready for the ETL mapping step. Three mechanical problems show up on nearly every batch:

Module dependency order. Yardi Voyager's import modules aren't independent. Owner records have to exist before property records that reference them; GL accounts have to exist before charges that post to them. A lease-data batch commonly spans several modules at once — property, unit, tenant, and charge-schedule records — and importing them out of order doesn't fail gracefully. It fails on every row that references something the earlier module hasn't loaded yet, and the error message rarely says "wrong order" — it says "code not found," which sends people hunting for a data problem that isn't there.

Field mapping against the target's actual vocabulary. Your structured spreadsheet says Annual Rent; Yardi's import template wants a specific field, in a specific format, matched against your property's area and charge configuration. Escalation schedules that live in a free-text column need to become structured rate/date pairs. Option terms captured as a sentence need to become the discrete fields an import module can accept. None of this is conceptually hard — it's high-volume, error-prone translation work, exactly the kind that produces a clean-looking spreadsheet that still fails validation.

Validation before Yardi sees the file, not after. The expensive failure mode isn't a rejected row — it's an accepted one that's wrong: a charge that imports cleanly with a plausible but incorrect amount, and shows up as a tenant billing dispute months later instead of an import error today. Real validation checks required fields, formats, code lookups, and cross-field dependencies before the file ever reaches Voyager, so a wrong value gets caught as an exception you review, not a live bill you have to unwind.

A worked shape, not a formula

None of this means every migration has to run all five steps in full. A portfolio coming out of a well-maintained legacy ERP might skip abstraction entirely — the data's already structured, it just needs translation and validation. A small acquisition of a handful of properties with only PDF leases on file might spend most of its time in abstraction and barely notice the mapping step. The pipeline is a shape to check your project against, not a checklist every engagement runs start to finish. What doesn't change is the seam: wherever structured data enters the process, from whatever source, it has to pass through the same mapping-and-validation discipline before Yardi sees it, or the migration inherits whatever quality problems the source system had.

Where each product does its job

Lease Abstraction handles step 2 when you're starting from documents: AI extraction with page-level citations on every value, plus specialist human QA, turning a stack of PDFs into the structured spreadsheet that step 4 needs. It's a managed service — you send leases, you get abstracts back, and it's scoped specifically to that translation, not to what happens after.

ETL Mapper handles step 4 regardless of where your structured data came from: it detects which of Yardi's import modules a file belongs to, maps columns against the field catalogue, and validates against the cross-module rule set — dependency order, formats, lookups — before you ever upload to Voyager. Upload the messy spreadsheet, review the handful of genuinely ambiguous mappings in plain English, download an import-ready file.

Run together, the two close the seam: leases go in, a validated Yardi import file comes out, with no re-keying step in between where errors like to hide. If your lease data already exists in structured form and you just need the ETL mapping and validation stage, start there — try ETL Mapper free for 7 days, no card required. If you're starting from a stack of scanned leases, reach out about lease abstraction and ask for a free sample round before committing to anything.