A property business never stops. Rent falls due, residents move in and out, maintenance tickets open, and money moves every single day, including the day you switch systems. That is what makes a PMS migration different from installing ordinary software: there is no quiet weekend when nothing is happening. The fear of downtime is what keeps operators on a system they have outgrown for years longer than they should. The answer is not to find a gap that does not exist. It is to run the old and new systems in parallel so there is never a moment when the business is unmanaged.
This playbook covers how to do that, whatever vertical you run, coliving, build-to-rent, student housing, HMO, or flex. The principles are the same. The goal is a migration where residents notice nothing, rent keeps collecting, and you can prove the new system is correct before you rely on it.
Why downtime is the wrong thing to fear
When people say they are afraid of downtime, they usually mean one of three different fears, and separating them is the first step:
- Data loss: that a resident, a balance, or a signed agreement disappears in the move.
- Operational gap: that for some period neither system is authoritative and the team does not know where to work.
- Financial error: that rent is missed, double-charged, or misallocated during the switch.
None of these is actually about the software being offline for an afternoon. They are about losing the thread of a continuously running operation. Parallel running addresses all three directly, because at no point is there a gap: the old system stays authoritative until the new one has proven it holds the same truth.
The parallel-running principle
Parallel running means the new system is fully loaded and operating alongside the old one for a defined period, with the old system remaining the system of record until cutover. During the overlap you process real activity in the new system and reconcile it against the old, so that by the time you switch, you have already watched the new system produce correct results on live data. You are not hoping it works. You have evidence.
The trade is cost: for a few weeks you carry two systems and some duplicated effort. That cost is small next to the alternative, a hard cutover where the first time the new system meets real month-end is also the first time you find out what is wrong, with no fallback.
Phase 0: scope and data audit
Before any data moves, inventory what you actually have. Most migration pain comes from surprises in the source data, not the target system. Audit:
- Entities and counts: properties, units, beds, agreements, residents, guarantors, owners. Know the numbers so you can prove they arrive intact.
- Live financial state: open balances, deposits held and protected, rent schedules, and any arrears. This is the highest-risk data and needs the most scrutiny.
- Documents: signed agreements, certificates, compliance records. Decide what migrates and what is archived.
- Integrations: payment providers, accounting, channel or listing feeds, anything that reads or writes to the current system.
- Data quality: duplicates, blank fields, inconsistent formats. Every one of these becomes a mapping decision later.
Write the counts down. The audit numbers are the acceptance criteria you will reconcile against after the load. If you start 1,240 agreements, you finish 1,240 agreements, and you can show it.
Phase 1: data mapping and cleanup
Mapping is where the migration is won or lost. Each field in the old system has to land somewhere sensible in the new one, and the two systems rarely model the world the same way. The classic example in shared living is the shift from a per-property or per-unit model to a per-bed model, which changes the shape of your inventory and every report built on it. That specific transition has its own detailed guide: migrating from per-property to per-bed.
Do the cleanup in the old system, or in a staging copy, before you load. Migrating dirty data faithfully just gives you a clean new system full of old mess. A practical mapping discipline:
- Produce a field-by-field mapping document. Every source field is either mapped, transformed, or consciously dropped. Nothing is left undecided.
- Resolve duplicates and blanks before the load, not after.
- Decide the treatment of financial data explicitly: opening balances, mid-cycle rent, and deposits each need a deliberate rule.
- Load into a staging environment first and validate there before anything touches production.
Phase 2: the parallel run and reconciliation
With data loaded, run both systems on the same live activity for a defined window, one full billing cycle is the usual minimum, and reconcile. Reconciliation is the heart of the method: you compare what each system says and investigate every difference until it is explained. A worked, illustrative reconciliation for a single rent run:
Old system rent charged (period) = 248,600
New system rent charged (period) = 248,600
Variance = 0 OK
Old system receipts allocated = 241,900
New system receipts allocated = 241,450
Variance = 450 INVESTIGATE
-> two payments posted to old system after new-system cut
-> re-run allocation, variance clears
Deposits held and protected = match on count and value OK
Active agreements = 1,240 vs 1,240 OKA non-zero variance is not a failure. It is the method working. Every difference you find and explain during the parallel run is a difference you did not discover live after cutover with no old system to check against. Keep reconciling until variances are either zero or fully understood and accepted.
Phase 3: the cutover
Cutover is the moment the new system becomes the system of record. Because of the parallel run, it is an anticlimax by design: you have already seen the new system produce correct results, so switching is a decision, not a leap. A controlled cutover:
- Pick a cutover point that avoids the busiest moment, ideally just after a completed billing cycle so the new system starts a clean period.
- Do a final delta load of anything that changed in the old system since the last sync.
- Run the reconciliation one last time on the final state.
- Switch integrations, payments, accounting, and feeds, to the new system.
- Set the old system to read-only. Do not delete it. It is your fallback and your historical record.
- Tell the team clearly and on a specific date where they now work. Ambiguity here is the operational gap you were trying to avoid.
A migration timeline
An illustrative shape for a mid-sized portfolio. Adjust the durations to your scale, but keep the sequence.
| Phase | Focus | Old system status |
|---|---|---|
| Week 1-2 | Scope and data audit | Authoritative |
| Week 3-4 | Mapping and cleanup in staging | Authoritative |
| Week 5 | Staging load and validation | Authoritative |
| Week 6-9 | Parallel run across a full billing cycle | Authoritative, reconciled against new |
| Week 10 | Final reconciliation and cutover | Becomes read-only |
| Week 11-12 | Hypercare and decommission planning | Read-only fallback |
The parallel-run weeks are the ones people are tempted to cut. Do not. That window is where you buy the confidence that makes cutover safe, and it is the whole reason there is no downtime. For a structured programme view of the same work, see the 30-day PMS deployment guide.
The reconciliation checklist
- Entity counts match the audit: properties, units, beds, agreements, residents.
- Total rent charged for the period matches between systems.
- Receipts and allocations match, with every variance explained.
- Deposits held and protected match on both count and value.
- Arrears balances match per resident, not just in total.
- Rent schedules and future-dated changes carried across correctly.
- Documents and compliance records are attached to the right records.
- Integrations post correctly from the new system in a test transaction.
The rollback plan
Parallel running is itself most of your safety net, but write the rollback plan down anyway. Define, before cutover, the specific conditions under which you would revert to the old system, who makes that call, and how. Because the old system is preserved read-only and was authoritative until cutover day, reverting is realistic in the early hours after the switch. Keep the old system available through a hypercare period rather than decommissioning it the moment you go live. The cost of keeping it a few extra weeks is trivial against the value of a genuine fallback.
Vendor-specific realities
How hard the export step is depends heavily on the system you are leaving. Some legacy and enterprise platforms make it deliberately awkward to get your own data out in a clean, complete form, so budget time for extraction, not just import. If you are moving off a specific incumbent, these comparisons cover the common export gotchas and what to expect:
Whatever you are leaving, the method is the same: audit, map, load to staging, run in parallel, reconcile, then cut over with the old system preserved. The integrations hub and booking and onboarding capabilities in JumboTiger are built to make the load and parallel-run phases as low-friction as possible, so the migration is a few weeks of careful reconciliation rather than a leap of faith. Done this way, the honest answer to how much downtime a PMS migration needs is none.
