Taking Over a Website from Another UK Development Agency

A real takeover where server access was not enough

In September 2026, Appycodes took over maintenance work on an established enterprise WordPress site. The initial access request correctly covered WordPress, hosting, SSH, database, repository, registrar, DNS, SSL, CDN, object storage and email. That list was useful, but the project soon exposed why a checklist alone is weak evidence.

The team gained database access and working SSH access to the website files. A staging environment could be created. Yet the invitation route for the shared operational account had problems, the relevant Cloudflare zone or permission was not usable, and the team could not add the DNS records needed for the intended staging domain and TLS path. The practical blocker sat at the edge control plane, not on the server.

The difficult decision was to avoid treating broad infrastructure access as permission to improvise on production. Appycodes explicitly directed that work stay off the live site, created staging separately, asked for the specific DNS permission that was missing and required snapshots/evidence around changes. The project then had to distinguish a DNS record supplied by the client from the staging environment Appycodes had already prepared; those were related artefacts, not the same thing.

The lesson is precise: access is local; control is end to end. A developer who can edit PHP but cannot verify the domain, change DNS, inspect the deployment path or restore the data cannot responsibly own the release. Conversely, requesting “all passwords” creates unnecessary risk. The receiving team needs the narrow role that proves each required operation.

The Appycodes Takeover Control Score

Score five gates from 0 to 3: 0 absent, 1 claimed, 2 demonstrated in a non-production environment, 3 proven with retained evidence. The maximum is 15. Authority and Recovery are hard gates: either at zero means no production changes, whatever the total.

This is deliberately stricter than “we can log in”. GitHub notes that a repository transfer keeps webhooks, secrets and deploy keys attached, and retains the original owner as a collaborator; a transfer therefore starts an access review rather than completing one. GitHub: transferring a repository

Inventory control planes, not just accounts

For a .uk domain, confirm who the registrant is rather than assuming the agency or registrar dashboard proves ownership. Nominet says registrants can use its Online Services to update contact details, change registrar or transfer the domain, using the registration email address. Nominet: managing a .uk domain

Use named roles instead of shared super-admin access. Cloudflare provides domain-scoped roles including Domain DNS; its guidance says configuring each member’s permissions helps prevent accidental account changes. That is enough for many staging and cutover tasks without handing a new supplier billing and account-member powers. Cloudflare: account and domain roles

A takeover should move from observation to revocation

1. Freeze the baseline

Record the current DNS zone, response headers, certificates, redirects, robots rules, sitemap, canonical tags, top landing pages, forms, payment path, scheduled jobs, integrations and uptime checks. Capture repository HEAD, plugin/package versions and environment shape. Do not “tidy” while discovering: a strange rule may be carrying revenue or mail.

2. Establish business authority

Move primary ownership and recovery to business-controlled identities. Invite the incoming agency with least privilege. Record which party is controller, processor or sub-processor for personal data. The ICO states that whenever a controller uses a processor, a written contract must bind the processor and clarify the relationship. The contract should reflect what the service actually does, including end-of-service handling. ICO: controller–processor contracts

3. Rebuild and restore in isolation

Clone the source into a clean environment. Retrieve secrets by reference, not from a copied document. Build without the outgoing developer’s laptop or personal registry. Restore the database and user-uploaded files into a protected destination; then test application login, representative content, search, forms and scheduled work. WordPress distinguishes database data from files such as themes, plugins, uploads and wp-config.php; a database export alone is not a full restore. WordPress: backing up the database

4. Prove release and rollback

Deploy one reversible change to staging through the intended pipeline. Verify the exact commit, configuration source, health checks and log access. Define the production change window, decision maker, DNS TTL plan, cache handling, form/payment tests, monitoring and numerical rollback trigger. Never make “we can deploy” and “we can restore data” one untested operation.

5. Accept, rotate and revoke

After business acceptance, rotate secrets that crossed the supplier boundary, remove unused users, deploy keys, API tokens and verification artefacts, and record what remains. NCSC supply-chain guidance says contract closure should regain control of assets and shut down unauthorised or unintended access. NCSC: assess supply-chain cyber security

Make the handover machine-readable—without storing secrets

