Check the immediate situation
Is the website still online? Are forms reaching you? Is a domain, hosting plan or software licence about to expire? Record urgent dates and visible faults. If everything works, there is usually more room to plan a controlled handover than if a renewal is due tomorrow.
Use the provider’s ordinary account recovery or ownership-verification process for accounts you are entitled to manage. Do not try to access somebody else’s account or bypass authentication. A new developer can assess the technical situation, but ownership disputes depend on the agreements and evidence available.
Build an access inventory
| Item | Why it matters |
|---|---|
| Domain registrar | Controls renewal and where the domain is pointed. |
| DNS provider | Holds records for the website, email and other services. |
| Hosting and backups | Contains the running site and a potential recovery route. |
| Website admin and source code | Allows content changes and technical maintenance. |
| Email service | May be separate from hosting, even if the previous developer arranged both. |
| Forms, booking and payment accounts | Can keep working independently or fail after an account change. |
| Licences and documentation | Explain renewals, dependencies and how releases are made. |
Record who owns each account, who has access and what renews when. Share access through suitable delegated accounts or a secure method agreed with the new supplier. Do not paste passwords or secret keys into a contact form.
Take a recoverable copy before making changes
Ask the incoming developer to establish what a backup contains and whether it can be restored. A copy of public web pages is not necessarily a backup of the database, uploads, source code or configuration. For a working booking system, records can change while the handover is happening.
Preserve a note of current domain and email settings. Changing nameservers without reproducing required records can interrupt email even when the new website itself works. Plan changes with somebody who understands all the services on the domain.
Ask for an assessment before agreeing to rebuild
A new supplier needs to understand the technology, access, dependencies and outstanding faults. Missing documentation can increase the effort, but it does not automatically make the site unusable. Separate urgent recovery from improvements you can schedule later.
- Can the existing site be maintained with the access available?
- Which components or licences depend on the previous supplier?
- Can a test environment be created without affecting customers?
- What would be needed to release a small change reliably?
- Which risks require immediate attention and which can wait?
Transfer responsibility in a controlled sequence
Agree the handover scope, make and test the required backups, establish access for the new supplier and verify the customer journey after each material change. Remove obsolete access when responsibility has actually transferred and the relevant accounts are under the right control.
If the move includes hosting or URL changes, use the website migration checklist. If a replacement is proposed, compare it against the repair and redesign options before discarding working functionality.
Avoid the same dependency next time
Make account ownership, documentation, backups, renewal reminders and exit arrangements part of the new agreement. More than one authorised person in the business should know where essential accounts are recorded. Our maintenance guide explains responsibilities worth agreeing before ongoing support starts.
Discuss a website handover
Tell us the website address, whether anything is currently failing and which accounts the business controls. We can discuss whether an assessment is possible before proposing changes.