Before your current website developer steps away, collect a clear handover of account control, website files, content, connected services and operating instructions. Make sure your business can sign in and recover each key account, then test the handover while the current developer can still answer questions. A list of passwords alone is not enough to keep a site maintainable.

Start with the accounts that control the site

Ask the developer to identify each account, who owns it, who can sign in, how recovery works and which renewal date or payment method is attached. Your business should have an authorized administrator using a company-controlled email address and recovery method. Use a password manager and individual user access where available; do not keep a shared password in a public document or send a bundle of secrets by ordinary email.

  • Domain registrar: registrar name, account owner, domain expiration and renewal settings, nameservers, DNS records and any transfer lock or authorization steps. ICANN explains that registrants manage their domain settings through the registrar and have rights to information about renewal, transfer and restoration; check your registrar’s own process before making a change in ICANN’s registrant guidance.
  • Hosting or website platform: account owner, plan, billing contact, administrator access, backup location and how to restore the site.
  • Code and deployment: repository organization, source files, current production version, build and deployment instructions, environment configuration names, and any scheduled jobs or integrations.
  • Business tools: content management, forms, email delivery, payment or booking services, DNS/CDN, and any licenses or paid plugins.

Do not ask for private keys, API tokens or database passwords in the handover notes. Have the outgoing developer transfer account ownership or invite the incoming person with the access they need, then rotate credentials through the relevant service or password manager. Keep an inventory of which credentials were replaced and who now controls them. OWASP advises against checking keys into version control; keep live secrets out of source files and public repositories. See the OWASP Secrets Management Cheat Sheet.

Collect the site itself and the information behind it

Get a dated copy of the source code or platform export, the original image and document files, fonts and other assets, and a note of any license or usage limits. Ask for a simple map of how to preview, build, publish and roll back the site. If the site uses a database or content management system, request a current export and a tested restoration path, not just a screenshot of the admin panel.

For content, collect the page list and URL list, approved copy, image captions or alt text where maintained, redirects, downloadable files, and a note of pages that are intentionally hidden or retired. Keep the domain and hosting decisions separate from the code handover: moving either account can change email or website behavior if its settings are copied incorrectly.

Make sure you can keep measuring and responding

Request access to the analytics and search reporting accounts, including the account or property names and any dashboards the business relies on. Prefer an invitation to your own account over receiving another person’s login. Google Search Console supports different owner and user permissions; Google advises reviewing who has access and removing or changing permissions when people no longer work on a property. See its permissions guidance.

Also record where contact form submissions go, who monitors them, what sends the notification, and how a failed submission is reported. Keep the actual notification email and a test procedure in the handover. If a developer controls the sending service, arrange a business-controlled administrator before removing their access.

Use a handover checklist you can verify

  1. Make a list of accounts, owners, administrators, renewal dates and recovery methods.
  2. Get current code or exports, source assets, content, URL and redirect lists, and license notes.
  3. Ask for build, publish, backup and rollback instructions, plus a list of integrations and their purpose.
  4. Invite the incoming developer to the required accounts using named access. Transfer ownership only through each provider’s official process.
  5. Have the incoming developer preview and publish an agreed small change, then check the public pages and forms.
  6. Confirm backups can be restored, renewal notices go to the business, and the business can contact the platform providers.
  7. After the new team confirms access, remove former users and rotate credentials that they held.

If a full transfer cannot happen at once, prioritize registrar, hosting, source repository and business email, then schedule the remaining services with named owners and dates. Keep the old site and accounts available until the new team verifies the live site, form delivery and recovery path. Do not cancel an account just because a replacement has been purchased; it may still hold the only copy of files or records.

This checklist is about continuity and access. It does not decide whether the site should be redesigned or guarantee that every platform can be moved without a service change. For a scoped transition, review our website migration service and website handover checklist.