Taking over an existing website

Taking responsibility for an existing website starts with understanding how it is operated. The administrator login may provide access to the content while leaving hosting, domain renewals, deployment and external services undocumented.

The first task is to establish ownership and a reliable recovery path. Those details determine how safely later changes can be made and who can act when something stops working.

Build an access and ownership list

Record the service, account owner, renewal date and recovery contact for each important dependency. Include:

• Domain registration, DNS and hosting.
• The content management system and administrator accounts.
• Source repository and deployment process, if present.
• Transactional email, forms and external integrations.
• Analytics, search tools and monitoring.
• Paid themes, extensions and other recurring licences.

Use individual accounts with appropriate permissions where the service supports them. Confirm that recovery belongs to the business. A domain or critical subscription tied only to a former supplier’s personal account needs a planned ownership transfer.

Keep credentials in a suitable password manager rather than adding them to the handover document. The document should explain where authorised people can obtain access.

Verify that recovery is possible

Locate the backups and establish what they contain, how often they run and who can restore them. Downloading a WordPress site’s directory does not normally include its database. WordPress explains the distinction in its backup documentation.

Test a restore in an isolated environment where practical. Check that the restored site includes recent content, uploads and the custom functionality needed to operate it.

For an active store, discuss how much recent order data could be lost and how it would be recovered. A backup taken several days ago may be sufficient for a rarely edited brochure site and inadequate for a busy checkout.

Identify custom behaviour

List installed themes and extensions, but also inspect custom plugins, child-theme changes, code snippets and scheduled jobs. Ask which features staff depend on and which workarounds they use.

A shipping restriction might live in a small snippet rather than a named shipping extension. A nightly product import could run outside WordPress entirely. Record the location, purpose and dependencies of each custom process.

Compare the available source code with the running website. If deployment changes have not been recorded in the repository, preserve and reconcile them before treating the repository as the complete source.

Establish a baseline before updates

Check important journeys: contact submission, account access, search, purchases or another function appropriate to the site. Record existing failures separately from planned improvements.

Review versions, abandoned dependencies and access permissions. WordPress’s security guidance emphasises maintaining core, themes and plugins. Compatibility and custom behaviour still need checking when planning the update sequence.

Agree the ongoing responsibility

Finish the handover with named owners for renewals, backups, monitoring, content and technical changes. Define how faults are reported and which issues require immediate attention.

The first maintenance plan should distinguish urgent repairs, routine updates and larger improvements, with enough explanation for the business to prioritise the next steps.