Taking over an unfamiliar website starts with bounded transition discovery, not an open-ended promise to fix everything. Before updating extensions or changing hosting, establish account ownership, authorized access, recoverability and external dependencies. The intended outcome is a responsibility and risk map that supports a realistic maintenance scope.
A site can appear healthy while its domain account belongs to a former employee, its theme licence belongs to the previous agency, or its backup excludes the database. A homepage inspection will not reveal those issues. Distinguish verified facts, statements supplied by others and unresolved unknowns.
Start with an asset register, not a password document
Record each service, business owner, administrative access holder, access-transfer method, renewal date and billing destination. Transfer secrets through an approved secure channel and use individual accounts where supported.
| Asset | Question before accepting responsibility |
|---|---|
| Domain and DNS | Does the business control the account and authorize changes? |
| Hosting | Who can back up, restore and contact support? |
| CMS | Who administers it and which accounts remain active? |
| Theme and extensions | Can licences be transferred and renewed? |
| Email and forms | Which delivery services, destinations and owners are involved? |
| Measurement and integrations | What external dependencies exist and who approves changes? |
If access is missing, use the provider's official recovery process with the owner's evidence. Do not bypass a former supplier's account or use credentials obtained without authorization. Some steps may need to be completed by the business owner rather than delegated to maintenance staff.
An available backup is not demonstrated recovery
Identify the backup's contents, date, location and authorized recovery operator. WordPress documentation distinguishes files from the database and explains that a typical full restore requires both. WordPress backup guidance. Downloading an image folder is not a complete site backup.
Where appropriate, demonstrate restoration in an isolated environment, preventing the test copy from sending real email or triggering live integrations. Check pages, downloads and forms afterwards. Record actual effort and dependencies without turning a limited exercise into a guaranteed recovery time for every incident.
CMS Development can clarify the content structure and maintainable dependencies. Keep current defects in a separate register so they are not confused with responsibility for newly introduced changes.
Hypothetical example: a working site with incomplete handover
Imagine a company moving away from its previous supplier. This is an illustration, not a LAB client story. CMS administration is available, but the domain remains in a former manager's account, the theme uses an agency licence and no restore test has been documented.
The team records three different actions: legitimate domain access or ownership transfer, confirmation of licence rights or an owner-approved replacement licence, and a backup-restoration test. It does not launch a bulk update merely because the admin screen opens. Nor does it label every item a software defect: some are administrative dependencies that must be resolved first.
Restoring a test copy reveals that the enquiry form depends on a separate email service omitted from handover. That service and its owner are added to the register, and the delivery path is tested. Transition discovery exposes dependencies before the first production outage makes them urgent.
A useful transition report also states what could not be inspected and why. “No DNS access supplied” is materially different from “DNS configuration reviewed and accepted.” That distinction should remain visible when the ongoing maintenance agreement is prepared.
Separate transition, remediation and operation
Transition covers authorized access, asset inventory, architecture discovery, backup checks and unknowns. It has defined deliverables even if a blocker prevents complete takeover.
Initial remediation addresses known, approved issues such as a broken form or unsupported extension through Website Repair and Improvement. A complete redesign should not be concealed inside an undefined maintenance line.
Ongoing operation describes recurring tasks and agreed coverage: who receives reports, who authorizes changes and what happens outside normal hours. Response times, after-hours work and emergency responsibilities need explicit agreement. Do not assume continuous monitoring or round-the-clock response.
A bounded risk review and selected fixes may fit Performance and Security Hardening. If signs of compromise appear, the problem needs an appropriately authorized specialist route rather than being treated as ordinary maintenance.
What demonstrates a completed takeover?
The new team should be able to perform an ordinary administrative task, understand how to reverse it and reach the relevant support provider without depending on an account belonging to someone who left. Quality Assurance checks agreed journeys and documents existing and newly discovered defects.
State exclusions clearly: domain administration remains unavailable, or a booking integration has not been assessed. An exception does not disappear when billing begins. Give each unresolved item an owner, a next action and an explanation of how it limits commitments.
Transition acceptance checklist
- Owner authorization and appropriate accounts are documented.
- Assets, renewals and licences are recorded within scope.
- Backup contents and recoverability have stated evidence.
- Critical functions are tested or the reason testing was blocked is recorded.
- Former-supplier access is addressed without indiscriminate service disruption.
- Maintenance coverage, emergencies and exclusions are approved.
Frequently asked questions
Should we immediately rotate every password?
Coordinate changes with system owners so integrations and service accounts do not fail. Remove unnecessary access, but avoid an unplanned bulk credential change.
Does supplier-owned hosting prevent takeover?
It may require migration, contractual arrangements or documented access. Login capability does not by itself establish ownership, and account rights must not be bypassed.
Does maintenance include all content changes?
Only if the scope says so. Define types, quantities and approvals rather than relying on the word “maintenance.”
What if no reliable backup exists?
Document that risk before changes and assess legitimate backup and verification options with the responsible specialist. Do not claim an unproven rollback capability.
Prepare a reviewable transition
Give LAB the known service and account names and a description of faults, without embedding secrets. Commission a bounded takeover assessment first, then approve repairs and maintenance on the evidence it establishes.
Sources
- WordPress: backups and site components, reviewed 26 October 2026; used for the files/database distinction.
