Getting your code, accounts, and domains back

Ownership of a software asset is usually discovered rather than confirmed. An engagement winds down, a retainer lapses, and someone asks a simple question: where does this actually live? The answer involves a company that is no longer being paid. This is rarely bad faith. It is almost always drift: the domain was registered nine years ago by the person building the site, the cloud account was opened on a Friday to get a demo online, and nobody revisited either because nothing broke. Convenience compounds quietly, and then the relationship ends.

This guide covers what ownership actually consists of, which assets routinely end up in someone else's name, what a healthy agreement says, and how to make a request that gets answered. It is not legal advice. Where a request is refused there are two legitimate routes: your contract, through your own counsel, and the platform provider's documented account-recovery process for accounts that belong to your company. Nothing else.

Owning the code is not the same as controlling where it runs

Contracts talk about intellectual property. Operations run on credentials. Those are two different things, and companies tend to negotiate the first while assuming the second follows from it. It does not. Ownership of a working software asset has four parts, and a gap in any one of them can stop you from shipping.

• The intellectual property: a written assignment of the work product to your company, with any pre-existing or third-party components identified and licensed for your continued use.
• The artifacts: source code with its history, infrastructure definitions, database schema and migration scripts, design files, and enough documentation to rebuild from nothing.
• The accounts: registrar, DNS, cloud, source control organization, app stores, certificates, analytics, email sending, and payment processing, held in your company's name and billed to your company.
• The knowledge: what each environment variable means, how a deploy happens, which scheduled jobs exist, which third-party contracts are in force, and who to call when a specific thing breaks.

A company can hold the first two completely and still be unable to put a fix in front of customers. The code is yours, the assignment is signed, and the deploy target is an account you cannot log into. That failure mode is far more common than a genuine dispute over source code.

The assets that routinely sit in someone else's name

None of these are exotic. Each one gets registered by whoever was doing the work at the time, on whatever email address and card was closest to hand.

Why the domain and the cloud account hurt most

Every other item on that list has a recovery path that costs money and time. These two have a recovery path that costs money, time, and customers.

The domain is your identity, not your hosting

A domain carries your website, your inbound email, your single sign-on, your API endpoints, and every link anyone has ever sent about you. If you cannot change its DNS, you cannot move anything. The failure is not gradual either: a renewal nobody is watching becomes an expired domain and a simultaneous mail and web outage. Registrar transfers are also the slowest item on the list, gated by authorization codes and multi-day locks, so it is the asset you least want to sort out under pressure.

The cloud account is where the evidence lives

The cloud account holds more than servers. It holds the production database and its backups, the secrets, the object storage with your uploaded documents, the logs, and the billing history that tells you what this costs. Losing the source code means rewriting software. Losing the account can mean losing data that was never anywhere else, and no engineering budget reconstitutes that.

What a healthy agreement says, asked for at signing

Every one of these terms is easy to agree at signing and hard to agree at separation. Raise them while both sides are optimistic, and treat reluctance as information rather than as an insult.

• Ownership of the work product is assigned to your company, with the timing stated plainly: on payment or on delivery, but written down either way.
• Pre-existing and third-party components the vendor reuses are identified before work starts and licensed to you perpetually, so you are never surprised by a dependency you cannot keep.
• Root accounts for domains, DNS, cloud, source control, stores, and payments are held by your company; the vendor works under access you grant and can revoke.
• Handover is defined as a deliverable, not a favor: repository access, credential transfer, environment documentation, and a working build performed by someone new.
• Termination includes a transition assistance period at a stated rate, so the vendor is paid to help you leave instead of being asked to do it for free.
• There is no clause allowing work product or access to be withheld outside of a genuine payment dispute, and the dispute process is defined.

Where escrow fits

Source code escrow matters when a vendor hosts the software and you never see the code (a small SaaS platform running a core part of your operation, for example). It matters much less when you already hold the repository. If you do use escrow, define the release conditions concretely and require a verified build: a deposit that has never been checked against a clean environment is an expensive filing cabinet.

Making the request when a relationship is ending

The goal is a documented, unemotional record of a reasonable request. It makes every later step easier, and in most cases it is never needed because the request simply works.

1. 1

   Inventory before you write. List every asset the software touches, noting who receives the renewal email and which card is billed. Public registration records and your card statements tell you most of it.

2. 2

   Read the agreement and mark the exact clauses on ownership, termination, and handover. Quote them accurately or not at all.

3. 3

   Settle the money first. Pay outstanding invoices, or state precisely what is disputed and why. A large share of refusals is about an unpaid balance nobody has named out loud.

4. 4

   Send one written request that lists each asset by name, the specific action you are asking for, the destination account, and a reasonable date. Ten business days is normal for a cooperative handover.

5. 5

   Offer to pay for the handover time at the contracted rate. Vendors resist unscheduled unpaid work far more than they resist the handover itself.

6. 6

   Verify on receipt. Have someone who did not build the system deploy the application from what you were given, into an environment you control, before you close anything out.

7. 7

   If the request is refused, stop negotiating over email. Contract and dispute matters go to your counsel. For accounts registered to your company, open the platform provider's documented account-recovery process and supply your corporate registration, billing records, and domain history.

The structure that prevents all of this

The preventative rule is one sentence and it runs in one direction: the company owns the root accounts and grants the vendor access. A vendor who owns the account and grants the company access has the relationship backwards, however convenient it felt at the time.

• Create root accounts on a company group address such as a shared operations mailbox, never on an individual's personal or vendor-issued email.
• Put company billing on every account, including the small ones. The card is the strongest practical proof of ownership and the reason renewals do not lapse.
• Add vendors as scoped, named users with the least access they need, and treat that access as something that expires.
• Keep a one-page asset register listing each account, the owning email, where the credentials are stored, and the renewal date. Review it quarterly.
• Store credentials in a company password manager the vendor contributes to, not in a chat thread or an individual's browser.
• Make offboarding a checklist you run on the last day of an engagement rather than a task someone remembers six months later.

None of this requires distrusting the people you work with. Good vendors welcome it, because clear ownership protects them too and removes the unbilled work of untangling accounts years later. If you are starting an engagement, set it up this way in the first week; if you are ending one, use the inventory as the agenda for a calm final conversation.