Website Held Hostage? How to Migrate WordPress When Your Developer or Host Holds the Keys

You need to move your website, and someone else has the keys. Maybe your web developer disappeared three months ago and stopped answering emails. Maybe the agency that built your site folded, or got acquired, or is holding your website hostage until you sign another contract. Maybe you inherited this website from someone who left the company and took the only password with them. No one wants their website held hostage.

Whatever got you here, the result is the same: you own a website you can’t fully get into.

Every guide you find online starts with “log into your hosting control panel” or “log into your WordPress dashboard” — and at least one of those is exactly the thing you can’t do.

Here’s the good news: there’s a path out of almost every version of this. Which path depends on what access you still have. There are really three scenarios, and they’re worth walking through one at a time — including the ugly one at the end.

First, Check Who Owns Your Domain

Before any of the three scenarios below, settle one question: is the domain name registered in your name, in an account you control? Everything else in this article assumes the answer is yes, because the last step of every path is pointing your domain at a server you own. If the domain isn’t yours, that step isn’t available to you yet.

Look it up at lookup.icann.org. Type in your domain and read two things: the registrar (GoDaddy, Namecheap, Google Domains, whoever) and the registrant. The registrant is often masked by a privacy service, and that’s fine. What matters is whether you have a login at that registrar that shows this domain in your account. If you do, you own it. Skip ahead to the scenario that fits.

If you don’t, the domain was registered by your developer or agency in their account, usually with good intentions and a line like “we’ll handle that for you.” That’s the one form of lockout none of the steps below can fix, because it isn’t a technical problem. It’s an ownership problem.

Here is the order to work it in. First, ask plainly and in writing for the domain to be transferred to a registrar account in your name. A legitimate provider does this without drama, even during a dispute over money, because the domain was never theirs to keep. Transfers between registrars take a few days and need the domain unlocked and an authorization code from their side, so make the request specific: “please unlock the domain and send the transfer authorization code.” Second, if they refuse or go silent, contact the registrar directly. Registrars have a process for exactly this, and it goes faster when you can show the domain has been used for your business all along: invoices showing you paid for it, your business registration, marketing that carries the domain. Third, if the registrar won’t act, a letter from a lawyer usually does what emails didn’t. If the domain is your registered business name or trademark, there are formal dispute channels as well, but they cost real money and take months, so treat them as the last resort, not the first move.

While that’s in progress, get the site itself out of harm’s way. If you have wp-admin, take the full export described in Scenario 2 now, before anyone decides to change your password. And put a reminder on the domain’s expiry date, which the lookup also shows. A developer who has stopped responding may also have stopped paying for renewals.

Then come back here. Once the domain is in your account, the rest of this article works exactly as written.

---

Scenario 1: You Have Hosting Access, But No WordPress Admin

This one sounds backwards, but it happens all the time. You’ve got the hosting account — maybe it was always in your name, maybe you recovered it — but nobody has a working wp-admin login. The old developer created the only administrator account, and it’s tied to an email address that no longer exists.

If you’re here, you’re in the best shape of the three. Server access is the master key. WordPress admin access can be rebuilt from it; the reverse isn’t true.

Two ways in:

Reset the admin password with WP-CLI. If your host gives you SSH access (most decent ones do), WP-CLI can list every user on the site and reset any password directly — no email link, no “forgot password” form pointed at a dead inbox:

wp user list
wp user update admin --user_pass="a-new-strong-password"

If the only administrator account belongs to someone long gone, you can also just create a fresh one:

wp user create yourname you@yourcompany.com --role=administrator

Thirty seconds of work, and you’re back in your own site.

Restore from a backup. If something on the site is broken or you suspect the old developer left it in a bad state, a hosting-level backup restore gets you to a known-good starting point first. Restore it to a staging copy if your host supports that — check that everything works before you touch the live site — then do the password reset on the restored copy.

Once you’re in, do the housekeeping: remove admin accounts you don’t recognize, remove any remote-management plugins you didn’t install, and change every credential the old developer might still have.

Scenario 2: You Have wp-admin, But No Hosting Access

This is the most common version of “locked out.” You can log into WordPress, but you have no FTP, no database credentials, no hosting control panel — because the hosting account was never yours. It belongs to the developer or agency, and they’re not handing it over.

Here’s the part most people don’t realize: WordPress admin access is enough to get your entire site out.

