FourdaystoliveonValix

What changed

A mid-size mixed-use portfolio can move off Yardi Voyager in about four working days — no historical data loss, no re-entered leases, no rent charges missed.

Here is how a production cutover is designed to run — not a pilot, not a sandbox. The legacy system goes read-only Friday afternoon. By Tuesday morning the plan has the operator posting rent and running AR-aging inside Valix.

Why four days (not four months)

Long migrations tend to run long for one of three reasons: (1) the target system forces a schema change halfway through, (2) the accounting model silently disagrees with the source and the team debugs trial-balance drift for weeks, (3) nobody owns the business-logic decisions so every discovery waits for a meeting.

We solve those upfront. The schema is locked day one. The GL mapping is applied in a dry run before cutover so any trial-balance drift surfaces on a Wednesday, not after go-live. And every decision has a named owner in a RACI worksheet before kickoff — no meetings to resolve ownership.

The dry run

The rule the whole timeline is built around: never, ever, cut over on a Monday morning without a dry run the Wednesday before. The dry run exercises every rent charge, every CAM reconciliation, every percentage-rent calculation against a sandbox and tells you whether the outputs match your trial-balance target.

What breaks (and what doesn’t)

This is exactly the class of issue a dry run is built to catch: a percentage-rent breakpoint calculated on the wrong sales base (gross-inclusive-of-tax versus exclusive), a dropped option-year amendment, a CAM cap applied against the wrong lease year. Each of those surfaces during the Wednesday dry run — against a sandbox, with time to fix it — instead of inside a live trial balance after cutover, where it costs days of reconciliation to isolate.

The numbers

For a portfolio in this range — a few hundred units, on the order of a hundred-plus chart-of-accounts entries, one or a handful of SPVs consolidated, and roughly two years of transaction history re-posted — the target is zero dropped rent charges: on the order of a day and a half of hands-on operator time spread across the four days, and a few days of calendar time from export to first posting.

Takeaway for operators

Migration time is a function of how much business logic has to be re-decided under pressure, not how much data has to move. Decide the logic up front. Map the GL before cutover. Run the dry. The data part takes a weekend.