Ask anyone who has taken a portfolio live on Yardi Voyager what surprised them most, and you'll rarely hear "the software." You'll hear about the spreadsheets.
Every migration — whether you're coming from MRI, JD Edwards, CTI, or a pile of Excel exports from a property manager's desktop — funnels through the same bottleneck: someone has to turn messy source data into the exact column structure, codes, and formats that Yardi's ETL import modules demand. Across real implementations, that preparation work consistently absorbs 40–60% of the total engagement.
Where the hours actually go
The time sink isn't typing. It's the invisible knowledge work wrapped around every file:
- Figuring out which of 306 import modules you're even building. CommUnits or ResUnits? Does this batch need CommOwners loaded first? Every module has its own template and its own place in the dependency order.
- Reconciling column names. Your source says
Sq Footage; Yardi wantsDSQFT0— but only when it aligns with yourCommPropAreaLabelsconfiguration. Multiply that by 6,572 field definitions across the schema. - Normalising values.
GFvs0for ground floor.1,200vs1.1kvs1200. Owner codes that don't exist yet because that file hasn't been imported. - Interpreting rejections. Yardi tells you
ERR_FIELD_042; it doesn't tell you that row 47 references an owner code that arrives two files later in the batch.
None of this is billable strategy. It's formatting — expensive formatting, often at consultant rates of $200/hour.
The dependency order problem
Yardi Voyager's import modules aren't independent. Owners must exist before properties. GL accounts before leases. Area labels before square-footage fields validate. Experienced administrators keep a private cheat sheet of this ordering, and every cheat sheet we've seen is incomplete — because the full rule set spans 5,204 validation rules across the schema.
Get the order wrong and the import doesn't fail loudly at the start; it fails 31 rows deep with a cryptic code, and you start the hunt again.
What AI-assisted ETL mapping changes
This is exactly the kind of work a purpose-built AI connector does well, because the knowledge is bounded and structured: a finite module list, a finite field catalogue, a finite rule set.
PropETL packages that knowledge — 306 modules, 6,572 field definitions, 5,204 validation rules, distilled from 20+ live implementations — into a connector that runs inside Claude. The workflow collapses to:
- Upload the source file (Excel or CSV, as messy as it arrives).
- PropETL detects the module, maps the columns, and asks about the genuinely ambiguous ones — "Owner code 'OWNER' on rows 1–12: did you mean OWNER01?"
- It validates against the cross-module rules before Yardi ever sees the file.
- You download an import-ready ETL file. Typically in about 60 seconds.
The consultant stays in the loop for the decisions that need judgment. The formatting disappears.
What that means in project terms
A 4–8 hour reformatting task becomes a 20–30 minute review. Per file, per property, per migration. On a portfolio onboarding with a dozen import batches, that's the difference between a two-week data-prep phase and an afternoon.
And because files are processed entirely in memory — nothing written to disk, nothing stored — the privacy review that usually slows tool adoption tends to be short.
Try it on your own worst spreadsheet: start a free 24-hour trial — full access to every module, no credit card. Upload the file you've been avoiding and see what comes back.