Domain, hosting and business accounts: what to check at website handover

Damian Baranowski, websites for small businesses
Published: 14 November 2026

At website handover, check that you can manage the domain, renew services, recover account access and restore the site. A login for editing text is not enough. Here is what to collect and how to adapt the checklist to WordPress, a simple static site or an online website builder.

Domain, hosting and accounts are three different things

The domain is the address customers use to find your website. Hosting is the service that makes it available. Accounts determine who can change settings and content. These services may come from one provider or several. Email, booking calendars and contact forms may also run separately.

For business independence, I recommend having the appropriate person or company recorded as the domain registrant and keeping the provider account under your control. The developer can have separate technical access. Check billing details, payment and account permissions separately: an invoice alone does not establish the full extent of your control.

These are practical organisational and technical checks. Agree the scope of code delivery, licences and rights to materials in the contract. Dashboard access does not replace those agreements.

How to check the domain registrant and registrar access

The registrant of a .pl domain is the party to the domain maintenance agreement. The registrar handles the domain and processes requests. Check the registrant details in the registrar dashboard or ask the registrar to confirm them. Distinguish them from the technical contact and billing details.

NASK WHOIS helps check the status, registrar and registry information for a .pl domain. Publicly visible details depend on the registrant. NASK does not publish individual registrants’ personal details, so a missing name for a sole trader’s domain does not prove incorrect registration. The public result does not replace checking your own account.

Log in to the registrar account yourself and check that the correct domain is listed.
Confirm registrant details, the renewal date, the next renewal price and how reminders are sent.
Check the email address used for account recovery and change confirmations. It should remain under your control.
Establish how to obtain the AuthInfo code and what permissions the developer has.

Keep a recovery route that does not rely solely on email hosted on your own domain. An outage could affect both the website and the messages needed to recover access.

Domain transfer, registrant changes and DNS

Transferring the management of a .pl domain means changing the registrar. Changing the registrant is a separate operation. If your business is already the registrant but the domain is held in the developer’s shared account, first ask the registrar how to move its management into your account. Do not automatically assume the registrant must change.

The AuthInfo code authorises a transfer to another registrar. NASK describes how to obtain it and confirm a transfer. Registrars may use different code-issuance procedures; the absence of an instant download button does not itself mean a violation. Check the official instructions and identity verification requirements.

NASK states that a registrar must issue AuthInfo promptly at the registrant’s request and cannot make issuance conditional on additional requirements, including a fee. If the registrar refuses to issue the code, check NASK’s complaints procedure.

DNS connects the domain name with services, including the website and email. Changing the registrar, DNS servers and hosting need not be one operation. Before any change, save the records and agree a plan with the administrator, especially if email or DNSSEC is in use. Do not change settings merely to test access.

DNSSEC allows verification of the authenticity and integrity of DNS responses. It does not encrypt queries or protect them from being observed. It does not replace HTTPS or account security. Enabling or moving DNSSEC requires coordinated configuration at the DNS provider and registrar.

What to collect for your website platform

Self-hosted WordPress

Check the hosting customer account, WordPress administrator account, file access and backups. Establish who manages the database, updates, certificate and email. SFTP or SSH is useful for administration where the hosting plan provides it. A business owner need not do this work personally, but should be able to appoint an administrator and revoke the previous one’s access.

A complete backup of a typical WordPress site includes both files and the database. Exporting posts or downloading the images directory alone is not enough for a full restoration. Also check paid theme and plugin licences and whether they work independently of the developer’s account.

Static website or application

Collect the agreed source files or repository, deployment account and publishing instructions. A simple static website may have no database, CMS dashboard or FTP account. If it uses an external form, calendar or database, document and back up those services separately.

Online website builders such as Wix

For a website builder, the key is control over the site owner account, subscription, domain and collaborator roles. Not every platform lets you download the code or database, or move a working site to arbitrary hosting. Wix states that a site built with its technology must run on Wix servers. The domain can be managed by another provider. Establish export restrictions before handover.

Accounts and information to collect

Work through this table with the developer. Mark services the site does not use as “not applicable”. Keep secrets in a password manager; in the handover document, record only where to find them and who has access.

Service	What to check	What to retain
Domain and DNS	Registrant, registrar account, DNS permissions and renewals.	Registrar, dates, recovery contact, AuthInfo procedure and record copy.
Hosting or builder	Owner or customer account, subscription, payments and roles.	Plan name, renewals, support contact and export restrictions.
CMS and code	Administrator access, repository or agreed export, and licences.	Update and deployment instructions, plus a dependency list.
Business email	Administrator dashboard, renewals, mailbox access and recovery.	Provider and DNS configuration needed for email.
Forms and booking	Accounts, enquiry recipients, calendars, notifications and integrations.	Configuration, operating instructions and data access rules.
Analytics and search	Appropriate Analytics roles and verified Search Console access, where used.	Service identifiers and the list of people with access.
Backups	Scope, schedule, storage location and a test restoration.	Restore instructions and the agreed recovery time.

How to organise passwords and developer access

Use individual accounts for collaborators and grant the permissions their tasks require. Enable 2FA or other available strong authentication for the registrar, hosting, email and CMS dashboards. Keep recovery codes somewhere safe. 2FA alone does not guarantee security.

Change passwords that were shared or supplied as temporary credentials. First establish where the application uses them. Changing a database or SMTP password, or an API key, without updating the configuration can break the website, email or booking service. Coordinate such changes with the administrator, save the settings and test the service afterwards.

Do not revoke every permission indiscriminately. Establish whether the developer still maintains the website. Revoke redundant accounts and keys; limit and document access that remains necessary. Also review active sessions and account recovery methods.

Backups and a restoration test

Establish what the backup includes: code, content, files, the database and service settings that can be exported. The scope depends on the technology. A website backup may not include email, form submissions or an external calendar. Check those separately.

Keep an independent copy outside the primary hosting service, accessible only to authorised people. Choose the frequency and retention period according to how often the site changes and how much data you can afford to lose. Ask for a test restoration in an isolated environment, with real outgoing messages disabled and no payments being triggered.

At handover, test the website and HTTPS, contact form and booking service. The public site should have the agreed indexing settings. Protect the test environment against unauthorised access; robots.txt and noindex do not secure data. Do not delete files or database tables simply because they look technical.

A short website handover checklist

I have confirmed the correct domain registrant and can log in to my registrar account.
I know renewal dates and costs and receive reminders at an address I control.
I can access the hosting or builder account and manage collaborator roles.
I have received the agreed source files or export and understand platform and licence restrictions.
I have checked the form, calendar, email and additional services used by the site.
I have an agreed backup scope and the result of a test restoration.
I have organised passwords, account recovery, 2FA and any necessary developer access.
I know who handles updates, outages and ongoing maintenance.

A properly handed-over site lets you choose who maintains it without depending on the previous developer’s personal account. It does not mean you must administer a server yourself. What matters is understanding the services you have, who manages them and how to recover access.

For my projects, the client sets up the domain, hosting and accounts in their own name, while I advise and configure them. If you are preparing a new website or want to clarify the scope of work, describe your situation through the contact page.

Sources and verification date

Technical content checked on 14 November 2026. Domain information primarily concerns .pl; for other extensions, check the relevant registry and registrar rules. This article was prepared with AI assistance and edited. It does not describe an audit performed on a specific website.