Introduction
A developer becoming unavailable can be stressful, especially when they are the only person who understands the website.
The situation is much easier when the business already controls the domain, hosting and key accounts.
Do not start by making random DNS or server changes.
First establish what the business owns and what access still works.

Step 1: Check Domain Ownership
Find the domain registrar and determine which account controls it.
Look through billing records, old emails or internal documentation.
If the business controls the registrar, protect the account immediately with current recovery information and multi-factor authentication.
Do not transfer the domain unnecessarily unless there is a reason.
Step 2: Identify the Hosting Provider
Find where the website is hosted and whether the business has account access.
Old invoices, card charges and DNS records can provide clues.
If the account belongs to the business, update authorized contacts.
If it belongs to the developer, contact the provider and review what recovery or ownership process is available.
Step 3: Secure CMS and Application Access
If administrator access still works, create or confirm a business-owned account.
Do not delete the old developer account immediately if doing so could break integrations or deployment workflows.
First understand how the site operates.
Then reduce unnecessary access once a replacement developer has reviewed the system.

Step 4: Create a Backup
Before making major changes, create a full recovery point if you have the required access.
Back up files, database and important configuration.
For custom applications, preserve source code and deployment information.
The goal is to avoid turning an access problem into a data-loss problem.
Step 5: Find the Source Code
Custom sites may depend on code stored in GitHub, GitLab, Bitbucket or another repository.
Search company accounts and previous project communications.
If deployment is connected to a platform such as Vercel or another host, identify which repository and team own the project.
A live website alone may not contain everything needed for future development.
Step 6: Audit Third-Party Services
List email services, form providers, analytics, payment gateways, APIs, booking systems, CDNs and other integrations.
Confirm ownership and billing for each.
Rotate credentials when necessary after understanding dependencies.
Do not revoke keys blindly if they are actively used by the site.
Step 7: Protect Business Email
Website and email services may share DNS.
A careless domain change can interrupt business email even if the website migration works.
Document MX and other email-related DNS records before changes.
Coordinate with the email provider during DNS migrations.
Step 8: Bring in a Replacement Developer Carefully
Give the new developer the access needed to audit the environment.
Ask for a written summary of the current stack, risks and missing ownership.
Prioritize backups and business continuity before redesign ideas.
Stabilize the existing system before making optional changes.

How to Prevent This Next Time
Keep business-controlled accounts for domain, hosting, analytics and key services.
Require repository and documentation access during the project.
Use milestone-based handover instead of waiting until the final day.
Maintain at least basic internal documentation of where the website lives and who can recover it.
Frequently Asked Questions
Can I recover a website without the developer? — Often yes if the business controls the domain, hosting or platform accounts, but the exact recovery options depend on the setup.
What if the domain is in the developer's name? — Contact the registrar and review the contractual and account-recovery situation. Legal advice may be necessary in a serious ownership dispute.
Should I rebuild immediately? — Not before preserving data, access and existing functionality.
Can a new developer take over WordPress or custom code? — Usually, but the difficulty depends on code quality, documentation and whether source files and credentials are available.