Multi-Tenant Migration for ISVs

Part 4 brought the product to the web by extracting logic into a service tier and building a web front end on it. A web front end almost always raises the next question about the backend: should each customer still get their own separate install, or should one deployment serve them all? That question is multi-tenancy, and answering it is the backend shift that turns a modernized installed product into something that can be delivered like cloud software.

Single-tenant installs are the source of the sprawl

Start from the problem multi-tenancy solves. An installed-software vendor ships a single-tenant product: each customer gets their own copy, running in their own environment, on their own schedule. That is the architecture that produces the version sprawl Part 1 named — many releases across many environments, every combination supported at once. Each install is a separate thing to deploy, patch, debug, and keep secure, and the total cost of running the product is the per-install cost multiplied by the customer base.

Multi-tenancy collapses that multiplication. Instead of one install per customer, one deployment serves all of them, with each customer — each tenant — kept separate in software. There is one version running, one environment to operate, one place to patch. The version-and-environment sprawl that makes installed software expensive largely disappears, because there is no longer a population of installs in the field to keep in sync. This is why multi-tenancy is the foundation of cloud and SaaS delivery, and why it is usually the highest-impact backend change an ISV can make — though, as Part 7 discusses, the savings are real but not automatic.

The tenancy models and the trade they make

There is no single way to be multi-tenant; there is a spectrum, and the choice is a trade between isolation and efficiency.

Separate database per tenant. Each tenant’s data lives in its own database, while sharing the application tier. This gives the strongest isolation — a query simply cannot reach another tenant’s data because it is in another database — and makes per-customer operations like backup, restore, and compliance boundaries straightforward. The cost is the most infrastructure to provision and operate, which limits how far it scales.

Shared database, separate schema per tenant. One database holds a schema per tenant. A middle ground: more isolation than a fully shared model, less operational weight than a database each. It is a common landing spot for products migrating from single-tenant, because it maps reasonably onto the per-customer mental model the old architecture had.

Shared schema with a tenant key. All tenants share the same tables, and every row carries a tenant identifier. This is the most efficient — one schema, the least infrastructure, the easiest to scale to many tenants — and the hardest to get right, because isolation now depends entirely on the software always filtering by tenant. A single query that forgets the tenant predicate is a data breach. Many mature products run a hybrid: shared schema by default, with separate databases for the customers whose compliance or contractual needs require it.

The right model is dictated by the isolation your customers actually require — a healthcare or financial customer may demand physical separation — not by what is cleanest to build. Getting this choice right early matters, because it is expensive to change later.

The hard part: isolation and the tenant thread

The defining technical challenge of multi-tenant migration is that the product was written assuming customers never shared anything. Code, queries, caches, file paths, background jobs — all of it implicitly assumed one customer per install. Making it multi-tenant means threading a tenant identity through everything that touches data, so that every operation knows which tenant it is acting for and can never act across the boundary.

This is unforgiving work, because the failure mode is the worst kind: one tenant seeing another tenant’s data. A bug that would be a minor glitch in a single-tenant install becomes a confidentiality breach in a shared one. Every data path has to enforce isolation, every cache has to be keyed by tenant, every background job has to carry tenant context, and the guarantee has to hold even in the code paths nobody thinks about. The data-boundary discipline this draws on is the same one behind decomposing a database cleanly — knowing exactly what data belongs to whom and never letting a boundary leak.

How to migrate without breaking anyone

Given those stakes, the migration to multi-tenancy is exactly the kind of change you do not attempt as a big-bang cutover of the whole base. It is the slice-by-slice method again, with isolation as a first-class part of what every slice has to prove.

You build the multi-tenant platform behind the service tier from Part 4, thread tenant identity through the logic slice by slice, and validate at each step that two things hold: behavior parity — a tenant on the shared deployment gets the same results its single-tenant install produced — and isolation — that tenant can reach none of its neighbors’ data, in any code path. Parity validation covers the first; isolation testing, the second. Only when both are proven do real customers begin to move.

And they move gradually. You onboard tenants onto the shared platform a few at a time, validating each migration, with their old single-tenant installs still running until each customer is safely across. The old and new run in parallel during the transition, the way the strangler fig always lets them, so no customer is forced onto shared infrastructure before their migration is proven and a problem with one tenant’s move never touches another’s. The single-tenant installs are retired only as the base lands safely on the multi-tenant platform.

Where a shared deployment is the wrong answer

Multi-tenancy is the right destination for most ISVs heading toward cloud delivery, but it is not free of trade-offs, and it is not for everyone. The shared model concentrates risk: one deployment serving all customers means one outage can affect all of them, and the noisy-neighbor and isolation problems are real engineering work, not afterthoughts. Some customers — for regulatory, contractual, or sovereignty reasons — will require dedicated infrastructure no matter how clean your shared platform is, which is why hybrid models exist. And the operational savings depend on actually retiring the single-tenant installs, not running both indefinitely. Multi-tenancy pays off when the customer base is large enough that collapsing the sprawl outweighs the cost of building and operating strict isolation; for a handful of large, isolation-demanding customers, separate deployments may remain the right answer.

Where this leads

The backend has moved from per-customer installs toward a multi-tenant deployment, slice by slice, with data isolation proven at every step — the change that makes cloud-style delivery technically possible. But delivering software differently usually means selling it differently, and the commercial model behind most installed products — the perpetual license — was built for a world of one-time sales and shipped media. Part 6, From Perpetual License to SaaS Delivery, takes on modernizing the licensing and packaging alongside the architecture, and migrating customers onto a subscription model without breaking the contracts they are already under.