A manifest turns a static checklist into an acceptance record. Keep owner identifiers, artefact paths, dates and secret references in version control; keep secret values in a client-owned vault. A CI check can reject release while restore_tested_at, the accepted commit or outgoing-access review is empty.

# handover.yml — references only; never put secret values here
service: corporate-wordpress
business_owner: digital@client.example
accepted_at: null

control_planes:
  domain:
    registrant_verified: true
    registrar_owner: client-business
    renewal_tested: true
  dns:
    provider: cloudflare
    client_super_admins: 2
    agency_role: domain-dns
    zone_export: evidence/dns-zone-2026-09-30.txt
  source:
    repository: client-org/corporate-site
    protected_default_branch: true
    release_commit: null
  runtime:
    hosting_owner: client-business
    deployment: pipeline
    staging_url: https://staging.example.co.uk
  recovery:
    database_backup: evidence/db-backup.sha256
    files_backup: evidence/files-backup.sha256
    restore_tested_at: null
    rollback_command: runbook://website/rollback
  search:
    search_console_owner: digital@client.example
    analytics_owner: digital@client.example

integrations:
  - name: transactional-email
    owner: operations@client.example
    secret_ref: vault://prod/website/smtp
    rotation_status: pending

exit:
  outgoing_access_reviewed: false
  old_tokens_removed: false
  evidence_pack: evidence/handover-index.md

Hash exported artefacts so the parties can show which zone file, database backup or build was accepted. Do not put personal data, live credentials, private keys or full production configuration into the evidence pack. Evidence should prove a control without becoming another sensitive system.

Security and data work continue after the cutover

Changing agencies changes the supplier boundary. Review production accounts, SSH keys, CMS users, database users, deploy keys, OAuth apps, package-registry tokens, webhook secrets, SMTP credentials, analytics owners and support accounts. Remove access by identity and purpose, not by guessing which shared password was used. Require MFA for privileged cloud access and keep an emergency route owned by the business.

Do not remove a Google Search Console user and assume access is gone. Google explains that a verified owner may regain access while its verification token remains in DNS, HTML, Analytics or Tag Manager; removing tokens must be done carefully because the same token can support other services. Google: owners, users and verification tokens

Ask the outgoing supplier to return or delete personal data in line with the contract, but distinguish their service copy from records the client must retain. Confirm logs, backups, ticket attachments, database exports and local development datasets—not only the live database. This section is operational guidance, not legal advice.

Protect search visibility during the handover

An agency change does not require a redesign, framework migration or domain move. Keep the first cutover boring. Baseline the top organic landing pages, status codes, canonical URLs, robots directives, XML sitemaps, structured data, hreflang, Core Web Vitals and conversion events. Crawl staging behind authentication or IP controls, but make sure those controls and any noindex directive cannot leak into production.

Verify a business-controlled Search Console owner before removing the outgoing supplier. Google recommends multiple verification methods and notes that ownership lasts only while the relevant token remains valid. For domain properties, DNS control is required, which is another reason DNS belongs inside the operational acceptance gate rather than an administrative appendix. Google: verify site ownership

For the first production release, compare a fixed URL set before and after: homepage, top landing pages, a form, a search result, representative media, robots.txt and sitemap. Track new 4xx/5xx responses, canonical changes and analytics continuity. Defer URL restructuring until the team has a stable baseline and a separately reviewed redirect map.

Recommendations for UK businesses changing agency

After real takeovers, Appycodes recommends a two-contract mindset even if procurement uses one document: the commercial agreement defines rights and obligations; the technical acceptance record proves that the current service can actually be operated and exited. Our UK software rescue and security service covers inherited-code audits, access recovery, staging, deployment, security remediation and controlled handover.

Primary sources

• NCSC: Assess supply-chain cyber security
• ICO: when controller–processor contracts are needed
• Nominet: manage and transfer .uk domains
• Cloudflare: member roles and domain-scoped permissions
• GitHub: transferring a repository
• Google Search Console: owners, users and verification tokens
• WordPress: database and full-site backup boundaries

Technical and operational guidance, not legal, data-protection, contractual or security advice. Ownership, intellectual property, termination and regulatory duties depend on the relevant agreements and facts; obtain qualified advice where needed.