Backup and migration plugins — UpdraftPlus, Duplicator, All-in-One WP Migration — install through the normal WordPress plugin screen and package your whole site into a downloadable archive: files, database, media, themes, plugins, everything. No server credentials required. That’s the whole point of them.

The process looks like this:

1. Install a migration plugin from the dashboard and run a full site export. Watch for size limits on free tiers — a media-heavy site may exceed the cap and need the paid version to get everything into one archive.
2. Find a new host. If that’s your own hosting account, fine. If it’s an agency or provider you trust, that’s fine too — just make sure you have your own wp-admin access and regular backups you can get to, so this never happens again.
3. Install the same plugin on the new site and import the archive. Expect to spend real time here, not five minutes — this is where broken image paths and plugin quirks surface.
4. Test everything on the new server before touching DNS. Forms, menus, mobile, checkout if you have one. Use the new host’s temporary URL or a hosts-file edit so no visitor sees the work in progress.
5. Cut DNS over last — and read the live DNS record set before you edit anything. Never work from an old screenshot or a document someone sent you weeks ago. Records drift, and overwriting a verification token or a mail record breaks things you won’t notice until they’re already broken.

The old host can go on hosting their copy of your site until the account lapses. It doesn’t matter. Your domain points at your server now.

Scenario 3: No Hosting, No wp-admin, Nobody Answering

Now the hard one. No hosting access. No WordPress login. The agency doesn’t return emails, or the company dissolved, or the one person who had the keys is unreachable. The site is running — you can see it in a browser like everyone else — but that’s the only access you have.

There’s no trick that gets you into that server. What you can do is rebuild from what’s publicly visible, because the one thing still working in your favor is the browser: everything your visitors can see, you can capture.

This is a reconstruction, and honestly, it’s the process to expect:

1. Scrape the live site. Tools like HTTrack, or a crawler like Screaming Frog, can pull down every public page, image, and stylesheet. What you get is the rendered output — the HTML your visitors see — not the WordPress installation underneath. Themes, plugins, and the database don’t come with it.
2. Rebuild in a fresh WordPress install on hosting you own. The scraped content becomes your source material: page copy, images, structure, menus. Depending on the site’s size, this ranges from a long afternoon to a real project. It’s also, frankly, a decent moment to fix everything you never liked about the old site — you’re rebuilding anyway.
3. Recreate what a scrape can’t capture. Forms don’t scrape — they have to be rebuilt and pointed at your email or CRM. Anything behind a login, any dynamic functionality, any e-commerce — those get rebuilt, not copied.
4. Point your domain at the new site. This is the moment the old provider becomes irrelevant. You update DNS at your registrar to point at your new hosting, and their copy of your site is just a server nobody visits anymore.

A side note worth considering: you don’t have to rebuild in WordPress. Since you’re rebuilding from scratch anyway, this is the one moment the platform is genuinely up for grabs. For a site that’s mostly content — pages, posts, images — a static rebuild in something like Astro will be faster than WordPress, cheaper to host, and has almost nothing to hack or maintain. And “static” no longer means calling a developer for every text change: tools like Decap or Sveltia put an editing dashboard on top of a compiled site, so your team can still make updates themselves. The honest tradeoffs are elsewhere — far fewer developers know this stack than know WordPress, which matters if you ever need to hand the site off, and anything dynamic (complex forms, search, e-commerce) means wiring in services rather than installing a plugin. For a lot of small business sites, it’s a genuinely better outcome. For sites that lean on WordPress’s ecosystem, WordPress is still the right call.

One caution before you start: if there’s any chance the old provider will respond — a certified letter sometimes works where email didn’t — it’s worth one real attempt before committing to a rebuild. A proper export is always better than a scrape. But don’t wait months on someone who’s already shown you who they are. The rebuild path works, and it ends with something the other two scenarios end with too: a site that’s actually yours.

The Pattern Behind All Three

Notice what every scenario has in common: the problem was never WordPress. It was access. The admin login, the backups, the basic knowledge of what lives where — somewhere along the line, those ended up entirely in someone else’s hands, and nobody noticed until it mattered.

The migration fixes today’s problem. The lasting fix is simpler than you’d think: keep your own wp-admin access, make sure the accounts that should be in your name actually are, and have backups you can reach if things go south. It’s fine to have a host or an agency handling the technical side — that’s what they’re for. You just never want to be in a position where losing one relationship means losing your website.

Locked out and not sure which scenario you’re in? Get a Free Rescue Assessment — we’ll tell you honestly what it’ll take to get your site back under your control.