Own the accounts. Hire the supplier.
An organization pays a monthly retainer for a service it depends on and cannot inspect. The domain, the hosting, the analytics, the advertising accounts, and the content are all held by the vendor, and asking to see them is a negotiation.
Replaceable
The organization holds the accounts
- DomainVerified at the registrar
- Hosting and certificatesVerified in the account itself
- Analytics and advertisingOwner, with the supplier invited
- Content and historyExported in a readable format
Illustrative example · ownership checked from each source
The situation
This is not a story about large platforms. It is the ordinary shape of capture: a small organization, a supplier who set things up years ago, and an arrangement where every asset is registered to whoever did the work rather than to whoever owns the business. Nothing improper has to happen for this to be dangerous. It is enough that leaving would mean starting again.
How this usually goes
The bill is easy to see and the value delivered is not.
Nobody inside the organization knows which accounts exist or who holds them.
The site, the data, and the reputation it earned are entangled with the vendor's infrastructure.
Leaving is technically possible and practically ruinous, which is what capture feels like from the inside.
What happens here
Establishing the facts, regaining control, and staying out.
1. Establish the facts from primary sources
Who holds the domain, the hosting, the certificates, the analytics, the advertising accounts, and the content, each verified from a source of record rather than from what the vendor says. Ownership that cannot be verified is treated as unknown, not as fine.
2. Separate the asset from the operator
Accounts move to the organization, and the vendor is granted access to them. That single inversion changes the relationship from dependence to service, and it costs nothing technically.
3. Make the system legible
What it is built from, what it depends on, what would break, and what it is worth, recorded as something the organization can read without the vendor's help.
4. Keep what was earned
Rankings, history, customer records, and content are the organization's accumulated position. A migration plan that treats them as recoverable later is a migration plan that will lose them.
5. Rebuild on contracts, not on a relationship
Whatever replaces the arrangement is chosen for whether the organization could leave it again. The test is applied before adoption, when it is still cheap to fail.
Why this page exists
Everything else on this site is an argument about avoiding this situation. This page is what it looks like once you are in it, and the reason the principles are written as tests rather than as values. A credible right of exit is not an abstraction to the organization discovering that its own domain is registered to someone else.