In short and in plain language
Who owns the website? This question often comes up only when you switch. That may be a new provider or a dispute.
A website is made of rights, files and logins. Each part has its own rules. For the rights, the purpose of the job matters most.
A domain is the address of your website on the internet. What matters is who is listed as its owner. A provider usually has to hand over files and data.
Your own copy of the website helps in an emergency. So does a list for the handover.
We hand over the domain, files and logins to you with full notes.
The site is running, the invoice is paid, and the ownership question surfaces the day something is meant to change: a new provider, a relaunch, a parting of ways. Then it becomes clear that "the website" is not one object you hand over like a key. It is rights, files and credentials, governed by three sets of rules. Copyright law says what you may do with the delivered work; agency law says which materials you are owed; data protection law and the EU Data Act say in what form and within what deadline data comes back. This article sorts the layers, sources every statement and ends with a handover list.
Key takeaways
- "The website" is a bundle: usage rights, files and data, credentials. Each part follows its own rules, and a joint handover happens only if it was agreed.
- If the contract does not name the types of use individually, its purpose determines the scope of the rights granted (UrhG). What the purpose does not carry was not granted either.
- The domain holder is the party materially entitled to the domain (DENIC). The password for moving a .de address is valid for 30 days (DENIC).
- Whatever an agent obtains from the engagement must be handed over (BGB). Personal data is deleted or returned at the controller's choice (GDPR).
- For data processing services the EU Data Act sets deadlines: notice at most 2 months, transition at most 30 calendar days, a retrieval window of at least 30 calendar days, and from 12 January 2027 no switching charges (EU Data Act).
Why the question only surfaces at the switch
Nobody asks about rights while everything runs. The question surfaces only when something changes beyond day-to-day work: a new design, a move to another server, taking the copy elsewhere. Running your own site is long since the norm. In the EU, 79.02 percent (Eurostat) of enterprises with at least ten employees reported having a website; the share ran from 76.67 percent for small to 95.65 percent (Eurostat) for large enterprises. In Bavaria, 92 percent (Bayerisches Landesamt für Statistik) of enterprises with at least ten persons employed had a website in 2025.
Who looks after those sites explains why handovers stall. 54 percent (Statistisches Bundesamt) of enterprises in Germany with at least ten persons employed bought paid IT services online in 2025. For in-house IT staff, the most recent officially published figure from that survey is considerably older: in survey year 2019, only 19 percent (Statistisches Bundesamt) of enterprises with at least ten persons employed had in-house IT specialists, and security tasks were carried out by external providers in 50 percent (Statistisches Bundesamt) of enterprises. Both figures describe 2019, not today. Those credentials therefore sit outside your own building in many cases.
Both sets of figures describe one position: the business carries the responsibility, the technology sits with others. That works while the relationship holds and becomes a problem where it ends. There it is decided whether a website relaunch is planned work or a reconstruction from screenshots. Which signs argue for a rebuild is covered in the article on seven signs it is time for a new website; this piece is about what you may take with you.
Outsourcing is not the mistake, ambiguity is
Three layers to be settled separately
The most common error is treating "the website" as one thing. Ask for handover at a provider switch and an archive of files comes back. In fact two layers remain untouched: the rights that say what you may do with those files, and the credentials without which the files run nowhere.
Rights in the work
Design, copy, images and code are protected works or performances. You receive usage rights to the extent the contract provides; without a list, its purpose determines the scope (UrhG).
Files and data
Source files, images at original resolution, database exports, form submissions and reports. The agent hands over what was obtained from the engagement (BGB); personal data follows the processing agreement (GDPR).
Credentials and accounts
Domain administration, hosting, content system, DNS, certificate, mailboxes and measurement. Without those accounts the site cannot be moved, even when rights and files are complete.
These layers can be checked one by one, and so they should appear in the contract. A clause promising "handover of all materials" does not cover the rights layer: usage rights arise from a grant, not from handover. Conversely, a generous rights clause helps little if nobody can reach the domain account.
Rights: what the purpose of the contract decides
The central provision on the scope of usage rights is short. If the types of use are not expressly named individually when a usage right is granted, the scope is determined by the purpose of the contract as understood by both parties, says Section 31(5) of the German Copyright Act (UrhG). In practice: if the quote says only "creation of a website", using it as a website is covered. Whether further development by another provider, print use of the design or reuse of components for a second brand belongs to it is decided by that shared purpose - and argued about afterwards. Hence the list belongs in the contract.
What the wording does and does not do
The second point concerns transfer. A usage right may only be transferred with the author's consent, says Section 34(1) (UrhG). That is the case arising at every provider switch: you want to hand the existing site to the new provider to maintain. It needs either a matching grant in the original contract or the author's consent. Written permission at the point of engagement is straightforward; the same permission after a separation is harder to get.
Special rules apply to program code. Computer programs are protected if they are individual works in the sense that they are the result of their author's own intellectual creation, says Section 69a(3) (UrhG). The threshold is low: own creation counts, not artistic merit. For employed developers the position differs: where a program is created by an employee in the execution of their duties, the employer is exclusively entitled to exercise all economic rights unless otherwise agreed (Section 69b(1) (UrhG)). That allocation does not cover commissioned third parties - a distinction rarely considered.
This article sorts the questions, it does not advise
Two provisions work in the operator's favour. Unless specific contractual provisions apply, certain acts do not require the rightholder's authorisation where they are necessary for the use of the program in accordance with its intended purpose, including error correction, by a person entitled to use a copy (Section 69d(1) (UrhG)). Whoever lawfully operates the site may have a fault fixed unless the contract says otherwise. The second rule is clearer still: the making of a back-up copy by a person entitled to use the program may not be prevented by contract insofar as it secures future use (Section 69d(2) (UrhG)).
The flip side belongs in the picture. Anyone who infringes intentionally or negligently is liable to the injured party for damages, says Section 97(2) (UrhG). Whoever keeps running a design or codebase after a separation without holding the rights carries that risk - so the rights question belongs before the move.
| Common assumption | What the wording says | Source |
|---|---|---|
| Whoever pays owns everything | Without individually named types of use, the purpose of the contract determines the scope of the grant | Section 31(5) (UrhG) |
| I can simply pass the site on | A usage right may only be transferred with the author's consent | Section 34(1) (UrhG) |
| An adapted template is not protected | Protection exists where the program is its author's own intellectual creation | Section 69a(3) (UrhG) |
| Commissioned code belongs to the client like employee code | The allocation to the employer covers employees, not commissioned third parties | Section 69b(1) (UrhG) |
| A back-up copy can be ruled out by contract | A back-up copy by an entitled person may not be prevented by contract | Section 69d(2) (UrhG) |
| Credentials are the provider's trade secret | Everything the agent obtains from the engagement must be handed over | Section 667 (BGB) |
The domain: the holder is the holder
With the domain the position is clearer than elsewhere, and yet this is where most complications arise. For .de addresses, the registry's domain guidelines provide that the domain holder is the contracting party and thus materially entitled to the domain (Clause VI (DENIC)). What matters is who is recorded as holder, not who pays. The .de space has passed the threshold of 18 million (DENIC) registered domains, which statistically means almost every sixth inhabitant of Germany holds a .de address (DENIC).
Moving a .de domain runs via a password the registry stores or issues. The process is fast; the limiting factor is the deadline on that password. It is valid for 30 days from deposit or issue and can be used once (DENIC). Generic endings such as .com follow a different rule set; there a transfer may be denied if requested within 60 days (ICANN) of the creation date. Anyone moving a fresh address should plan for that lock.
- Look at the holder record. The name recorded there is the legal position - regardless of who pays.
- Think about the administrative contact. That entry decides who can trigger changes - convenient while the cooperation runs, obstructive once it ends.
- Your own account with the registrar. A contract in your name makes the handover question moot.
- Know the transfer deadlines. The password for a .de move expires after 30 days (DENIC); with generic endings a request may be denied within 60 days (ICANN) of registration.
- Monitor renewal. An address that lapses because the previous caretaker stops renewing it is an expensive loss of control.
The domain outlives every design
Files and data: a claim, not a favour
For the file layer there is a provision rarely quoted that still hits the point. The agent is obliged to hand over to the principal everything received in order to carry out the engagement and everything obtained from conducting it, says Section 667 (BGB). Applied to a website: whatever was created or collected in the engagement belongs in your hands - image files at original resolution, database exports, form entries and credentials made for you. The claim exists whether or not the contract repeats it; spelling it out saves the argument about "everything".
For personal data, data protection law is added. The processing agreement must provide that the processor, at the controller's choice, deletes or returns all personal data after the end of the services, unless storage is required (Article 28(3)(g) (GDPR)). The choice is yours. The right to data portability describes the quality a handover needs: data subjects have the right to receive their data in a structured, commonly used and machine-readable format (Article 20(1) (GDPR)). It governs data subject and controller, yet works as a yardstick for your own agreement: a printout is not a data handover. The basics are sorted in the article on GDPR basics for small websites.
Credentials: the keyring of the website
The third layer is the least spectacular and, in an emergency, the hardest. Rights can be renegotiated and files reconstructed - a missing credential takes a site offline. This is the keyring to keep together.
- Domain administration. The registrar account including access to request the transfer password.
- Hosting or server access. Control panel, file and database access, each in your name.
- Content system. An account with full administrative rights, not merely an editor account for copy.
- DNS administration. Name resolution often sits elsewhere than the domain. Note both separately.
- TLS certificate. The account or procedure through which renewal runs, so encryption continues without help.
- Email mailboxes. Access to mailboxes and forwarding - password resets for every other service hang on them.
- Measurement and search console. Owner rights, otherwise success measurement restarts at zero after the switch.
- Directory and map profiles. Ownership of the business profile and comparable entries pointing to the site.
One item creates time pressure. The lifetime of publicly trusted TLS certificates has been shortened: since 15 March 2026 the maximum validity is 200 days (CA/Browser Forum). Whoever lacks that access and can no longer reach the previous caretaker soon faces a site greeting visitors with a security warning. What happens then is covered in the article on the SSL certificate and the "not secure" message; the wider frame is described in the article on website security for small businesses.
What the EU Data Act sets as deadlines
The EU Data Act has applied since 12 September 2025 and has a chapter on switching between providers of data processing services. The scope needs reading closely: it covers compute, storage and platform services, not every agency service. Where hosting or an operated platform is in the contract, the requirements apply. They frame the switch in time: a notice period for initiating it that may not exceed 2 months (EU Data Act), and a binding transition period of at most 30 calendar days (EU Data Act) after that notice period, during which exportable data and digital assets are transferred.
The claim does not end there. For retrieval the same provision prescribes a minimum of at least 30 calendar days (EU Data Act), beginning after the agreed transitional period expires. The cost side has a date too: from 12 January 2027 (EU Data Act), providers of data processing services may no longer charge switching fees. Anyone renewing a contract today can take those figures into the negotiation.
Deadlines are a frame, not a schedule
Your own back-up copy as a fallback
All layers so far presuppose cooperation. Only the back-up copy works without it and cannot be taken away by contract: its making by a person entitled to use the program may not be prevented insofar as it secures future use (Section 69d(2) (UrhG)). The measure is widespread: backing up data to a separate location or to the cloud was, at 79.23 percent (Eurostat), the second most common ICT security measure in EU enterprises. A back-up held solely by the provider, though, shares the problem it is meant to solve.
A usable back-up of your own is the file inventory, a database export and a note saying which version is from when - stored where you reach it without the provider. How that fits into ongoing support is described in the article on website maintenance; as a service package it sits under maintenance packages.
The handover list for the real case
The order below begins with what takes longest and shows which points belong in an agreement.
- Read the contract and mark the rights clause. Does it list the types of use? Is modification named? Is passing on allowed? Without those details the purpose of the contract decides (UrhG).
- Check the domain holder record and, if needed, start the change of holder - the item with the longest lead time.
- Draw up an inventory of accounts: domain administration, hosting, content system, DNS, certificate, mailbox and measurement, each with the account holder's name.
- Request handover in writing, citing the agent's duty to hand over (BGB) and, for personal data, the processing agreement (GDPR).
- Name the format of the handover. Database export, file inventory, images at original resolution, form submissions; machine-readable is the yardstick data protection law sets (GDPR).
- Set deadlines that match the rule set. Where the EU Data Act applies, notice and transition periods are capped (EU Data Act); otherwise the contract governs.
- Take your own back-up copy before giving notice. That is permitted (UrhG) and takes the sting out of it.
- Take over the accounts one by one and change the passwords afterwards. An account carried over with its old password is not yet yours.
- Move two-factor procedures onto your own devices. A second factor on the former caretaker's phone keeps the dependency alive.
- Measure availability again once everything is switched: site, encryption, mailboxes, forms, redirects.
A website belongs to you to the extent three things are settled: which rights were granted, which files must be handed over and whose name the accounts run in. The rest is trust - a basis for working together, not for parting ways.
Whoever settles these points before the engagement negotiates from a relaxed position; whoever settles them after giving notice, from a tense one. How an engagement can be scoped with the handover in mind is shown in the article on fixed price and hourly rate. Whether the site pays for itself is covered in the article on counting enquiries, and environmental statements face extra requirements that the article on the new rules for environmental claims sorts out.
How we handle it
Sources and studies
Related Articles
Website Relaunch: 7 Signs It Is Time for a New Site
Seven clear warning signs that a website relaunch is worthwhile: not mobile, slow, outdated, no SSL. How to relaunch while keeping your Google rankings.
Craft Business Website: Market Dates and Unique Pieces
A market calendar, one-off pieces with stock levels and a commission form: how a craft business sets up its website, with a clear line on withdrawal rights.
One page or several pages: what a starter site needs
When is a one-pager enough and when does a website need several pages? Three triggers for expanding, figures from Bavaria and a path to grow without a rebuild.