If you’ve built a monolithic enterprise product, it is not sensible to convert it to multi-tenancy. You can sell a managed service provider (MSP), but you’re not going to get to software as a service (SaaS).

Often no one wants to discuss reasoning at all, because the need to convert your business to a different model is taken as an imperative which overrides any reasoning. Present problems are ignored, because the future state is too valuable to ignore. Unfortunately, “skating to the puck” in this case is leaving the rink, and the result looks like disrupting yourself.

But what about customers who demand multi-tenancy? There are very few customers who actually need multi-tenancy features. Let’s take a moment to clarify what these features are, because a lot of folks confuse multi-tenancy with role-based access control (RBAC).

Multi-tenancy lets you operate a single instance of a product for multiple groups of people, keeping content, capabilities, and configurations hidden from users who aren’t members of the correct group. Multi-tenancy features allow for a super administrator who can configure which tenants are part of which environments. They allow for tenant administrators who can configure which users and groups are part of a single tenant. They allow for tenant users who do the job that the software is for.

Most customers do not need multi-tenancy features for themselves, they need to be tenants and they hope that the vendor is using modern cloud techniques to deliver features cheaply. Maybe they want administrivia to be separated or hidden away so that the result is delivered as a service. This doesn’t mean the customer wants multi-tenancy. It means the customer wants your software as a service.

The exception is the customer who plans to provide your software to their own customers as a service. This customer does want multi-tenancy features: they want to manage the access rights of business units A, B, and C. This customer is not going to be happy with a stack of singleton instances of the software. This customer needs a professional services development partner, or perhaps a different software vendor. They are asking the vendor to sell a product that allows configuration and maintenance of a multi-tenant environment.

The whole conversation rests on an assumption that the resulting software environment will be simpler and cheaper to set up and use than a stack of singleton instances. I see no evidence for that assumption when the software in question was not designed from the ground up as a multi-tenant application. It’s far better for the vendor to offer their software in singleton mode as a managed service. This effort will inevitably produce the tools necessary to support and automate software installs, which the company can decide to sell to selected customers if they like; but those tools do not need to be exposed to all customers.