Avoid rushed changes and preserve evidence
If a website is still online, avoid changing hosting, DNS or production files until you know how the site is assembled and how it can be restored. Save the current public URLs, note any errors and record what the business can access. Do not delete accounts or overwrite files just to test a theory.
If there is an urgent outage or security concern, document the symptoms and contact the relevant hosting or domain provider through an official channel. Ask what account recovery process is available and verify who is authorized to act for the business. A careful record helps a new developer understand what changed.
Find out who owns the domain and accounts
A business website depends on several accounts: domain registrar, DNS, hosting, code repository, email, content management, analytics, payment services and sometimes app stores. Create a list of providers and known administrators. Check business email records and invoices to identify renewals or account holders.
The company should control its domain and recovery contacts. If a former developer registered a service personally, contact the provider to understand its transfer procedure and evidence requirements. Do not attempt to bypass access controls or use credentials that the business is not authorized to use.
Recover access through the provider
Use official password recovery, account ownership verification and support channels. Update recovery email addresses and multifactor authentication only after an authorized company administrator regains control. Keep a record of the changes and ensure more than one appropriate business representative can recover critical accounts.
If the provider needs proof of domain or billing ownership, gather invoices, company records and prior correspondence. Recovery can take time, so prioritize the domain and hosting accounts that affect public access. Avoid creating duplicate services until you know whether the original account can be restored.
Locate the source code, backups and documentation
Search business-controlled repositories, shared drives, project handover documents and provider accounts for source code, design files, database exports and deployment notes. Confirm the date of each backup and whether it can be opened or restored. A backup that has never been tested should be treated as unverified.
Do not publish private code or credentials in a public issue or send them to an unknown person. A qualified developer can help identify which repository relates to the live site and what is needed to reproduce a safe environment. Preserve the existing version before making updates.
Assess the site before taking over
A new developer should review the technology, hosting configuration, dependencies, forms, integrations, logs and deployment process. They should ask what the business needs to preserve, what is currently failing and whether any customer data or payments are involved. The goal is to create an accurate picture before proposing a rebuild or making changes.
The assessment may find missing source files, unsupported software, unknown credentials or no reliable staging environment. Those are findings to plan around, not reasons to make unsupported claims. A written risk list can help the business prioritize recovery, urgent repairs and longer-term improvements.
Make a safe transition plan
Once access and system condition are understood, agree who will make changes, how backups are handled and how the live site can be restored. Change one critical part at a time where possible. Test important journeys such as quote requests, login, payments and contact routes after each release.
Update account ownership and remove access that is no longer needed, but preserve service continuity and records. Document where code lives, how deployment works, who pays renewal fees and how future requests should be submitted. This reduces the chance of repeating the same dependency problem with the next provider.
When to rebuild instead of repair
A rebuild may be appropriate when the current system cannot be safely maintained, is unsupported, has no usable source or cannot meet the business’s requirements. It is not automatically the best answer: rebuilding costs time and can lose content, search visibility, data or working integrations if transition planning is weak.
Compare repair, staged migration and replacement based on cost, risk, user impact and future ownership. Preserve useful URLs and content where possible, plan redirects and test before switching DNS. Ask a developer to explain the evidence behind the recommendation and the risks of each alternative.
Get help from web11
web11 can discuss taking over a website or app after the business confirms its authority and arranges access. Share the public URL, known provider names, current issues and what you can still access. Do not include passwords in the first enquiry.
We can assess the current state and outline a safe next step, whether that is account recovery, a repair, maintenance or a planned rebuild. If you are searching for someone to maintain an existing website, start with a clear inventory and a conversation about ownership before authorizing production changes.
Tell customers what to expect
If a public website is unavailable or a key feature is interrupted, provide a clear alternative contact route where possible. Do not promise a recovery time you cannot verify. Keep a note of reported symptoms and the time they began so the provider can compare them with hosting or application logs.
Once service is restored, document the cause if it is known, what was changed and how the business can reduce a repeat problem. A useful handover is more than restoring a homepage; it also leaves the company better able to manage accounts, backups and future supplier transitions.
Frequently asked questions
Can someone take over my website from my old developer?
Yes. Recover business-owned accounts through providers, confirm authorization and have the site reviewed before making production changes.
What if the old developer owns the domain account?
Contact the registrar through its official ownership recovery process and gather billing or business evidence. Do not attempt unauthorized access.
Should I immediately rebuild the website?
Not necessarily. Assess the live site, code, backups, dependencies, business goals and transition risks before comparing repair and replacement.
What information should I give a new developer?
Provide the public URL, known technologies and providers, current issues, available code or documentation and the business goals. Share credentials only through an agreed secure process.
Can web11 maintain a website it did not build?
Yes, after reviewing access, ownership, code and current condition to determine a safe support scope.