What was happening
The operator was running on a general-purpose property management system that did not understand room-level shared living: transfers, per-room pricing, and the support workload that comes with residents rather than tenants. A replacement had to be built, not bought, and it had to be live on a committed date with the existing data intact.
What we did.
- 01
Designed a custom build on top of a commercial CRM rather than a greenfield platform, so the parts that were genuinely standard stayed standard.
- 02
Mapped platform limits early and locked the process decisions those limits forced, before any of them could be relitigated in a build sprint.
- 03
Sequenced the modules against the cutover date and cut the ones that could ship after it, which is the decision most migrations get wrong.
- 04
Rebuilt the customer support function alongside the system, because a migration that lands on an unprepared support team looks like a failed migration.
no parallel-running, no extended dual entry
One cutover
Where it landed
- A room-level operating system the team actually uses, rather than a generic PMS with workarounds.
- Governance that held a fixed go-live date across a multi-module build.
- Support restructured around the new system rather than retrofitted to it.