Website Handover Checklist Between Agencies

August 8, 2026 · 7 min read

A safe website handover transfers operational knowledge and control without creating an unmonitored gap. The client, outgoing agency, and incoming agency should agree on scope, a UTC cutover time, account ownership, code and data state, critical journeys, open incidents, recovery evidence, monitoring overlap, acceptance criteria, and final access revocation.

Do not reduce the handover to a password archive. The receiving team needs enough verified context to operate and recover the service, while the departing team needs a clear end of responsibility.

At a glance

1. Appoint one client handover owner.
2. Create a shared transfer register and timeline.
3. Freeze or coordinate high-risk changes.
4. Confirm ownership for every account and dependency.
5. Transfer code, documentation, licences, data, and runbooks.
6. Validate backups and critical journeys.
7. overlap monitoring and incident contacts.
8. record known defects, debt, and accepted risk.
9. sign operational acceptance at a precise time.
10. revoke outgoing access and rotate exposed shared secrets.
11. verify that billing, alerts, and vendor contacts follow the new owner.

Roles

Party	Primary responsibility
Client owner	authority, ownership decisions, risk acceptance, final acceptance
Outgoing agency	accurate records, current state, controlled transfer, access inventory
Incoming agency	validation, new monitoring, recovery readiness, acceptance exceptions
Vendors	account transfer and support under their procedures

The client should not force the two agencies to resolve contractual disputes inside an incident channel. Keep commercial disagreements separate from continuity tasks.

Phase 1: agree the transfer plan

Record:

• websites and environments in scope;
• outgoing responsibility end and incoming responsibility start in UTC;
• change-freeze or change-coordination period;
• routine and emergency contacts;
• handover channel and system of record;
• security/privacy restrictions;
• acceptance criteria;
• unresolved commercial or legal items handled elsewhere;
• fallback if transfer cannot complete.

Avoid responsibility that changes “at the end of the day.” Time zones and daylight-saving transitions make that ambiguous.

Phase 2: build the transfer register

# Website handover register

Client: [organisation]
Service: [name/URLs]
Cutover: [UTC]
Client owner: [role]
Outgoing owner: [role]
Incoming owner: [role]

| Item | Current owner | Target owner/access | Evidence | Status | Exception |
|---|---|---|---|---|---|
| Domain | [value] | [value] | [link] | Open | [value] |
| DNS/CDN | [value] | [value] | [link] | Open | |
| Hosting/cloud | [value] | [value] | [link] | Open | |
| Repository | [value] | [value] | [link] | Open | |
| Backups | [value] | [value] | [link] | Open | |
| Monitoring | [value] | [value] | [link] | Open | |

Acceptance criteria:
- [ ] Critical journeys pass.
- [ ] Incoming incident route receives a test.
- [ ] Recovery status and limitations are accepted.
- [ ] Open risks have owner and due date.
- [ ] Outgoing access revocation plan is approved.

Phase 3: transfer ownership and access

Cover:

• registrar, domain, DNS, CDN/WAF, hosting/cloud;
• CMS and privileged user accounts;
• repository, CI/CD, package registries, deployment keys;
• database, object storage, backups, logs;
• email/SMS, identity, payment, tax, shipping;
• CRM, ERP, PIM, OMS and integration middleware;
• analytics, tag manager, consent platform, search consoles;
• monitoring, status page, help desk, alert channels;
• licences, subscriptions, renewal contacts, and billing.

Prefer adding named incoming accounts, verifying them, and then removing outgoing accounts. Do not send a single spreadsheet of passwords by email.

Phase 4: transfer technical state

Code and deployment

• authoritative repositories and branches;
• unmerged or unreleased changes;
• build and deployment process;
• environment differences;
• database migrations and rollback constraints;
• feature flags and temporary configuration;
• third-party and open-source licence obligations;
• release history and last known good version.

Infrastructure and data

• current architecture and shared dependencies;
• capacity and scaling constraints;
• scheduled jobs, queues, caches, search, and storage;
• logging and retention;
• backup scope, encryption, retention, RTO/RPO;
• last restore-test evidence;
• data residency or handling requirements supplied by the client.

Application and operations

