What to Put in an Agency Contract So You Actually Own the Work
Paying for work and owning it are different things. Here are the clauses and account arrangements that decide which one you end up with.
Cerno Team
Strategy
Almost every company that has worked with an external vendor for a few years has discovered at least one of these: the website cannot be moved because it runs on the agency's proprietary platform, the ad account is owned by the agency so the performance history leaves with them, the analytics data starts on the day you switched vendors, or the design source files never existed in a format anyone else can open.
None of that is usually malice. It is the default outcome when nobody specified otherwise. Contracts get reviewed for price and timeline; ownership is assumed and therefore unwritten.
This is worth getting right before you sign, because every item below is straightforward to arrange at the start and expensive or impossible to arrange at the end.
Intellectual property: transfer, not licence
The distinction that matters is between assignment and licence. A licence grants you permission to use the work. An assignment makes it yours. Many contracts grant a licence — sometimes a broad one — and it reads like ownership until you want to modify the work, or move it, or the agency ceases trading.
What the contract should say:
- IP in all deliverables transfers to you on payment, not on completion, and not by licence
- The transfer covers source materials, not only outputs — editable design files, not exported PDFs; source code, not a compiled build
- Any third-party components are listed, with their licences, so you know what you own outright and what you are using under someone else's terms
- The agency may reference the work in a portfolio, which is reasonable, but that permission is separate from ownership
Watch specifically for language making transfer conditional on continued engagement. Ownership that ends when the relationship ends is not ownership.
Source code and repositories
For anything built rather than configured:
- Code lives in a repository your company owns, from the first commit — not pushed over at the end
- You have admin access throughout, not read access on request
- Build and deployment instructions are included as a deliverable, because code you cannot deploy is not usable code
- Environment variables and configuration are documented, with secrets transferred through a proper channel
- No undisclosed proprietary dependency that stops working if you stop paying
The repository point is the important one. If code arrives as a zip file at the end of a project, you have no history, no commit record, and no way to verify what changed when. Access from day one also means you can hand the project to anyone else at any point, which is the practical definition of not being locked in.
Accounts: registered to you, agency granted access
This is where most lock-in actually happens, and it has nothing to do with the contract's IP section. The rule is simple: every account is created under your company's identity, and the agency is added as a user. Never the reverse.
That applies to:
| Asset | Why it matters |
|---|---|
| Domain registration | Losing this is losing the business address |
| DNS management | Controls where everything points |
| Hosting and CDN | Determines whether you can migrate |
| Analytics | History cannot be backfilled after a switch |
| Search Console | Same — the data does not travel |
| Ad accounts | Conversion history and learning is the asset |
| Business/social profiles | Often irrecoverable if held by a third party |
| Email and DNS records | Deliverability reputation is account-bound |
| Third-party subscriptions | Billing in your name means continuity |
The ad account point deserves emphasis. Years of conversion history and algorithmic learning sit in that account. If it belongs to the agency, changing vendors means restarting from zero — which is a switching cost you pay whether or not anyone intended it as leverage.
A defined exit
A handover clause is a sign of a confident vendor, not a hostile client. It should specify:
- What gets delivered on termination: code, files, documentation, credentials, data exports
- In what format — "a data export" is meaningless; name the format
- Within how many days, and that it is included rather than billed as new work
- A support window after handover for questions from whoever takes over
- That handover is not conditional on anything beyond settled invoices
Also agree what happens to work in progress if the relationship ends mid-project. Unfinished work with no ownership terms is the worst position to negotiate from.
Data
If the vendor processes personal data — customer records, form submissions, CRM contents — you need a data processing agreement, and under GDPR that is not optional. Beyond compliance, specify that you can export your own data in a standard machine-readable format at any time, without asking, and what happens to their copies after termination.
Platform choice is a contractual issue
A proprietary CMS you cannot export from is lock-in regardless of what the IP clause says. You may own your content and still be unable to take it anywhere useful.
Ask directly: if we ended this tomorrow, what could a different vendor pick up, and what would have to be rebuilt? Any honest answer to that question is more informative than the entire contract.
The one-sentence test
Before signing, ask: if this agency disappeared tomorrow, could someone else continue the work without rebuilding it?
If the answer is no, the contract has a gap. Find it before you sign, because the leverage you have now is the most you will ever have.
Related reading: How to Choose a Digital Agency That Actually Delivers and The Discovery Phase Is Not Optional.
Cerno engagements start at €5,000
That floor is what lets the work be done properly — diagnosis, build and handoff — without cutting corners. If that is where you are, the next step is a short application.
See if we are a fit →