One shared database, or one database per firm?
Shared-tenant cloud suites are the default answer in legal software. For many firms they work well. The question worth asking is narrower: when your client’s file sits in a table next to another firm’s file, what exactly keeps them apart — a permission setting, or the fact that the other firm is not there at all?
The difference is structural, not a setting
In a shared-tenant suite, every firm’s data lives in one database, and rows are separated by ownership columns and permission checks enforced by application code. Done well, that is perfectly adequate for many purposes — and it is how most SaaS works.
OpenLPM takes the other route. Each firm gets its own instance: its own database, its own file storage, its own credentials. There is no table in which your rows sit beside another firm’s, because the other firm does not exist in your deployment at all.
The same question applies to the client portal, and this is where the difference becomes practical. In a shared suite the portal usually reads the same store as the staff application, with additional permission rules. In OpenLPM the portal is a separate deployment with its own store: it contains the matters, documents, messages and invoices you deliberately shared, and no staff records whatsoever.
Why firms care: confidentiality is a professional obligation, not a product preference. A structure is easier to explain to a client, an insurer or a regulator than a permission model — and considerably easier to test.
How the two approaches score
Scored on the things a firm lives with after the demo: separation of firm data, updates, operational burden, exit, and cost predictability.
Our own assessment of the approaches, not a vendor’s marketing claim. Disagree in the demo — that is what it is for.
Side by side, on the things firms live with
| What is being compared | Shared-tenant cloud suite | OpenLPM |
|---|---|---|
| Where firm data resides | One shared database; rows separated by permissions | A database provisioned for your firm alone |
| Client portal | Same store, additional permission rules | Separate deployment and separate store, containing only what you shared |
| Effect of one firm’s incident | The shared platform is the blast radius | Confined to the instance involved |
| Update delivery | Fleet-wide, all tenants on the same release | Released per firm, verified first, reversible for one firm |
| Customisation | Configuration options within the vendor’s product | Firm-built procedures and configuration; the software itself is open source |
| Verifiability | Vendor assurance and certifications | Public source and a numbered build record you can read |
| Exit | Export of what the vendor exposes | Complete export, and the deployment is yours to take over |
What this approach is genuinely good at
- Everything in one place, operated for you. No infrastructure conversation at all — you buy a subscription and sign in.
- Feature breadth. Long-established suites have years of adjacent features, integrations and partner networks.
- Ecosystem and familiarity. Staff may already know the product, and recruiters may consider it a plus.
- Price at the very small end. Some suites are cheap or free for a single practitioner.
When this is the right choice — and we are not
- You do not care where your data sits relative to other firms, and you never expect to have to demonstrate it.
- You want a long list of peripheral features immediately, and are happy to wait for the ones OpenLPM is still building.
- You have no appetite for configuring procedures, permissions and trust rules around your own practice.
- You need certifications and audit reports today rather than source code and a runbook — although the account-boundary notes on our security page matter to you here, and we state them plainly rather than glossing over them.
We would rather lose a deal than win a firm that should have stayed where it was.
Moving from a shared-tenant suite
The migration is a data project, not a rewrite — and it can run in parallel.
Export and map
Clients, open matters, documents and history come across in batches you review before anything is committed.
Rebuild the firm’s procedures
The way your firm works is written into blueprints once, then applied to every matter of that type.
Run in parallel
Both systems stay live for a period, so deadlines are never held hostage by a cutover.
Cut over and switch off
Once the team is working in OpenLPM, the old subscription ends on your schedule — nothing is held to ransom.
The harder questions
Yes, per firm — which is why the pricing is per firm and visible, rather than a per-seat figure that hides the infrastructure. Firms decide whether the separation is worth the difference; many do, some do not, and that is a legitimate answer.
You trade some breadth for a narrower product that is genuinely yours: matters, procedures, time, trust, documents, portal, intake, research, compliance and insight. If a long tail of peripheral modules is the priority today, a large suite will serve you better for now.
Yes, and we prefer it. The demo instances are live, the source is public, and the isolation is described without the marketing gloss on the security page — including the limits we are still closing.
Run the comparison against your own shortlist
Bring the two systems you are actually considering. We will compare the parts that will still matter in year three: where the data sits, how updates arrive, and how you would leave.