A prospect once asked me a question that sounded, at first, like an objection to our hosted product: “If we stop paying, can we run this ourselves?” The honest answer was yes. We had built the business on open-source software, and pretending otherwise would not have survived their first technical review.
The more useful question was what leaving would cost them. Could they export their data in a usable form? Would the configuration work outside our service? Could their team test a self-hosted deployment before a crisis? Those answers shaped the purchase decision more than any promise that they would never need to leave.
An exit path can help close the sale
When a buyer considers an open-source cloud, they compare it with two alternatives: operating the software themselves or choosing another vendor. A credible exit path makes the first alternative less frightening. That may sound bad for conversion, but it reduces the risk a buyer takes by choosing you today.
This matters especially when your product becomes part of a customer’s daily operations. The person who loves the developer experience may not be the person who signs the contract. Security, procurement, and infrastructure teams need to know what happens if your prices change, your service has an outage, or your company is acquired. “It’s open source” starts that conversation; it does not finish it.
Define what a customer can actually take
Source code is only one part of an exit. A customer might also need data, configuration, and a way to verify that the replacement deployment behaves as expected. Write down what moves with them and what does not. That document will expose gaps in your product faster than a reassuring sales answer will.
Start with a practical checklist:
- Data: Is there a documented export format, and can a customer retrieve a full copy without filing a support ticket?
- Configuration: Which settings can move to a self-hosted installation, and which depend on your cloud?
- Identity and secrets: What must the customer recreate or rotate during migration?
- Operations: What backups, monitoring, and upgrades will become the customer’s responsibility?
Run the procedure yourself against a recent version of the product. If the instructions only work with an engineer from your company on the call, you have a consulting service, not an exit path.
Do not promise that self-hosting is equivalent
Making departure possible does not require making every paid capability portable. You can charge for operating the service: managed upgrades, recovery, capacity planning, uptime commitments, and other work the customer would otherwise own. You can also sell features with terms that are clear about what remains available after a subscription ends.
The distinction is between a deliberate product boundary and a trap. A managed backup service, for example, need not become a free self-hosted feature. But customers should be able to obtain their underlying data in a documented format. Similarly, you can provide a cloud-only workflow without implying that its configuration will run unchanged on the community edition.
Say where the seams are before the sale. A buyer can assess a known migration project. They cannot sensibly assess a vague promise to “work something out” later.
Test the exit before you need it
Treat migration as a product workflow, even if you hope customers rarely use it. Give someone unfamiliar with the cloud implementation an export and ask them to bring up a working self-hosted instance. Record where they get stuck. Repeat the exercise after changes to your data model or deployment architecture.
You do not need to turn this into a one-click button on day one. A command-line export and a tested runbook may be enough for an early company. What matters is that the path is reproducible and that its limitations are stated plainly. If moving years of data will take days, say so. If a cloud-only feature has no self-hosted counterpart, name it.
Consider putting the exit procedure in the same documentation area as onboarding. Hiding it behind a contract request makes it look like something you would rather not discuss. Publishing it also gives your team a reason to keep the procedure current.
Earn the renewal without the lock-in
A customer who can leave still has to decide whether leaving is worth the effort. That is where a good hosted business earns its margin. Running software reliably consumes time; transferring that responsibility to your team can remain valuable every month.
Track what happens when customers actually consider self-hosting. Are they trying to cut costs, satisfy a deployment requirement, or escape a service problem? Each reason calls for a different response. An export tool cannot fix poor reliability. A discount cannot fix a requirement to run in the customer’s own environment.
If the only reason customers renew is that departure looks dangerous, you have deferred a product problem. Give them a usable door, then build a service they prefer not to walk away from.
Leave a Reply
You must be logged in to post a comment.