Real control of a website requires clear rights, access your business controls and a setup another supplier can take over. The domain, content, code and supporting services need to be considered separately. A login or a folder of files does not settle the whole question of website ownership.
This matters both before commissioning a website and when considering a new website supplier. The aim is to keep the business running, obtain help elsewhere and understand what a change would involve. You do not have to operate everything yourselves to retain control, but responsibilities and the route forward should be clear.
Separate access, rights and practical handover
An administrator may be able to edit the site but have no access to the domain or backup. The business may have agreed rights to use the design but lack the files needed to change it. The code may be in a repository you control while the contact form still relies on the former supplier’s service account. This calls for three separate questions:
- What are we allowed to do? Clarify in writing the rights to use, change, develop and hand over the work to another supplier.
- What can we access? Check accounts, contact details, billing and the ability to recover access.
- What can someone else actually take over? Request files, data, documentation and a controlled demonstration that the solution works in a new environment.
A sound working relationship can accommodate these questions. A handover may require paid work even when rights and access are clear. Ask for the scope, pricing basis, notice period and who will assist. This makes changing suppliers a planned task rather than a discussion left until the relationship ends.
Start with the domain and the accounts the business depends on
For Norwegian .no domains, registration provides a right of use through a subscription. Check that the correct business is registered as the subscriber and that its contact details are current. Changing the registrar is different from changing the subscriber. Norid’s rules explain these distinctions.
You can keep a .no domain when changing registrar. Norid describes transfer codes and one-time codes as two alternatives; the one-time code is sent to the email address registered on the subscription. See Norid’s procedure. This does not automatically move the website files or your business email.
Request an inventory of DNS, the records that direct website visitors and email for the domain. When changing nameservers, preserve email settings and verification records for connected services too. A working website does not prove that email is still being delivered.
Arrange for the business to control the necessary administrative access and recovery options where the platform supports this. Use named users, appropriate roles and multi-factor authentication. Agree a fallback if the main contact leaves or loses their phone. Where a supplier uses a shared account for several clients, establish what export or new account will replace your part. The supplier’s entire account cannot simply form part of the handover.
Create one inventory of what needs to be handed over
Use this inventory in a meeting with the supplier. For each row, record the responsible person, where the documentation is kept, what is missing and when it will be resolved. Do not put passwords or secret keys in an ordinary project document.
| Area | What you should control | Evidence at handover |
|---|---|---|
| Domain and DNS | Subscriber, renewal, contact and records for the website and email. | Confirmed access and a dated copy of the settings. |
| Content and rights | Text, images, design files, fonts and terms for continued use. | Agreement, licence inventory and agreed original files. |
| Code and publishing | Repository, versions, build process and how changes go live. | A new developer can build and deploy a test version. |
| Data and media | Database, uploads, content fields and necessary relationships between data. | An export checked and imported into the test environment. |
| Services and billing | Sign-in, forms, email, payments, analytics and integrations. | An agreed account, billing contact and owner for each service. |
| Operations and recovery | Backups, monitoring, updates and incident handling. | A tested recovery process and a named owner after the move. |
On small screens, scroll the table sideways.
Clarify usage rights, licences and costs before switching
Ask for an agreement that distinguishes work delivered specifically for you from existing software, templates and third-party content. Also obtain a specific answer on whether another supplier may change and develop the material. A general statement that “the client owns the website” is a poor working basis if nobody has described its components.
Review images, fonts, themes, plugins and subscriptions individually. Who purchased the licence? What use is covered? Can the arrangement continue after a change of supplier, or will you need your own licence? Clarify updates and support too. An image appearing on the public website is not, by itself, evidence of usage rights.
These questions must be resolved against the specific agreement and applicable licence terms. If rights are disputed, obtain a legal assessment before transferring or changing material. This guide does not determine who owns the code or design in an individual client relationship.
Include handover when calculating the website’s cost over time. The cost guide provides a fictional three-year budget and shows how changing assumptions affects the comparison.
What needs to come with WordPress, Astro or Lovable?
The technology determines which components need to be mapped. Custom code gives you room to shape a solution, but the documentation and actual handover show how easily others can continue the work. Read why we build more with Astro and AI for the background to our approach.
WordPress: a content export and a full backup serve different purposes
“Tools → Export” creates an XML file containing content such as posts, pages and categories, according to the WordPress documentation. It should not be treated as a complete copy of the website. For a full handover, also inventory the database, uploaded files, themes, plugins and configuration. The WordPress backup guide distinguishes the database from the files. Check that the backup can actually be restored.
Astro and custom code: make building and operating the site clear to the next developer
Request the repository with its change history, required versions, content sources and concise instructions for building, testing and publishing. The documentation should explain which services must be available and where secret keys are configured securely. A copy of the generated website files may display the current site without being sufficient to develop it further.
GitHub supports repository transfers, subject to access and recipient requirements. Existing collaborators and some integrations may remain attached, so review access afterwards. GitHub’s documentation explains what transfers. Hosting, external databases and billing still need separate attention.
Lovable: exported code needs its data and connected services
Lovable documents that code can be exported and run outside its platform. The code export does not include the database and uploaded files; these require separate handling. A complete move also requires mapping sign-in, storage and other connected services, replacing them where necessary. See Lovable’s ownership and portability documentation. Request a test of your actual solution before ending the services it uses.
A fictional example: the code arrives, but the form does not work
Imagine a business in Vestfold changing supplier. It receives a code archive and is told the handover is complete. The new developer gets the homepage to display, but product information is missing and enquiries never arrive. This is a fictional example, not a description of a particular client.
The review reveals that product data was held in a separate database, images in a storage service and outbound email in the supplier’s account. The required software version is also undocumented. The code forms part of the delivery, but the prerequisites for using it are incomplete.
The remedy is to agree exports of the data and images, create or transfer the necessary service access and document the build process. Then check that a product displays correctly and an agreed test enquiry reaches the correct recipient. Only then does the business have concrete evidence for accepting this part of the handover.
Plan the handover in a controlled sequence
- Map the setup before giving notice. Collect agreements, the account inventory and documentation. Establish what stays, what moves, deadlines and costs. Take a verified backup before making changes.
- Assign responsibilities. Name a contact at the business and at each supplier. Agree who transfers data, changes DNS, tests email and approves the switch. Plan when the old and new setups must run alongside each other.
- Test in a protected environment. Ask the new supplier to build or restore the solution from the material received. Check editing, mobile use, forms, sign-in and relevant integrations. Use test payments and test data where possible.
- Agree the final transfer and rollback. For an online shop or portal, account for orders and registrations received after the initial export. Set the timing, any brief pause in changes and how errors can be corrected without losing new data.
- Verify and close out. Check the website, email, addresses and agreed functions after the switch. Confirm operational responsibility and backups before retiring the old hosting. Remove obsolete access and rotate keys the previous supplier should no longer use.
Keep useful page addresses where possible and plan relevant redirects when addresses change. Record a baseline before the switch and monitor errors afterwards. The SEO guide to visibility and measurement and new website guide cover content, launch checks and measurement in more detail.
Personal data needs its own plan
Establish who can access customer information during the move and use a secure transfer method. Where a supplier processes personal data on the business’s behalf, a data processing agreement must govern the relationship. On termination, the agreement must address return or deletion and the handling of copies. The Norwegian Data Protection Authority’s guidance explains these requirements. Also establish any statutory retention obligations and how backups are handled.
An agreed recovery copy should have a purpose, restricted access and a defined retention period. A supplier change is not a reason to keep personal data indefinitely. See the guide to security in AI-built websites for checks on access, data and responsibility.
Ask your supplier for a concrete handover plan
You can use this list as the basis for a request and adapt it to your agreement:
- Describe the parts of the website we have agreed rights to use, change and have developed by others.
- Show who controls the domain, accounts and billing, and what must be transferred or set up again.
- Provide an inventory of the code, content, data, media, licences and connected services needed for continued operation.
- Explain how a new supplier can build, publish and restore the solution, and how this can be tested.
- Set out the work, costs and deadlines for handover, including the final data transfer, rollback and removal of access.
If the supplier does not respond, start with the agreement, invoices and accounts the business already controls. Request written clarification of missing items and keep a record of your requests. The platforms’ official support and recovery processes may be the next step for accounts you can demonstrate entitlement to. Resolve disputes about release of material or rights before attempting to change ownership or close off access.
At Færder Marketing, we can start by reviewing the existing website and the material actually available. We can then assess what can be retained, what needs clarifying with the current supplier and whether you need a move, improvements or a new solution. Read about our website development services, or tell us what you would like to take over. Share the website address and a description of the situation; do not include passwords or customer data in the contact form.
