Domain, hosting, code and assets — what should the client control after launch?

Administrator access does not always equal ownership, and paying an invoice does not automatically transfer every copyright. A company may control its hosting account while using software under licence. It may own rights to a bespoke interface without owning the open-source framework, a commercial font or a stock image underneath it.

A professional handover lists every class of asset separately: domain, infrastructure, code, design, content, media, data, third-party accounts and licences. Both parties can then see what the client receives, what it may modify and which elements remain subject to a vendor's terms.

The safest pattern is to register the domain with the client's legal details, an organisation-controlled email and its own payment method. For .pl names, NASK describes the subscriber's rights around registrar changes and the authinfo code. For global domains, accurate registrant information and access to the registrar account remain equally important.

A supplier may receive technical DNS access, but it should not be the only party able to renew or transfer the name. Automatic renewal, multi-factor authentication and at least two organisational recovery contacts reduce avoidable risk.

In the first model, the client owns the cloud, server or platform account and grants AERIX working access. In the second, AERIX provides managed hosting and assumes responsibility for the operational elements listed in the service scope.

Managed hosting is not a loss of control when the proposal defines fees, backups, updates, monitoring, support, any SLA, notice period and migration route. The client should know from day one what it receives at termination and how quickly the service can be moved.

A repository provides change history and supports future development, so a client should receive agreed access or a transfer after the project is settled. GitHub supports formal repository transfers with history and project data, although integrations and deployment secrets usually require separate configuration.

Rights in bespoke code should follow the signed agreement and commonly transfer only after full payment. Open-source libraries, vendor components and SaaS products keep their own licences: a supplier cannot transfer rights it never owned.

Bespoke layouts, copy and commissioned assets may be assigned or licensed under the project agreement. Client-supplied photography remains the client's, while stock, fonts, icons or music may restrict domains, advertising use or onward transfer.

The handover should include a dependency and licence register: asset name, source, account owner, usage scope and renewal date. This prevents a future team from discovering that nobody knows whether the hero image remains licensed or where the typeface was purchased.

Customer records, enquiries, CMS content, analytics, Search Console, map profiles and advertising accounts are business assets. They should normally be created inside the client's organisation, with the supplier invited under the least privileged suitable role.

Changing partner then preserves measurement history and access. The client removes the outgoing supplier rather than recovering an account tied to somebody's private inbox.

A complete package covers the registrar and DNS, hosting, repository and runbook, environment values delivered through a secure channel, a data export, CMS, analytics, Search Console, integrations, licences and the access list. Passwords should not live in an ordinary document or email.

Record runtime versions, backup and restoration procedures, vendor contacts and renewal dates as well. This operational map allows another qualified team to assume responsibility without digital archaeology.

A client may deliberately choose managed hosting for years and still remain independent. It needs a defined export procedure, delivery times for data and code, settlement rules and the scope of any paid migration assistance.

AERIX supports both patterns: client-owned infrastructure or managed care. We build retention through service quality, documentation and predictable rules agreed before production — not through technical captivity.