Before you start
- ✓An administrator login to wp-admin (check it works first)
- ✓A hosting account in the business's own name
- ✓The domain name, plus any old invoices or emails that mention it
- ✓A list of what uses the domain besides the website (email especially)
- ✓A staging copy to test plugin changes on
1. Check what you can still log in to
Log in to wp-admin (the WordPress dashboard) and check your role under Users → Profile. You need to be an Administrator: editors can't install plugins, and a plugin is how you'll get the site out. Then list what else you can reach: the hosting account, the domain registrar, DNS and any premium plugin accounts. On the manufacturer's site we recovered, wp-admin was the only thing the client could still get into. That was enough. What's on your list decides which of the steps below you need.
2. Set up hosting in the business's own name
Open a hosting account billed to, and owned by, the business, not a person or a supplier. We moved the site to WP Engine's managed WordPress hosting, which includes backups and a staging copy, so every later change could be tried safely first.
3. Copy the site across from wp-admin
Install the new host's migration plugin on the old site (we used WP Engine's). It copies the database, themes, plugins and uploads to the new account, with no need for access to the old server. Check the copy thoroughly on the new host's temporary address before you touch the domain.
A bloated media library slows every copy and backup. This site's was around 3 GB, and we cut it by 77% as part of the clean-up (see how to reduce a WordPress media library safely).
4. Find out where the domain is registered
Run a WHOIS lookup on the domain, for example with ICANN Lookup. The owner's details are usually hidden, but it shows the registrar (the company the domain is registered with) and the nameservers (who runs its DNS today): which account to recover, and where the DNS records live.
5. Recover the registrar account
Use the registrar's account recovery process with the business's details. Old invoices and the email address the domain was bought with help. If the developer registered it on their own account, the registrar will say what proof it needs to move it to you. We guided the client to the right registrar and helped them regain access.
6. Point the domain at the new host
First write down every existing DNS record, including the mail (MX) records, so email and anything else on the domain keep working. Then add the new host's records and check the site on the real domain.
7. Audit every premium licence
For each premium plugin and theme (Elementor included), we look at:
- who the licence is registered to;
- whether it's active, expired or about to renew;
- whether the site actually uses it. If you're not sure, deactivate it on staging and see what breaks.
Here, every licence was registered to the old developer and many had expired. Only six were actually needed.
8. Re-license what you need, in your own name
Buy the licences the site needs on a business email address, enter the new keys, and note the renewal dates where the business will see them. Remove plugins nobody uses rather than leaving them installed and unpatched.
9. Bring everything up to date on staging first
With valid licences in place, update WordPress, the theme and the plugins on staging, check the site, then repeat on live. From here on, updates are routine instead of a gamble.
What usually goes wrong
From our own projects, not the manual.
No hosting access at all
With the developer out of business, nobody could reach the old server. An administrator login was enough: the migration plugin copied the whole site to new hosting without the old host's involvement.
Every licence belonged to the developer
Elementor and the premium plugins were registered to the old developer, and many had expired, so the site couldn't get updates or support. Buy licences in the business's name: one on someone else's account can lapse without you ever knowing.
Paying for plugins the site didn't use
Some licences were still being paid for, but for plugins the site no longer used. Six were essential. Audit what the site actually uses before renewing anything.
Nobody knew where the domain was registered
A WHOIS lookup showed the registrar and the current nameservers, which told the client which account to recover and who controlled the DNS.
A 3 GB media library
Oversized original images made the site slow to copy and back up. Shrinking them cut the library by 77%, to under 700 MB.
Do it yourself, or get help?
If you have an administrator login, the site is simple and you know what each plugin does, you can do this yourself with a migration plugin and a WHOIS lookup. Get help if you can't log in as an administrator, the domain is registered in the developer's name, the site takes payments or bookings, or you're not sure what depends on what: a missed licence or DNS record is what takes a site down.
Get a developer on it