When should a SaaS product introduce multi-tenancy?

Start with the segment and the economics

Introduce shared infrastructure when it is required to serve the next customer segment profitably, not simply because a prospect mentioned it. Compare the cost of operating separate deployments with the cost of building and supporting a shared model. Include the ongoing work: provisioning, upgrades, monitoring, incident response and billing reconciliation.

Compare pooled, dedicated and hybrid models

The right model depends on the isolation a customer segment will pay for and the support burden you can carry. A mixed estate may be appropriate, but each variant adds another path to operate.

• Pooled: one application and shared data store with tenant-aware boundaries. Usually the lowest operating cost per tenant at scale, with one upgrade path; isolation depends on application, query and export controls. Suitable for many similar accounts with limited isolation needs.
• Dedicated: separate infrastructure or a database per tenant. Usually the strongest isolation, with room for customer-specific operations; also the highest provisioning, patching, monitoring and support cost. Suitable for large or regulated accounts that require separation and will fund it.
• Hybrid: a shared application with dedicated data or infrastructure for selected tenants. Balances isolation and operating cost; adds routing, schema change, reporting and support complexity. Suitable when one segment needs stronger guarantees without a separate product.

Define isolation and support responsibilities

Isolation can apply to data, configuration, reporting, integrations and support access. Decide which guarantees each segment needs and how you will test them. Name who can view customer records, change configuration, run exports and respond to an isolation incident.

• Data storage, query and export boundaries.
• Configuration, entitlement and permission changes.
• Reporting access and support impersonation controls.
• Provisioning, upgrades, monitoring and incident ownership per model.
• A test that attempts cross-tenant reads, writes and exports.

Plan migration and assign responsibility

Existing customers may need a different migration path from new ones, and the tenancy model should not be changed without an owner. Document how accounts move, who validates the data, how support handles the transition and how a failed move is reversed. Prove the boundary with tests before the first large customer arrives.

• Inventory accounts, data volume, integrations and custom configuration.
• Choose which accounts move first and which remain on the current model.
• Define validation, cutover, rollback and communication responsibilities.