A planned website takeover should be treated like an operational handover, not a password exchange. The new team needs enough access and knowledge to keep the site running, recover it when necessary and make changes without guessing.

The safest sequence is inventory, transfer, preserve, verify, stabilise and then improve.

1. Build the ownership register

Record the provider, account owner, billing owner, renewal date and access status for:

  • domain registration and DNS;
  • hosting, cloud and CDN;
  • CMS administration;
  • source-code repositories;
  • deployment platforms and pipelines;
  • databases, file storage and backups;
  • analytics and search tools;
  • form email, SMTP and transactional email;
  • payment, CRM, maps and other integrations;
  • themes, plugins, modules, fonts and software licences.

Where possible, accounts should belong to the organisation rather than a vendor employee.

2. Use individual access

Invite named users through the provider instead of sharing a single administrator password. Grant only the access needed, enable multi-factor authentication where available and record who can approve higher-risk actions.

Do not remove the outgoing provider until the new team has verified its own access and the organisation has confirmed the handover is complete.

3. Collect the technical record

Ask for:

  • architecture and hosting notes;
  • local, staging and production environments;
  • repository and branch workflow;
  • deployment and rollback steps;
  • database migrations and scheduled jobs;
  • third-party API details and webhook flows;
  • custom code and known technical debt;
  • critical customer journeys;
  • open defects and planned work;
  • incident and maintenance history.

Missing documentation is common. Mark it as a gap rather than pretending the knowledge exists.

4. Preserve a known baseline

Before the first broad update or configuration change:

  1. Verify a complete backup or snapshot.
  2. Confirm how restoration would work.
  3. Record current versions and dependencies.
  4. Export or preserve relevant configuration.
  5. Tag or record the current production code state.
  6. Capture the current behaviour of important journeys.

This baseline gives the new team something concrete to compare and, where possible, recover.

5. Test the business-critical journeys

Do not limit takeover testing to “the home page loads.” Check the actions the organisation depends on:

  • enquiry forms and internal notifications;
  • checkout and payment confirmation;
  • registration, login and password reset;
  • search, filters and downloads;
  • editorial publishing;
  • CRM, email and external API flows;
  • analytics and consent behaviour;
  • scheduled imports, exports and background jobs.

Record the expected result and who confirms it.

6. Review support lifecycle and risk

Identify the CMS or framework version, hosting runtime and important packages. Compare them with official support policies. For example, Laravel defines bug-fix and security-fix windows for framework releases, while Drupal Security Team coverage applies to supported Drupal versions.

Review abandoned extensions, expired licences, custom code and accounts belonging to former staff. These may become stabilisation tasks before routine maintenance.

7. Rotate access deliberately

After the handover is verified, remove accounts that are no longer authorised and rotate shared secrets that cannot be replaced with individual access. Coordinate changes to API keys, webhook secrets and deployment tokens so working integrations are not broken unexpectedly.

Never publish secrets in tickets, chat transcripts or repository history.

8. Agree on the new operating rhythm

Document:

  • who owns business priorities;
  • who owns technical maintenance;
  • how routine and urgent requests are sent;
  • which checks occur weekly, monthly and quarterly;
  • what evidence or reporting is provided;
  • who coordinates hosting and third-party incidents;
  • what needs separate approval or quotation.

The handover is complete when continuity is real

A takeover is not complete because the new provider has logged in once. It is complete when the organisation controls the key assets, the new team can deploy and recover safely, critical journeys have been checked, known gaps are documented and everyone understands what happens next.

Sources