Who really owns your website: domain, code and data

01The day you change provider

As long as everything goes well, nobody wonders who owns the website. The provider built it, keeps it running, updates it; you pay and get on with your work. The question comes up the day something changes: the provider closes down, raises prices, stops answering, or you have simply found one who suits you better. That day you find out, all at once, what is really yours.

A scene that happens often: a business wants to rebuild its website with a new provider. It asks the old one to “transfer the domain”, and discovers that the domain is registered to the agency. It asks for “the website files”, and receives an archive that is useless without the program it was built with. It asks for “the list of registered customers”, and is told that this is not included. Nobody did anything illegal: simply, nobody had written it down.

This chapter is meant to keep you from arriving unprepared on that day. It is not a list of suspicions about people who develop software, quite the opposite: a serious provider is the first to want these things to be clear. It is a list of questions to ask beforehand, when asking them costs one line in a quote and not a dispute.

Could you answer this question today, without calling anyone: if tomorrow you wanted to change provider, what would you take with you?

02Six assets, six possible owners

When you say “my website” you are actually talking about six different things, which are bought, registered and protected in different ways. Each one can be registered to you, to the provider or to a third party.

• The domain: the address, registered in someone’s name in a public registry.
• The server: the space where the website runs, with a hosting contract and administration credentials.
• The source code: the software written for you, protected by copyright.
• The data: customers, orders, bookings, content uploaded over the years. They are often worth more than the website itself.
• The accounts: the Google Business Profile, the analytics tools, Google’s console for websites, social media profiles, email, the payment service account.
• The content: texts, photographs, logo, videos. These have an author too, and a photo taken from a paid stock library has a license that is not always transferable.

Let’s look at them one by one, starting with the one that gets lost most often.

03The domain: what counts is the name written in the registry

For domains ending in .it there is a public Registry, run by the Institute of Informatics and Telematics of the CNR (the Italian National Research Council) in Pisa. In the Registry every domain has a Registrant (in Italian, Registrante), that is, the owner of the domain name. The technical operations are carried out by a Registrar: the company (provider, agency, hosting service) you turn to in order to register and renew.

The whole distinction is here, and it is decisive: the domain belongs to whoever is listed as Registrant, not to whoever pays for it and not to whoever uses it. If, when the website was built, the provider registered the domain in its agency’s name “for convenience”, the owner is the agency. The Registry itself explains that a simple update of the details cannot change the party the domain is assigned to: changing it requires a specific change-of-Registrant operation.

The AuthInfo code, the house key

To modify a .it domain, and in particular to change Registrar or Registrant, you need the AuthInfo code: a kind of password for the domain, which the Registrar issues to the Registrant at the time of registration. If you have lost it, you ask the Registrar; the Registry steps in only if the Registrar cannot be reached or refuses to hand it over.

Three checks to do today, in five minutes

1. Look up your domain in the Registry’s WHOIS (for .it domains it is on the nic.it website): check who is listed as Registrant.
2. Check the expiry date and who receives the renewal notices. A domain not renewed because an email ended up in a former employee’s spam folder becomes free again, and someone else can register it.
3. Ask for the AuthInfo code and keep it somewhere safe, like a password. How to look after keys properly I explain in the chapter on passwords, two-factor authentication and passkeys.

How the domain works from a technical point of view, that is, DNS, records and the HTTPS certificate, you will find in the chapter on what happens when someone types your address. A practical rule that comes from there: the domain can be with one provider and the website with another, because it is enough to change the DNS records. That is why there is no technical reason for the domain to be registered to whoever builds your website.

04The source code: who owns what was written for you

Under the Italian copyright law, Law 633 of 1941, computer programs are protected works, like books. Whoever writes them is their author, and has the right to decide who can use, copy and modify them.

The law makes an exception for software written by an employee in the course of their duties or on the employer’s instructions: in that case, unless otherwise agreed, the economic exploitation rights belong to the employer (article 12-bis). For those who rely on an external provider, an agency or a freelance professional, this automatic transfer does not exist: the contract decides.

Neither of the two is “right” in absolute terms. A ready-made management system, used by many businesses and adapted to yours, is almost always licensed: the provider improves it for everyone and you benefit from it. Software written from scratch just for you, on the other hand, makes sense to become yours. What matters is that the choice is written down, and that it is consistent with the price.

What “handing over the code” means in practice

An archive of files is not enough. A handover that is really useful to another developer includes:

• the complete source code, including the part that runs on the server, not just the visible pages;
• the database structure and the scripts to create it from scratch;
• the instructions to get the system up and running on another server: software versions, configuration, variables;
• the list of third-party libraries used and their licenses: many are open source and free, some have conditions to respect, others are paid and must be renewed;
• ideally access to the repository, that is, the archive that keeps the whole history of changes.

