Replacing a facilities system without losing your history

Replacing the system your operation runs on is one of the least fun projects in property management. It's disruptive, it's hard to estimate, and the failure mode isn't a crash — it's a year of your team quietly working around a tool nobody adopted.

We sell a replacement, so treat what follows accordingly. But we'd rather you run this properly than buy something that doesn't fit, so this is the honest version — including the part where you decide not to.

First: are you solving the right problem?

A surprising number of replacement projects are really about one of these, and none of them need new software:

• A data-quality problem. If your categories are free text and your statuses have drifted into a dozen overlapping values, your reports are wrong — and they'll be just as wrong in a new system, because you'll migrate the same mess. Run a distinct count on those fields before you shortlist anything.
• A configuration problem. Sometimes the platform can do what you need and nobody has set it up. Worth an honest conversation with your account manager first — it costs a meeting and can save a year.
• A process problem. If requests arrive by text message to one person's phone, no system fixes that until the intake path changes.
• A people problem. If the current tool is unloved because it was imposed without training, a new tool imposed the same way will land identically.

Rule of thumb: if you can't name the specific thing the current system cannot be made to do, you're not ready to shortlist.

Reasons that genuinely justify replacing

• Getting the monthly picture out requires manual assembly every single month
• The product's direction has moved away from your use case
• You need capability it doesn't have and won't get — leases, COI enforcement, branch-scoped access
• Access control can't express how your teams are actually organized
• Adoption has failed repeatedly and the interface is a named reason
• You're paying for breadth you don't use, and the cost is real

Two or three of those and it's worth looking. One, and it might be a feature request.

The risk nobody scopes: your history

The technical migration is rarely what sinks these projects. What sinks them is realizing in month three that only current open work is coming across, and three years of history — the basis of every trend, every vendor conversation, every budget argument — is staying behind in a system you're about to stop paying for.

Ask early and get it in writing:

• What historical data comes across, and in what detail?
• Are original work-order numbers preserved, or regenerated? (Regenerated numbers break every historical reference, invoice match, and email thread.)
• Do lease abstracts, clauses, and rent schedules migrate, or are they retyped?
• Who does the work — you, them, or a paid third party?
• What happens if the first import is wrong? Can it be rolled back and redone?

“We'll help you get set up” is not an answer to any of these. If a vendor is vague about historical data, assume it isn't coming and price the manual work.

Questions worth asking every vendor

Including us. The answers are more revealing than any feature list:

1. “Show me this running on my data.” Not a canned demo — your export, loaded. A vendor who can't or won't is telling you something about how import really works.
2. “What does this not do well?” Anyone who says “nothing” either doesn't know their product or isn't being straight with you.
3. “Who is the wrong customer for this?” A confident vendor has a clear answer. It also tells you fast whether you're the wrong customer.
4. “How does a branch manager use this on a phone?” Or whatever your most reluctant user does. Adoption dies at the edges, not in the demo.
5. “What happens to my data if we leave?” Ask on the way in. The answer is much harder to get on the way out.

A sequence that reduces risk

Big-bang cutovers fail more often than they need to. A phased approach costs a little overlap and removes most of the downside:

1. Import history first, before anyone changes how they work. Load your exported records and check the numbers against reports you already trust. If the totals don't reconcile, you've found out cheaply.
2. Run reporting in parallel for a cycle. Produce next month's report from both systems. Discrepancies are informative, and it builds confidence before anything is at stake.
3. Move intake next. Requests are the highest-volume, most visible flow. Get it right at a handful of properties before the whole portfolio.
4. Then the specialist data — leases, vendors, COIs. Slower-moving, so less urgent, and the lease work in particular deserves care.
5. Decommission last, and export a final archive before you stop paying. Whatever your contract says about data retention after termination, having your own copy is cheaper than finding out.

Costs that don't appear on the quote

• Parallel running — you'll pay both vendors for a period. Budget it rather than discovering it.
• Data cleanup — normalizing categories and statuses is real work, and it's better done before migration than after.
• Training the reluctant — not the ops team who'll be fine, but the branch staff who submit four requests a year.
• Rebuilding reports — anything downstream that consumed the old export format will need attention.
• Your own time — usually the largest line item and the one nobody records.

Signs it's going wrong early

Worth watching for, because all of these are recoverable if you catch them in month one:

• The import happened but nobody reconciled the totals against the old system
• Your team is keeping a parallel spreadsheet “just for now”
• Requests are still arriving by email because the new path is harder
• The go-live date is fixed but the data isn't validated
• One person understands the new configuration and nobody else does

The honest summary: most teams who should replace their system wait too long, and most teams who rush into it skipped the data question. If you do only one thing after reading this, export your data this week — whether or not you ever switch, you'll know what you actually have.