• CMS/framework/runtime versions;
• unsupported components and known vulnerabilities;
• critical user journeys and test data;
• monitoring checks, thresholds, maintenance windows, and exceptions;
• incident and provider escalation runbooks;
• recurring maintenance schedule;
• open incidents, problems, and postmortem actions.

Known issues and accepted risks

Risk	Existing before transfer?	Impact	Current control	Owner after cutover	Decision/due
Domain in personal account	Yes	continuity	manual reminder	Client	transfer by date
Restore test failed RTO	Yes	recovery delay	backup available	Incoming agency	improve/accept
Unsupported plugin	Yes	change/security	WAF + limited change	Shared	replace by date

Both parties should avoid rewriting history. The purpose is to make current risk visible.

Monitoring overlap

For material sites:

1. incoming agency creates and tests its checks before cutover;
2. outgoing monitoring remains active through an agreed overlap;
3. both sides know which team acts during overlap;
4. one test alert confirms the incoming route;
5. checks are compared for obvious gaps;
6. outgoing checks are removed only after acceptance;
7. client-facing status and escalation contacts are updated.

Two alert systems without one response owner create confusion, not redundancy.

Cutover validation

• canonical URL, DNS, TLS, and representative regions;
• critical pages and business journeys;
• email/CRM/order/integration destination state;
• scheduled jobs and queue health;
• new deployment and rollback access;
• backup retrieval and accepted restore evidence;
• help-desk, monitoring, and fallback notifications;
• authorised client contact can reach the new emergency route.

Acceptance record

Service: [value]
Operational responsibility transferred: [UTC]

Accepted:
- Scope/version: [reference]
- Inventory/passport: [reference]
- Access matrix: [reference]
- Known risks: [reference]
- Recovery status: [reference]
- Monitoring and escalation: [reference]

Exceptions:
- [condition, owner, decision, due date]

Outgoing agency confirms no further operational authority after [UTC],
except [explicit transition obligation].

Accepted by client: [role/date]
Accepted by incoming agency: [role/date]
Acknowledged by outgoing agency: [role/date]

Offboarding the outgoing agency

• disable named accounts and sessions;
• revoke personal access tokens, SSH keys, app passwords, and OAuth grants;
• rotate shared secrets the team could retrieve;
• update recovery email, phone, and MFA methods;
• transfer automation ownership;
• remove private monitoring and alert destinations;
• export required evidence under contract/policy;
• remove client data from agency devices and systems according to approved retention;
• confirm vendor billing and renewal contacts;
• record completion.

Do not delete evidence required for security, contract, tax, or dispute purposes without authorised review.

Example: a seamless-looking but incomplete transfer

The new agency receives WordPress, hosting, and repository access. Two weeks later checkout emails stop because the mail account and DNS records remained controlled by the previous provider. The handover appeared complete because the homepage and deployment worked.

A dependency-based register would have exposed transactional email, DNS ownership, monitoring, and the destination mailbox as separate transfer items.

Common mistakes

• transferring passwords but not account ownership;
• no exact cutover time;
• both agencies assuming the other handles incidents;
• cancelling outgoing monitoring before incoming alerts are tested;
• omitting open changes and temporary feature flags;
• hiding known defects to make the transfer look clean;
• rotating a shared secret without mapping downstream consumers;
• deleting accounts before transferring repositories or automation;
• accepting the site without testing business journeys.

FAQ

How long should monitoring overlap?

Choose based on service criticality and operational validation. It may be hours for a simple site or several days for transactional systems; define one response owner throughout.

Must the previous agency provide source code?

That depends on contracts, licences, and ownership. The operational checklist cannot decide legal entitlement; escalate missing assets early.

What if the incoming agency refuses the current risks?

Record exceptions and let authorised parties choose remediation, scope limitation, delayed cutover, or another arrangement.

Who should rotate credentials?

The target account owner or authorised administrator, coordinated so dependencies are not broken and use is logged.

Sources and further reading

• OWASP Secrets Management Cheat Sheet
• NIST SP 800-61 Rev. 3

Reviewed: 8 August 2026.

Next: Monitoring as code for web agencies, maintenance onboarding, and access control matrix.

Pingvera can be configured before cutover so the incoming agency validates external checks and alert routes while outgoing monitoring remains active.

Read next: Web Agency Access Control Matrix Template · Monitoring as Code for Web Agencies.