The quality of this handover depends on how the software was written from day one: tidy, documented code, without shortcuts that only the person who took them can find again. It is the theme of the chapter on the value of a professional developer: clean code is also code that can be handed over.

Escrow, when the software is licensed

If the software remains the provider’s but is vital to your business, there is a middle-ground solution: source code escrow. The provider periodically deposits the source code with a third party (a notary or a specialized service), and the contract establishes in which cases the deposit is released to you, for example if the provider ceases trading. You don’t receive the code as long as everything goes well, but you are not left empty-handed if things go wrong.

05The data: the most valuable asset, and the one always forgotten

After a few years, the archive of customers, orders, bookings and uploaded content is often worth more than the website that holds it. The website can be rebuilt in a few weeks; ten years of customer history cannot. Yet it is the thing people check least.

The four questions about data

• Can I export them whenever I want? From a dashboard, or on request within written time frames, with no surprise costs.
• In what format? An open format (CSV for tables, an SQL dump for the database, JSON for structured data) can be read with any program. A proprietary format ties you to the provider who invented it.
• Who makes the backups, where are they kept, and can I have a copy? A backup that exists only at the provider protects against failures, not against the end of the relationship. How to make a backup that really holds up I explain in the chapter on business backup and the 3-2-1 rule.
• Where are they physically? In which country the servers are: for your customers’ personal data it makes a difference, because transfers outside the European Union have precise rules.

The contract the GDPR makes mandatory

If the provider stores or processes your customers’ personal data on your behalf (the management system with the customer records, the portal with the accounts, the booking platform), under the European data protection regulation you are the data controller and the provider is the data processor. Article 28 of the GDPR requires this relationship to be governed by a contract or another written act: what the provider can do with the data, how it protects them, and what happens at the end of the service, that is, return or deletion.

Then there is portability under article 20: it is the right of individuals to receive their own data in a structured, machine-readable format, and to transmit them to another controller. It is meant for individuals (your customers), not for companies between themselves: for your business data, the guarantee comes from the contract. But a provider that can handle your customers’ portability requests can usually export everything else too. What the GDPR asks of a small business website you will find in the chapter on GDPR and cookies.

06The server and the accounts: in whose name, with which keys

The server the website runs on has a contract with a hosting or VPS provider. The question is the same as for the domain: in whose name is the contract, and who has the administration credentials. There is nothing odd about your developer managing the server: it is their job. But it is good for the contract to be in the business’s name, or for it to be written how and when the credentials will be handed over to you. The differences between shared hosting and a VPS, and who should administer what, are in the chapter on professional web infrastructure.

The accounts nobody remembers creating

Many accounts spring up around a website, often created in a hurry by the provider on launch day:

• the business profile on Google and on maps;
• the visitor analytics tools and Google’s console for websites;
• the email on the business domain;
• the social media profiles and the linked business pages;
• the online payment service account, which receives the money: this one, more than any other, must be yours from day one;
• subscriptions to themes, plugins, libraries or external services paid with any old card.

The rule is simple: every account is created with a business email address and ownership must be yours; the provider is added as a user or administrator, and removed when the relationship ends. Keep a list with address, service, whose name it is in and who has access. It is the document you will use on moving day.

A clean exit, in five moves

07Reading a quote with the right questions

Everything we have seen is decided in a single document: the quote, with the terms that come with it. Usually people look at the total line and the delivery times. The lines that matter for ownership are others, and they are often missing: then they need to be asked for.

The real cost is the five-year cost

Two quotes with the same total can have very different costs over time. One includes domain and server registered to you, with a clear maintenance fee; the other costs little at the start but ties the business to a platform that is expensive to leave. To compare them, add up everything you pay over five years: development, renewals, server, maintenance, third-party licenses, and the estimated cost of a possible move. The lowest quote today is not always the lowest tomorrow.

Frequently asked questions

Sources

1. .it Registry, “Modifying a domain” (in Italian): Registrant, Registrar, AuthInfo code and change of owner.
2. .it Registry, WHOIS lookup (in Italian): the registration details of .it domains.
3. Law no. 633 of 22 April 1941 (in Italian): copyright protection, including computer programs and article 12-bis.
4. Regulation (EU) 2016/679 (GDPR): article 20 on portability and article 28 on the data processor.
5. Garante per la protezione dei dati personali, the Italian Data Protection Authority, “Right to data portability” (in Italian): how the right works and the European guidelines.

Chapter updated October 2026. It is meant to help you find your way and ask the right questions before signing; it does not replace a lawyer’s advice: for an important development or license contract, it is worth having it read by someone who does this professionally.