What "no vendor lock-in" actually means for hosting

"No vendor lock-in" is on the website of nearly every agency that has ever locked a client in. It is a claim with no definition attached, which makes it worth exactly nothing until somebody attaches one.

So here is a definition you can test:

You are not locked in if you can end the relationship tomorrow, with no notice and on bad terms, and your systems keep running.

Note the wording. Not "if we part ways amicably." Not "we'd of course hand everything over." On bad terms. Lock-in is only ever discovered in the situation it is designed to exploit, and by then asking nicely is not a strategy.

Where lock-in actually lives

It is rarely a clause in a contract. It is usually structural, and often unintentional — which does not make it cheaper.

1. The infrastructure is in their account

The single most common one. The server, the domain, the CDN, the email — all provisioned under the agency's billing, because it was easier at the time and probably was.

What it means in practice: you do not have root. You cannot see the bill. You cannot revoke their access, because their access is the account. Migrating means asking the party you are leaving to help you leave.

Domains are the sharpest version. A domain held in someone else's registrar account, with their email on the WHOIS, is the whole business held hostage by an asset that costs twelve dollars a year.

2. Deploys only they can perform

If shipping a change requires a machine with a particular SSH key, a particular script, or a person who remembers the sequence, then that person is a dependency regardless of what the contract says. The code being "yours" is irrelevant if nobody else can get it onto a server.

3. Proprietary tooling in the path

An agency's in-house framework, CMS, build tool or "platform". Sometimes genuinely good. Always a hiring problem: the pool of engineers who can maintain it is the set of people who have worked at that agency.

The tell is a technology whose documentation exists only inside the company that sold it to you.

4. Undocumented knowledge

The quietest one and the hardest to detect while things are going well. The code is yours, the server is yours, the stack is standard — and nobody except the original engineer knows why the cron job at 04:00 exists, or which of the three environment variables is load-bearing.

This is lock-in by omission. It is usually not malicious. It is just what happens when nobody was ever asked to write it down.

5. Data you cannot get out in a usable shape

"You can export your data" is not the same as "your data is portable". A CSV of orders without the customer relations, or a database dump with no schema documentation, is technically an export and practically a puzzle.

Seven questions to ask before you sign

Ask these of any agency, including us. The answers are more informative than anything on the services page.

1. Whose name is on the hosting account and the domain registration? If the answer is not "yours", ask when that changes and get a date.
2. If I hire an engineer next month, what do you hand them? Listen for "the repository, the runbooks and the credentials." Listen for whether "runbooks" was already in their vocabulary.
3. Can I deploy without you? Not "would you show me" — can I. A documented command, or a button, or a git push.
4. What in this stack is not open source or a major cloud service? Every item on that list is a future hiring constraint.
5. What happens to backups if I stop paying you? Backups in the agency's storage account vanish with the relationship, exactly when you need them most.
6. Show me the handover documentation from a previous client. Redacted is fine. Either it exists or it does not, and you will learn which in about four seconds.
7. What does offboarding cost? There is a right answer and it is "nothing". A migration fee is a departure tax, and a departure tax is lock-in with an invoice attached.

What the good version looks like

Concretely, and this is what we do — stated so you can hold us to it rather than as a promise you have to take on faith:

• The server is provisioned on the client's own account. Hostinger, DigitalOcean, AWS, wherever. The billing is theirs, the root credentials are theirs, and we get access — not the reverse. This is slightly more work to set up and it is the whole ballgame.
• The domain is registered to the client, with their details on the WHOIS. Always. There is no version of this that is easier for us and acceptable.
• Deploys are a git push, running through a pipeline defined in a file in the repository. If we disappear, the pipeline is still there and still readable.
• Nothing proprietary. Standard frameworks, standard databases, standard container tooling. Any competent engineer can read it.
• Runbooks for every routine operation — deploy, rollback, restore from backup, rotate a credential, add an environment. Written for someone who has never seen the system.
• Offboarding is free, and consists of us removing our own access.

The uncomfortable part

All of this is worse for the agency, in the narrow sense. Lock-in is retention. A client who cannot leave does not leave, and revenue from a client who cannot leave is the most predictable revenue there is.

The argument for doing it the other way is not charity. It is that an agency which has to be re-chosen every month is under permanent pressure to be worth choosing, and that is a healthier arrangement for the work than a client who stays because the exit is expensive.

It also changes the sales conversation. When leaving is free, "why should I trust you" stops being the question, because the cost of being wrong about us is one month.

If you are already locked in

It is recoverable, and usually less dramatic than it feels. Roughly in order:

1. Get the domain first. Request the auth code and move it to a registrar in your own name. It is the cheapest and most important step, and it is often the only one that is genuinely urgent.
2. Get a copy of the code, including the full git history if it exists. History is documentation.
3. Take your own backup of the database and any uploaded files, stored somewhere you control.
4. Write down what you do not understand. That list is the actual scope of the problem, and it is usually shorter than the anxiety suggests.
5. Then plan the migration. Not before — a migration started without the first four steps is how people lose things.

None of that requires the incumbent's cooperation, and doing it while the relationship is still fine is far easier than doing it after it is not.