Home / Switching

Switching building software without losing a year

Most teams know their current tool is not enough. What holds them back is usually the migration: the worry that it will take a year and leave the building running on two half-systems.

Work order list showing imported requests with issue types, companies and assignmentsOperations Hub · after migration
Nothing gets deleted

We import from exports. Your existing system keeps working exactly as it does today for as long as you want it, which means a rollback is always available and costs nothing.

Your accounting system stays put

Yardi or MRI remains the system of record. The migration covers the operational layer on top of it and leaves the ledger alone.

A date, not a leap

New work starts in the new system on an agreed day. Open work finishes where it started. No one has to re-key a queue over a weekend.

What has to move

Less than most people expect. Open work orders and their history. Vendors, with their certificates and expiry dates. Tenants, suites and contacts, which usually come from the accounting system instead of the old tool. Preventive schedules and the assets attached to them. Documents, if they are stored somewhere we can reach.

What usually cannot come across

Some legacy systems export work order detail badly: notes get truncated, attachments lose their references, custom fields get flattened into one column. We will tell you that before you sign. In most cases the practical approach is to bring across three years of structured history and keep the rest as an archived export, because rebuilding it by hand costs more than it is worth.

Running both at once, on purpose

The safest migration is a simple one. New requests start in the new system on a chosen date, and open items finish where they were raised. For a few weeks two systems are live. That feels untidy, but it prevents the real failure, which is a half-migrated queue where no one knows which screen to trust.

The biggest risk in a migration is the two weeks when no one is sure which screen is the real one. That is a sequencing problem, and we plan for it.

The order that works

Read-only integrations first, so tenant and lease data is flowing and visible before anyone depends on it. Then operations for one building: work orders, vendors, preventive schedules. Then the tenant-facing side once the internal team is comfortable, because the worst version of this is tenants meeting a new portal while your own team is still learning it. Write-backs to accounting last, when finance has approved the mapping.

What we need from you

Not much, but it has to be somebody's job. One person who can make decisions about data. A Yardi or MRI administrator for a few hours to set up a service account and agree scope. Access to whoever configured the access control system. And a list of the things your current tool does that nobody documented, which is the item that most often turns up in week three.

What it is reasonable to expect

A single building live in 30 to 60 days. A portfolio in phases after that, at a pace set by how clean your data is. Expect some friction in the first two weeks while routing rules get adjusted to how the building really works. Be wary of anyone promising a portfolio-wide cutover in two weeks.