A lot of website projects change hands: the freelancer took a full-time job, the agency relationship ended, or the developer simply stopped replying. Handing a site to someone new goes smoothly when the business controls its own accounts and the new developer starts with a proper review instead of guesses.
1. Make sure your business owns the accounts
Every account the site depends on should be in your business’s name, with a login you control. Collect or recover access to:
- The domain registrar (where the domain is registered and renewed).
- DNS, if it is managed somewhere else, such as Cloudflare.
- Hosting and its control panel, plus SFTP or SSH access.
- The website admin: WordPress, Shopify, or another CMS. Create a new admin user rather than sharing the old developer’s login.
- Code repositories (GitHub, Bitbucket) if the site is in version control.
- Google Analytics, Tag Manager, and Search Console.
- Third-party services: payment providers, email delivery, forms, CRM, and premium plugin or theme licenses.
If the previous developer registered something under their own account, ask them to transfer it. If they are unreachable, the hosting company and domain registrar have ownership recovery processes for the account holder of record.
2. Take a full backup before anything changes
Back up the files and the database, and store the copy somewhere other than the server. For Shopify, duplicate the live theme and export products and customers. This gives the new developer a safe starting point and protects you if access disappears later.
3. Remove access you no longer need
Once your own logins work, remove or downgrade the previous developer’s accounts on the hosting, CMS, and services, and change shared passwords. It’s routine housekeeping, not an accusation.
4. Get a technical review
A good handover starts with an inventory of what actually exists:
- Platform, theme, and versions, and whether updates are overdue.
- Plugins or apps in use, and which ones are no longer needed.
- Custom code: where it lives, and whether it is documented.
- Hosting setup, backups, SSL, and email deliverability (SPF and DKIM records).
- Security: unknown admin users, malware, outdated software.
- Tracking: whether analytics and conversion events actually fire.
- A list of known bugs and unfinished features from the previous work.
5. Prioritize, then fix
Sort what you found into three groups: things that put the business at risk (security, broken checkout or forms, expiring domains), things that block planned work, and improvements that can wait. Fix in that order, on a staging copy where possible.
6. Write it down
Ask for a short, plain-English summary of how the site is built and which accounts it depends on. The next handover, whenever it happens, then takes an afternoon instead of weeks.
Picking up sites from other developers is a large part of DR3’s work. If your project stalled, send the site link and a few lines about what happened.