How we rebuilt a live multi-tenant SaaS without downtime

You can rebuild the backend under a live multi-tenant SaaS without taking a single customer offline. It's a sequencing problem before it's an architecture problem, and the sequence is the part most teams get wrong.

When we took ownership of CORE Home, it was already running. Web and mobile both existed. A small set of pilot brokerages were live, with real homeowners and real data moving through the product every day. The inherited system had done its job getting CORE Home to market. It wasn't built for where the product was going next.

Inside Real Estate needed a foundation that could carry millions of homeowners, a full white-label rollout, and a product the business could own for years. So we rebuilt that foundation underneath the running product, six months from the first line of code to the last tenant on the new API, with no downtime. Four years on, the same platform carries more than 5,000 tenants. This is how the migration worked, decision by decision.

Key Takeaways

• Keep the rebuilt backend behind the same API the live apps already call, so only one side moves.
• Run the old and new systems in parallel over one shared data layer, so parity is automatic.
• Cut tenants over one at a time behind a feature flag, so a single broken case never takes everyone down.
• Retire the old stack only once it is empty, so the migration actually ends.

On CORE Home, without downtime meant three things: no tenant went offline, no customer was forced to update an app the day the backend changed, and the migration had a real end date. Those three constraints shaped the work more than the architecture diagram did.

A multi-tenant platform raises the stakes. For more than 90% of mid-size and large enterprises, a single hour of downtime now runs over $300,000, by ITIC's 2024 Hourly Cost of Downtime Survey. One backend serves every brokerage, so a clumsy change can hit all of them at once. The risk that matters is blast radius: how many tenants one mistake can reach.

The other quiet risk is coupling. On CORE Home, web and mobile both talked to the backend. If a backend change forced a matching client release, every tenant would have to ship an app update the moment we cut over. We treated that coupling as the first thing to design away.

The hard part of rebuilding a live platform is replacing the engine while the car is moving, for every passenger at once, with no moment where the road is closed. The new code is the easy part.

The track record for this kind of work is sobering. Data migrations are notorious for overrunning on time and budget, and most of that risk comes from moving everything at once and meeting the problems live. The way through is to make the change incremental, a strangler fig migration, where the rebuilt system grows in behind the old one and the old one is retired only once it is empty.

The inherited backend was tangled enough that a change in one surface could reach further than we expected. Performance under real load was already a problem, and the system was not sized for the roadmap. The roadmap pointed at millions of homeowners.

The obvious approach, a single big-bang cutover, is the one that gets teams in trouble. You stage everything, pick a weekend, flip the switch, and hope. If one tenant breaks, the only option is to roll everyone back. The bigger the platform, the worse that bet gets.

Multi-tenant makes all of this sharper. There is no quiet corner to fail in when one mistake can reach every tenant at once. So the entire plan came down to a single goal: shrink how far any one mistake can travel.

Four decisions did the work. We kept the rebuilt backend behind the same API contracts the live apps already used. We ran the old and new systems in parallel over one shared data layer. We cut tenants over one at a time behind feature flags. And we retired the legacy stack only once it was empty. Each one exists to shrink blast radius.

Moving one tenant at a time is slower to plan and far safer to run than moving everyone at once. Each tenant became its own small, reversible release, and the migration was a long series of those, with no single event big enough to take the platform down.

There is a real cost to this discipline. It takes longer, and it asks the rebuilt backend to be production-correct for each tenant before that tenant moves. That is the trade we wanted. We would rather spend more calendar time than carry the risk of a migration that can take every brokerage down on the same night.

The payoff shows up in what the platform carries now. Against an industry where most migrations overrun or stall, this one finished in six months, and the foundation has run for four years without a re-platform, growing by orders of magnitude since the pilot brokerages.

Three changes came with the new foundation. First, the foundation itself: we moved core behavior onto Laravel, which matched Inside Real Estate's broader stack and hiring, with clear separation of concerns. Search, valuation, and notifications became services that scale on their own.

Second, onboarding. Provisioning a brokerage used to be manual: branding, domains, account records, and mobile release steps, all coordinated by hand. We turned it into infrastructure, wired into the client's billing system, so a branded tenant now spins up automatically when a package is sold.

Third, white-label at scale. Each branded app used to carry its own build and release overhead. We moved the product onto tenant configuration: branding, domains, app names, and feature toggles all live in config, and web and mobile run from one shared codebase.

Because configuration lives in one place, a single change reaches web and mobile at the same time. What looks like two products to a homeowner is two clients of one system to us. The web and mobile experiences stay in step because the platform underneath them is genuinely one.

On the same platform, we later shipped HomeSearch AI in five months. The foundation held, which is the whole point of building it the way we did.

If you are staring at a live platform that has outgrown its foundation, design the migration path as carefully as you design the architecture. The architecture decides where you end up. The migration decides whether you survive the trip.

Three things carried us. Keep every step small enough that one failure affects one tenant. Keep every step reversible, so a bad move stays an inconvenience. And give the migration a real finish line, so you do not end up running two platforms forever.

None of this is exotic. Preserved contracts, a shared data layer, feature flags, and the discipline to turn the old thing off are ordinary tools. The judgment is in the sequence, and in refusing the tempting big-bang weekend that turns a hard problem into a dangerous one.

This is the work we do when we rebuild and scale an existing product, and it usually grows into a longer engagement. For the screens, the stack, and the numbers, the CORE Home case study has the full detail.