When an employee, freelancer, developer, or agency relationship ends, changing the WordPress password is only one part of securing the website. The same person may have access to hosting, domain registration, DNS, server files, code repositories, analytics, advertising, email delivery, or backups. Some of those accounts may even have been created under the departing provider’s email address.
A good handover gives the business reliable control without interrupting its website or lead flow. Identify the accounts first, establish and test access for a current business owner, collect the settings and records needed for continuity, and then remove former users and rotate shared credentials. The seven checkpoints below cover the places most likely to be overlooked.
Quick Answer
Audit seven areas when a website-related relationship ends: WordPress users; hosting; domain and DNS; server credentials; source code and software licences; marketing and lead systems; and backups. Where a provider controls an essential account, arrange business-controlled access and verify it works before ending that access. Then revoke individual permissions, rotate shared passwords and keys, update recovery details, and test the site’s important functions.
Key Takeaways
- A WordPress password change does not remove access to hosting, DNS, files, repositories, or connected services.
- Confirm who owns each account and how the business can recover it before removing the last working administrator.
- Revoke named access and replace shared credentials, API keys, and deployment tokens that the former provider could still use.
- Document paid software licences, email delivery, backups, billing, and renewal responsibilities during the handover.
- Finish by testing logins, a form submission, tracking, and the recovery path.
Why website offboarding needs an access audit
Website administration rarely lives in one place. WordPress manages content and settings, but the hosting account controls the server, a registrar maintains the domain registration, and a DNS provider directs traffic to the website and email services. Marketing accounts can hold years of reporting history. Backup storage may belong to a completely different provider.
The issue is not necessarily misconduct by someone leaving. An agency might have registered a service under its own account for convenience, or a former employee might be the only person with a second authentication method. Either arrangement can delay an urgent update, a renewal, or a recovery. The practical question is whether authorized people at the business can independently access, maintain, and recover every essential system.
Build a simple access register as you work: record each service, its business owner, technical contact, billing owner, recovery method, and whether a former provider still has access. Store the register securely; do not put passwords or recovery codes in a shared spreadsheet.
1. WordPress administrator accounts and connected access
Start at Users in the WordPress dashboard. Review the people listed, their email addresses, their roles, and why they still need access. Confirm that at least one current, named business administrator can sign in and recover the account. Then remove accounts belonging to former staff and providers. When deleting a user, reassign their posts and pages if you need to preserve an identifiable author.
Administrator access warrants particular attention because WordPress administrators can manage users, plugins, and important site settings. The official WordPress roles and capabilities guide explains how these permissions differ from those of editors and authors. Give each remaining person a named account with the permissions their work actually requires.
Check more than the main login. WordPress application passwords, security plugins, membership tools, form plugins, WooCommerce, and other extensions may expose separate users, API keys, or service connections. Review those access paths and revoke credentials that a former provider created or could still use. If multiple people used one shared WordPress login, replace that arrangement with individual accounts and change the shared password.
2. Hosting account and control panel
Identify the company that hosts the live site and confirm who owns the account, pays the bill, receives renewal notices, and can contact support. A business-controlled administrator should be able to reach the hosting dashboard and its recovery email and multi-factor authentication method. Review invited users and support contacts, including access to staging sites and any account-level settings.
If the outgoing agency pays for hosting or keeps the website inside its own hosting account, do not assume that receiving a WordPress administrator login transfers hosting control. Agree on continued service or a documented migration, with a current backup and a new account or authorized access in place. Verify the site and email dependencies before changing or canceling the old arrangement.
Document the hosting plan, server or site identifier, renewal date, and where to find support. This gives the next provider a way to respond to an outage without searching old invoices or asking the former team for credentials.
3. Domain registration and DNS
The registrar account and the DNS hosting account may be separate. Check the domain’s registrant and administrative contact details, renewal method, account recovery address, and multi-factor authentication. Make sure the business has a durable way to renew and manage the domain rather than depending on a former employee’s personal email. ICANN offers a guide to protecting domain registration accounts that gives this risk the attention it deserves.
Next, identify where the authoritative DNS records are edited. That could be the registrar, host, Cloudflare, or another DNS provider. Record the nameservers and export the existing DNS zone before making changes. Website records are only part of the picture: MX, SPF, DKIM, and DMARC records can affect business email and form notifications, while verification records may be needed for search and marketing services.
Transfer or establish business-controlled registrar and DNS access before removing the outgoing administrator where possible. Remove their invitations or tokens after the handover, and test that the website resolves and email still works. Our discussion of website ownership and access after launch explains why these responsibilities should be clear even before a vendor change becomes necessary.
4. Server, file-transfer, and database credentials
WordPress access is separate from the technical routes used to change its files and database. Review SFTP accounts, SSH users and keys, hosting control-panel logins, database users, and any server-management service used by the departing developer. An old server key can remain effective even after every WordPress account has been removed.
Disable individual accounts and revoke their keys. Rotate shared SFTP passwords, database passwords, and other secrets that the former provider knew. Coordinate database credential changes with the site configuration so the live website does not lose its connection. Keep production secrets in an approved password manager, not in email threads, tickets, or a document that remains shared with the former team.
Review access to staging and development copies too. Those environments may contain a recent database, customer details, or live service credentials even when their public URL is hidden.
5. Source code, deployment tools, and paid software licences
Find out where custom themes, plugins, scripts, and deployment instructions are stored. Review GitHub, GitLab, Bitbucket, automated deployment services, build pipelines, and any personal access tokens used to publish changes. The business or its new technical partner should be able to retrieve the current code, identify who can deploy it, and perform a controlled update without the outgoing developer’s private account.
Replace deploy tokens rather than leaving a former provider’s token running indefinitely. Preserve the repository history and document the branch, build process, and destination for deployments. A handover is incomplete if the code is available but the only person who knows how to publish it has left. This is particularly relevant when custom WordPress pages depend on code or integrations that need ongoing maintenance.
Inventory premium themes, page builders, form plugins, and other licensed services. Some licences are agency-wide or attached to the provider’s account and cannot simply be transferred. Record what remains covered, what requires a new business-owned subscription, and which renewals or updates could stop after the relationship ends. Do this before removing a licence that the live site still relies on.
6. Analytics, advertising, email delivery, and lead systems
Review Google Analytics, Google Tag Manager, Search Console, Google Ads, Google Business Profile, call tracking, CRM and email marketing platforms. Confirm that a business-controlled owner has the appropriate level of access and that billing and recovery details are current. Agencies can then be given invited permissions suited to their role rather than becoming the only account owners.
Check the services that move inquiries out of WordPress: form notification addresses, SMTP or transactional email accounts, booking tools, webhooks, and CRM connections. If the outgoing provider owns an email sending account or API key, arrange its replacement, update the website connection, and send a real test submission. For an online store, include the payment gateway and other order-related service accounts in the review.
Before removing a marketing provider, preserve conversion definitions, tag-container access, campaign and account IDs, call-routing settings, relevant reports, and current billing contacts. Then verify that calls and form messages reach the right people and that the agreed conversions still appear in the systems the business uses. A site can look normal to visitors while its lead routing or measurement has quietly stopped.
7. Backups and the ability to restore the site
Identify every backup location: the hosting provider, a WordPress plugin, cloud storage, and any separate agency system. Confirm what each backup contains, how often it runs, how long copies are retained, and who can access and restore them. NIST’s backup guidance emphasizes maintaining and testing copies so they are useful when recovery is needed.
If the only off-site copy sits in the departing agency’s account, secure a business-accessible backup and an agreed restore process before that account is closed. Do not assume a file download alone is a complete recovery plan; confirm that the files and database are present and that someone knows how to restore them. A test on staging, when appropriate, offers better assurance than a backup status message by itself.
Document the backup owner, storage location, retention period, restore contact, and last successful test. That information is often most valuable precisely when the normal hosting account is unavailable.
How to confirm the handover is complete
After the seven reviews, have a current business owner or authorized technical partner verify the accounts. The order matters: establish access and preserve what is needed, remove former permissions, rotate shared secrets, and test the services people depend on.
- Sign in to WordPress, hosting, the registrar, DNS, repository, marketing systems, and backup storage using current accounts.
- Confirm password resets, billing notices, and multi-factor authentication reach current business contacts.
- Check that old user invitations, tokens, SSH keys, and shared sessions have been removed or replaced.
- Submit a test form, verify email delivery and lead routing, and confirm important analytics or conversion events still record.
- Locate a recent complete backup and confirm who could restore it if the live site failed.
Keep the access register up to date when staff, agencies, or systems change. One accountable business owner and one authorized technical contact are often enough to prevent essential services from becoming tied to an undocumented individual.
Conclusion
Website offboarding is complete when the business can operate, renew, measure, and recover its site without relying on a former employee or provider. Review all seven access areas, establish business-controlled accounts, preserve handover records, remove unnecessary permissions, and test the website’s most important functions.
If you need ongoing help organizing access, updates, backups, and website oversight, explore nuBranch Media’s WordPress management support.
