There's a conversation that comes up with some frequency in very specific sectors — law firms, wealth management, public sector, some financial services verticals. It always starts the same way: the head of operations explains why their sales team keeps working out of a monstrous Excel file and a shared Drive instead of a serious CRM. The short answer is almost always the same: "we can't put this in Salesforce".
The interesting part is that it's rarely a pure regulatory argument. It's a combination of regulation, vendor lock-in, lack of control over the data's lifecycle, and reasonable distrust about where client information ends up when it shares infrastructure with hundreds of other companies. This article is about why that happens, and what sits between "multi-tenant SaaS" and "legacy self-hosted".
The real problem with multi-tenant SaaS
The regulatory argument (GDPR, ISO, sector-specific) is the visible one. The one that matters operationally is different. When you put your data into a large-scale multi-tenant SaaS:
- You don't control when they update you. The vendor decides when the UI changes, when an API gets deprecated, when a database migrates. Your team finds out on Monday that the button moved.
- You don't control when they look at you. Audit logs about which vendor employees access your tenant are typically opaque. In sectors where an exposed client record is a reportable incident, that's a serious problem.
- You don't control when they pull you out. If the vendor changes pricing, changes terms or discontinues a critical feature, the cost of migrating away from a mature multi-tenant SaaS is asymmetric — limited data export, proprietary format, integrations to rebuild.
- Your data lives in a database shared with others. Serious vendors do this well, but "well" is not the same as "cannot fail". For a wealth management boutique, probability matters less than the magnitude of the failure.
None of this is a critique of the multi-tenant SaaS model in the abstract. For most companies it works and is efficient. But there is a subset of sectors where the math doesn't add up.
The real problem with legacy self-hosted
The typical reaction to the above is: "we'll deploy it on our own infrastructure". And that's where the second dead end appears. Legacy self-hosted — an open-source CRM installed on an in-house server or an EC2 instance maintained by the IT team — has different but equally serious problems:
- Ops costs more than SaaS. Patching, backups, monitoring, scaling, upgrades. In any organization where IT is not the core competence, this turns expensive and brittle.
- Features fall behind. The internal team keeps the instance running but doesn't add new functionality at the pace the market does. Three years in, you have a heavily outdated version and a tired team.
- Improvised disaster recovery. What happens if the server goes down at 6 PM on a Friday? If the answer is "depends who's on call", the answer is: there is no DR.
- The tech stack ages. What was a good stack in 2018 is technical debt today. Nobody on the team wants to touch it.
That's why the pendulum swings back to multi-tenant SaaS. And why it becomes a problem again.
Dedicated instance: the middle model
There's a third option that was operationally complicated between 2015 and 2020 and is clearly viable today: the dedicated-instance model. The idea is simple — each client deploys their own instance of the product, with their own database, on their own or controlled infrastructure — but the software lifecycle is managed by the vendor. Releases, patches, feature improvements ship to your instance like they ship to others, but the data never leaves your perimeter.
Operationally that means:
- Own database. No shared table with other clients. Backups, restore, audit are over your DB exclusively.
- Controlled infrastructure. Deployment on the cloud your IT department already accepts, or on-premise if the sector requires it. The vendor operates, but the security boundary is clear.
- Same release cycle as everyone else. Not a fork — it's the same product version that all dedicated-instance clients use. You don't fall behind on features.
- Own audit logs. Who accesses, what they access, when. Traceable and exportable.
This is what a multi-tenant SaaS cannot structurally offer — and what legacy self-hosted only offers in exchange for disproportionate operational cost.
Where this actually matters
Not every sector needs this model. The ones that typically do:
- Law firms. Client confidentiality is a legal requirement, not a preference. Information in multi-tenant SaaS is always an awkward conversation with corporate clients.
- Wealth management and private banking. Client base that often requires contractual confidentiality. Regulatory regimes that require demonstrable control over where data lives.
- Public sector and companies with public contracts. National cybersecurity schemes, sector-specific requirements about data localization.
- Professional services with clients signing tougher-than-normal NDAs. If your B2B contracts include clauses like "client data shall not reside on shared infrastructure", multi-tenant SaaS blocks you out of the gate.
In all of these cases, the question is not "do we want privacy". It is "we want a real CRM, not Excel, but the classic models block us on compliance or contract". The dedicated instance is the operational answer.
What changes, and what doesn't
Compared to a classic multi-tenant SaaS, the dedicated-instance model changes three concrete things:
- Slower onboarding. Provisioning the instance, connecting client data sources, validating the environment takes days or weeks instead of minutes. Not for companies that need to be running tomorrow.
- Tighter commitment. A dedicated instance implies a closer operational relationship with the vendor. It's the natural model for clients who want a partner, not an interchangeable software supplier.
- Much simpler compliance. GDPR, sector requirements, client audits — all cleaner when data lives in controlled and traceable infrastructure.
What does not change: the experience of the sales team using it. The UI, the pipeline, the copilot, the integrations — same. Only where the data lives changes.
Minerva follows exactly this model: a dedicated instance per client, with its own database and environment. If your sector blocks you from using classic multi-tenant SaaS and you still need a serious CRM, let's talk — we discuss the concrete requirements of your environment and validate if it fits.