A new portfolio signs. Somewhere in the deal room, a go-live date got written down, eight weeks out, ten weeks out, whatever felt reasonable based on the last few onboardings. Then the actual data shows up: an export out of Yardi, RealPage, Entrata, or something more homegrown, and it's on someone's desk to turn into the format the leasing CRM needs, property records, unit records that belong to a property, resident and lease records that belong to a unit.
That date got set before anyone had opened the file. Which means it wasn't really a schedule. It was a guess, dressed up as one.
The team isn't the variable
When an onboarding runs long, it's tempting to look for what went wrong, a missed step, someone new to the process, not enough hands on it. Sometimes that's the story. More often, the team did everything right and it still took three times as long as the last one, because the thing that actually determines how long this takes was never the team's skill in the first place. It's how messy this particular customer's data happens to be, and that's not knowable from the outside.
Two portfolios of a similar size can take wildly different amounts of time to onboard, and the difference usually traces back to the source system, not the customer's size or the team assigned to it. A property manager who's kept clean, consistently structured records in one platform for years hands over an export that maps over cleanly. Another, running a mix of legacy spreadsheets, a PMS that's been customized past recognition, and a few facts that only live in someone's head, hands over something that takes days just to understand before anyone can start reconciling it. Same team. Same process. Completely different week.
That mess doesn't originate on the implementation team's desk, either. It starts with the customer's own staff, usually people who've never worked with a schema like this before, converting whatever they have in Yardi, RealPage, or Entrata into the required format by hand. The implementation team doesn't create that problem, they inherit it, which is a different position to be in than the one people usually picture. Catching it costs one of two things: time spent fixing it in house, or time spent sending it back and waiting on the customer's calendar for a corrected version, often slower than doing it yourself, but off your own team's plate. Either way, the team is reacting to an error rate it didn't set and can't train its way down, because the process that produced it was never theirs to begin with.
Why this stays invisible until it's too late
The reason this keeps surprising people, even people who've run dozens of onboardings, is that the messiness isn't visible from the deal stage. Nobody previews the source data before signing. The go-live date gets set against an average, this kind of portfolio usually takes about this long, and averages hide exactly the variance that matters. A property-unit-resident structure that looks the same from the outside, three sheets, a reasonable number of rows, can hide a completely different amount of reconciliation work depending on whether the IDs line up cleanly across sheets or whether half of them have to be tracked down by hand.
That's also why this particular kind of problem doesn't show up as a clean bottleneck anyone can point to and fix. It's not that one step in the process is slow. It's that the actual duration of the reconciliation step is a random variable nobody's measuring until they're already inside it, and by then the date is already on a calendar somewhere.
What actually eats the time
It's rarely the property-level data. Properties are few, and property fields are usually simple enough to map by inspection. The time goes into the layer underneath: making sure every unit points at the correct property, every resident and lease points at the correct unit, catching the row where a unit ID got mistyped, or a resident record still references a unit that was renumbered two exports ago. None of that shows up as an error. It shows up as time, someone on the implementation team cross-referencing tabs, rebuilding a crosswalk by hand, checking a sample of rows and hoping the rest hold up the same way.
That work scales with how tangled the source data is, not with how many units are in the portfolio. An 11,000-unit portfolio with a clean, well-structured export can move through reconciliation faster than a 2,000-unit portfolio where the source system has accumulated a decade of manual overrides. Unit count is the number everyone plans against. Source-system hygiene is the number that actually determines the timeline, and it's the one nobody has visibility into until the file is already open.
What actually helps here
We're not going to pretend the fix is making the reconciliation step disappear, or that a tool replaces the judgment involved in deciding what a messy record should map to. Elvity's data mapping platform narrows the variance by catching the crosswalk errors themselves: it automatically checks whether every unit-to-property and resident-to-unit reference actually resolves, and surfaces the ones that don't, the unit ID that doesn't match any known property, the resident record still pointing at a unit that was renumbered two exports ago. That's a different problem than reformatting a column, and it's the one that was actually eating the time.
It doesn't turn a messy export into a clean one, and it doesn't remove the judgment call on what a flagged record should actually map to, that's still a person's decision. What it changes is where the team's time goes: instead of manually cross-referencing tabs or building a spot-check sample and hoping the rest holds, the team opens a short, specific list of exactly what didn't resolve, and decides what to do about each one, fix it in house or send it back, rather than spending the bulk of the week just finding it in the first place.
The honest version of this isn't "you'll never miss a go-live date again." It's that the date stops being a guess made before anyone's seen the data, and starts being closer to a real estimate, because the part of the job that used to eat unpredictable amounts of time, finding the crosswalk errors in the first place, isn't the open question it used to be.
A go-live date shouldn't be a bet on how clean someone else's spreadsheet turned out to be.