What needs to be handed over when you change website agencies?

Start with an asset inventory

List the domain, hosting, CMS, source repository, design files, media library, analytics tools and external services in one table. For each, record the account owner, business contact, current access, renewal date and acceptance evidence. Label unknown information as unverified instead of leaving an ambiguous blank.

In an illustrative manufacturing website, the enquiry form may use one service, the catalogue another storage system, and business email a separate panel. Having the homepage on a server does not demonstrate that all three journeys have been handed over. Begin with the visible website and follow each important customer task to its dependencies.

Make domain and renewal responsibility explicit

ICANN’s information for registrants highlights keeping contact details current and understanding the registrar’s renewal and transfer processes. Verify which registrar the business uses and who actually receives its notices. ICANN source.

Changing agencies does not automatically require a domain transfer or DNS change. Establish ownership, permissions and service dependencies first. Record who pays for renewal and who takes responsibility if that person leaves. Country-code domains and providers can have different procedures, so do not apply one generic process to every account.

Hand over appropriate access, not a shared password sheet

Where supported, invite accounts controlled by the business using appropriate roles. Give the incoming team the access needed for its work without unnecessarily expanding billing or ownership permissions. Confirm that the business’s own authorised access works before removing the only existing administrator.

• Record which account was tested without recording its password.
• Assign responsibility for recovery and multifactor authentication.
• Do not treat an outgoing agency’s personal account as a transferable asset.
• Agree when previous access will be removed and who will do it.

None of this requires collecting secrets in an email attachment. The handover document should contain verified access status and permission scope, with credentials handled through the organisation’s approved secure process.

Test whether the files are usable

An archive is not a usable source handover merely because it opens. Ask the developer to distinguish source files from compiled output. Document setup instructions, required versions and environment-variable names; do not place secret keys in the source repository. If the website depends on a hosted platform, explain its portability limits separately.

Photography, fonts, plugins and templates need their own licence checks. Possessing a file does not mean that its licence transfers automatically. Identify the agreement or subscription required for continued use. Evaluate backup usability through a controlled restore rehearsal, rather than assuming that a downloaded archive can restore the service.

Choose observable acceptance tasks

Example checks could require the new team to edit a draft, update the correct technical download and confirm that a test enquiry reaches the agreed inbox. Plan any production-changing test in advance so genuine customers do not receive test notifications. Record an owner and next step for every incomplete task.

The acceptance record should state which access worked, which files were opened and what remains outstanding. If a redesign is also planned, scope it separately from access handover. Our website design service can help clarify the existing system, handover requirements and renewal work before the transition becomes a guessing exercise.