“We want the SaaS economics without the lock-in.” That sentence, or some version of it, opens most delivery-model conversations we join — and it is the wrong starting point, because every delivery model locks you into something. Multi-tenant SaaS locks you into a vendor’s roadmap. Desktop-as-a-Service (DaaS) locks you into a broker and an image-management workflow. Private SaaS — the same application deployed into a tenant’s own account or data centre — locks you into an operational burden that never fully goes away, and usually into a version-skew problem too.
The useful question is not how do we avoid lock-in. It is which lock-in can we live with for the next five years, and what does the exit from it cost if we are wrong? Once you frame the decision that way, the three models stop looking like a spectrum from bad to good and start looking like three different bets on where your engineering capacity should sit.
What the three models actually commit you to
Terminology drifts, so it is worth pinning down what each label means operationally rather than in marketing terms.
Multi-tenant SaaS. One application instance (or one logically shared fleet) serves many customers, with tenancy enforced in the data layer and the application layer. The vendor controls the release cadence, the schema, the region footprint, and the integration surface. You get an API and, if you are lucky, an export. You do not get a copy of the running system.
DaaS. A managed virtual desktop or application-streaming layer — Azure Virtual Desktop, Amazon WorkSpaces, Citrix on a public cloud — delivers a full session to the user instead of a web application. The workload is a desktop, not a service. Lock-in lives in three places people usually underestimate: the golden image and its build pipeline, the identity and profile-management stack (FSLogix-style profile containers, Active Directory or Entra ID group policy), and the licensing terms attached to the OS and the broker.
Private SaaS (also called single-tenant, BYOC, or customer-hosted). The vendor’s application runs inside infrastructure the customer owns — their AWS account, their Kubernetes cluster, sometimes their own racks. The control plane may still be the vendor’s. This model has grown mostly because of data-residency and procurement pressure rather than technical preference, and it is the model where the support contract does more work than the architecture (market-direction: an observable pattern in enterprise procurement requirements, not a measured adoption rate).
The distinction that matters for lock-in is not “who hosts it” but who holds the operational knowledge required to keep it running. In multi-tenant SaaS, the vendor holds all of it. In private SaaS, it is split — and split ownership is where incidents get expensive.
Decision matrix: which model fits which constraint
The table below is the version of this decision we sketch on a whiteboard early in an engagement. It is deliberately about constraints, not features.
| Constraint you actually have | Multi-tenant SaaS | DaaS | Private SaaS |
|---|---|---|---|
| Data cannot leave a jurisdiction | Only if vendor has in-region tenancy and contractual guarantees | Workable — session stays in-region, data can stay in-place | Strongest fit; data never leaves your account |
| Per-seat cost must scale sub-linearly | Best; marginal cost near zero for the vendor is passed through partially | Worst; each seat is a running VM plus licence | Middling; you carry fixed infra whether seats grow or not |
| You need to customise the data model | Poor; you get fields, not schema | N/A (desktop, not app) | Good, but forks the upgrade path |
| Legacy Windows-only application must reach remote users | Not applicable | Designed for exactly this | Overkill |
| Your team has no platform engineering capacity | Best fit | Needs image and profile ops | Do not attempt |
| Audit requires you to inspect the running system | Not possible; you get attestations (SOC 2, ISO 27001) | Partial | Full |
| Exit within 90 days is a board-level requirement | Depends entirely on export fidelity | Moderate; images are portable, profiles less so | Easiest technically, hardest contractually |
Read the rows, not the columns. Most teams that regret their delivery-model choice picked on the column they liked — “private SaaS sounds safer” — rather than on the two or three rows that genuinely bind them.
Why “we’ll just migrate later” underestimates the bill
Migration cost between delivery models is dominated by one thing, and it is rarely the thing in the plan. It is not compute, not storage, not even the application rewrite. It is semantic reconstruction of state.
When you export from a multi-tenant SaaS, you get rows. You do not get the derived state: the workflow positions, the permission graph as the vendor computed it, the soft-deleted records that downstream reports still reference, the enum values that were renamed in a release two years ago but persist in older rows. Rebuilding that meaning on the other side is the work. In the migrations we have supported, the data-mapping and reconciliation phase consistently consumes more calendar time than the infrastructure build (observed across TechnoLynx engagements; not a published benchmark, and heavily dependent on how long the source system has been in use).
Three practical consequences follow.
First, export fidelity is a procurement term, not a technical feature. Ask, before signing: does the export include audit history, attachments, and referential keys, and is it available without a support ticket? A nightly full export to object storage in your own bucket changes your exit cost by an order of magnitude compared with a request-based CSV dump. This is the single highest-leverage clause in a SaaS contract and the one most often left to the vendor’s default.
Second, integration surface is stickier than data. A vendor’s data is usually extractable in some form. The forty internal scripts, dashboards, and Zapier-style automations that grew around its webhook payloads are not. Lock-in accumulates at the edges, in code nobody owns, and it is invisible until the migration kickoff meeting.
Third, in DaaS the migration unit is the image, and images rot. A golden image built with a hand-tuned sequence of installers and registry tweaks is not portable to another broker; one built through an automated pipeline — Packer, or an equivalent declarative build, with application layers separated from the base OS — largely is. The decision that determines your DaaS exit cost is made on day one of the image pipeline, not on the day you decide to leave.
Private SaaS is not a lock-in escape hatch
This is the most common misreading we encounter. Running the vendor’s software in your own account feels like control, and in some respects it is: your KMS keys, your VPC, your logs, your ability to pull the plug. What it does not give you is independence from the vendor’s engineering decisions.
Consider what actually happens over three years of a private-SaaS deployment. The vendor ships releases. You are on version N-3 because your change-control window is quarterly and their cadence is fortnightly. The vendor’s support engineers no longer have a test environment matching yours. A CVE lands in a transitive dependency, and the patched version requires a Kubernetes minor bump your platform team scheduled for next quarter. Nobody is at fault, and yet you are now operating a bespoke system with a support contract written for a standard one.
Version skew is the private-SaaS failure mode, and it compounds quietly. The mitigations are unglamorous: a hard maximum version lag written into the contract, an upgrade rehearsal environment the vendor can actually reach, and a clear line on who is paged when the application is healthy but the node pool is not. We have seen private-SaaS deployments run well for years — every one of them had those three things in writing before go-live.
There is a related trap on the cost side. Private SaaS moves spend from a per-seat line item to an infrastructure line item, which makes it look cheaper on the software budget while the cloud bill absorbs the difference plus the platform-team time. If you are evaluating on total cost, the comparison has to include operational headcount; the same discipline we describe in our work on reduction strategies for cloud spend that survive an actual audit applies here, because an idle single-tenant cluster is a rounding error nobody notices until the annual review.
How do you tell whether lock-in is dangerous or merely inconvenient?
Not all lock-in deserves a mitigation budget. The test we use has four questions, and the answers matter more than the score.
- Substitutability. Are there at least two credible alternatives that could serve the same job? If yes, lock-in is a negotiating position, not a risk. If the vendor is genuinely unique in its category, you are exposed regardless of architecture.
- State volume and age. How much accumulated state would need semantic reconstruction, and how old is the oldest record you still depend on? Systems of record with a decade of history are far harder to leave than systems of engagement with a rolling twelve-month window.
- Blast radius of a bad outcome. If the vendor doubles its price, sunsets a module, or gets acquired, does that stall a project or stop revenue? Only the second case justifies a parallel-path investment.
- Exit rehearsal. Have you ever actually performed the export and loaded it somewhere? A restore you have never tested is a plan, not a capability.
A vendor relationship that scores badly on substitutability but well on state volume is usually fine. One that scores well on substitutability but holds ten years of irreplaceable state is where the real risk sits — and that combination is common, because comfortable long-running systems are exactly the ones nobody rehearses leaving.
Where AI workloads change the calculus
Delivery-model decisions used to be about applications. Increasingly they are about where inference and embeddings live, and that shifts the weight of the criteria.
Two things drive it. Model-serving stacks are heavier and more opinionated than CRUD applications — a deployment that depends on specific CUDA and driver versions, a TensorRT engine compiled for one GPU generation, or a pinned PyTorch build is far less portable than a stateless web service. And retrieval state is a new kind of lock-in: embeddings are model-specific, so an index built with one embedding model is not portable to another without a full re-embed of the corpus. That is a compute bill and a quality-regression risk at the same time.
This is why the storage-layer choice under a retrieval system deserves the same scrutiny as the delivery model above it; our comparison of open-source vector databases for AI workloads covers the operational differences that determine whether a re-embed is a weekend or a quarter. If your product is itself a SaaS offering, the delivery-model choice also interacts with segment strategy — the trade-offs in choosing between a vertical and a horizontal SaaS model often decide whether private SaaS is a viable tier at all, because a narrow vertical with ten large enterprise buyers can support single-tenant deployments that a horizontal product with ten thousand accounts cannot.
For teams working through where a workload should sit and what the migration path looks like, our AI infrastructure and SaaS work is built around exactly this class of decision.
A worked comparison, with the assumptions stated
Assume a 400-seat internal analytics application, currently multi-tenant SaaS at a per-seat price, with a procurement requirement that data stay in the EU. The team is considering private SaaS. Illustrative figures, not a quote:
- Multi-tenant, in-region tenancy available. Software cost scales with seats. Operational cost near zero. Exit cost governed entirely by export fidelity. Residency satisfied by contract plus attestation, not by inspection.
- Private SaaS. Software licence typically restructured as a platform fee, so per-seat scaling advantage disappears. Add a single-tenant Kubernetes footprint sized for peak, not average — which for a business-hours analytics workload means paying for roughly three times the capacity you use unless you invest in scheduled scaling. Add roughly a quarter to a half of a platform engineer’s time, indefinitely, for upgrades and incident response.
- Break-even. Private SaaS tends to win on cost only at large seat counts, or where the residency requirement is a hard blocker rather than a preference. At 400 seats it usually loses on cost and wins only on the audit row of the matrix above.
If the audit row is the binding constraint, private SaaS is correct and the cost is the price of the requirement. If the residency concern is satisfiable by in-region multi-tenancy, the private deployment is buying a feeling rather than a capability. Naming which one is true is the whole decision.
FAQ
What is the practical difference between SaaS, DaaS and private SaaS?
Multi-tenant SaaS is one shared application fleet serving many customers, with the vendor controlling releases, schema and region footprint. DaaS delivers a full virtual desktop or streamed application session, so the unit of deployment is an OS image rather than a service. Private SaaS runs the vendor’s application inside infrastructure the customer owns, which splits operational responsibility between two organisations.
Does private SaaS eliminate vendor lock-in?
No. It removes hosting dependency but keeps you dependent on the vendor’s engineering decisions, release cadence and support model. The characteristic failure is version skew: your change-control window is slower than their release cadence, so within a few years you are running a bespoke deployment under a support contract written for a standard one.
What dominates the cost of migrating between delivery models?
Semantic reconstruction of state, not infrastructure. An export gives you rows, not the derived meaning around them — workflow positions, the permission graph, soft-deleted records that reports still reference, renamed enum values that persist in old data. In the migrations we have supported, mapping and reconciliation consistently takes more calendar time than the infrastructure build.
Which contract terms most reduce exit cost?
Export fidelity terms: whether the export includes audit history, attachments and referential keys, and whether it lands in your own object storage on a schedule rather than arriving via a support ticket. For private SaaS, add a maximum permitted version lag, a vendor-accessible upgrade rehearsal environment, and an explicit split of paging responsibility.
How do AI workloads change the delivery-model decision?
Model-serving stacks are less portable than ordinary applications because they pin CUDA, driver and framework versions, and often compile engines for a specific GPU generation. Retrieval state adds a second lock-in: embeddings are model-specific, so changing embedding model means re-embedding the whole corpus, which is both a compute bill and a quality-regression risk.
When is DaaS the right answer rather than a web application?
When the workload is a legacy desktop application that cannot be re-platformed and must reach distributed users, or when the security model requires that data never reach the endpoint. It is the most expensive per seat of the three models, so it is justified by constraint rather than economics — and its exit cost is set by whether the golden image is built declaratively or by hand.
The question to settle before the architecture review
Before anyone draws a diagram, get an answer to this: which single row of the constraint matrix, if violated, would stop the project? Residency, audit inspection, per-seat economics, customisation depth, or platform capacity — one of them usually dominates, and the honest answer often contradicts the model the team has already half-chosen. Teams that name that row first tend to pick a model they can defend three years later; teams that start from “which model is best” end up defending a preference.
And then rehearse the exit once, early, while the relationship is good. An export you have loaded into a staging system is a capability. An export clause you have never exercised is a sentence in a contract.
