You've decided to move on. Maybe the work stalled, maybe the quality slipped, maybe you've simply outgrown them. The decision is the easy part. The part that goes wrong is the handover.
Done properly, switching developers is a quiet weekend with no visible change to your customers. Done badly, your site goes down, your business email stops working, and six months of Google rankings evaporate. The difference is almost entirely preparation.
Collect everything before you announce anything
This is the single most important rule. Once a developer knows they're being replaced, cooperation tends to drop — not usually out of malice, just priorities. Get your access sorted first, then have the conversation.
Here's the full list.
Domain registrar login. Which company the domain is registered with, plus the username and password. Not the developer's dashboard — the actual registrar account.
Hosting control panel. cPanel or equivalent, with the URL, username and password.
A full backup. Files and database together. From cPanel this is one button. Download it and keep a copy somewhere that isn't the server.
The source code. If it was custom-built, ask for the repository — GitHub, GitLab, or a zip. If it's WordPress, the backup covers it.
CMS admin account. An administrator login in your own name, not a shared one.
DNS records. Take a screenshot of the DNS zone before anything changes. This is the thing people forget, and it's what breaks email.
Email accounts. If your business email runs on the same hosting, list every mailbox and export the mail. Moving hosting without doing this is how companies lose years of correspondence.
Third-party accounts. Google Analytics, Search Console, your Google Business Profile, Paystack or Flutterwave, any SMS or mail service. These are frequently registered under the developer's email and are worth more than the website.
Do not accept "don't worry, I'll handle it" for any of these. You are asking for keys to things you own.
Check whose name it's all in
Run a WHOIS lookup on your domain before you start. If the registrant email is your developer's, you have an ownership problem to solve before you have a migration problem. That's covered properly in who actually owns your website and domain.
If your developer has stopped responding altogether, the sequence is different — start with what to do when your developer goes silent.
Moving the domain
You have two options, and most people pick the wrong one.
Change the contact details. If the domain is at a decent registrar, you can simply update the registrant name and email to yours and change the password. No transfer, no downtime, no waiting. For most situations this is enough.
Transfer to a different registrar. Needed if you don't trust the current registrar or can't get an account with them. You unlock the domain, request the authorisation code (also called an EPP code), and start the transfer at the new registrar. Expect it to take a few days.
Two things worth knowing before you start: domains generally can't be transferred within 60 days of being registered or of a previous transfer, and at many registrars changing the registrant details also triggers a 60-day transfer lock. So if you plan to do both, change the details after the transfer, not before. Confirm the exact rules with your registrar — they vary, particularly between .com and .ng domains.
Moving hosting without going down
The order matters.
- Set up the new hosting and copy the site across.
- Test it on a temporary URL until it's genuinely working — every page, every form, payments included.
- Lower the DNS TTL to a short value a day beforehand, so the change propagates quickly.
- Switch the DNS to point at the new server.
- Keep the old hosting running for at least two weeks.
That last step is the one people skip to save a few thousand naira, and it's the one that saves you when something turns out to be missing. Overlap is cheap. Downtime is not.
Protecting your Google rankings
If your URLs stay the same and your content stays the same, you keep your rankings. Problems come from redesigns bundled into the migration.
If pages must move, map every old URL to its new equivalent and set up 301 redirects. A 301 tells Google the page moved permanently and passes the ranking across. Without it, every link anyone has ever made to your site points at a 404.
After the switch: check Search Console for crawl errors, confirm your sitemap is submitted and correct, and make sure the new server isn't accidentally blocking crawlers — a noindex tag left over from the staging site is the classic way to disappear from Google entirely.
If you can't get access at all
It's recoverable more often than people fear.
Registrars and hosting companies have account-recovery processes. If the account was paid for by your business, you can usually prove ownership with CAC registration documents, payment receipts and a matching business email address. It takes patience and paperwork, but it works.
If the domain genuinely can't be recovered, you rebuild on a new one. You'll lose search rankings and anyone with the old address bookmarked, which is painful but survivable. Businesses do it and recover.
Getting it right next time
Whoever you hire next, agree three things in writing before work starts: the domain is registered in your business name, you get administrator access to everything from day one, and a full backup plus source code is handed over at launch.
Any developer worth hiring will agree without hesitation. The ones who push back are telling you something useful.
We do this regularly
Taking over sites other people built is normal work for us — we audit what's there, fix anything urgent, migrate with redirects intact, and maintain it afterwards. If the site turns out to be built on something genuinely unmaintainable, we'll tell you that before you pay rather than after.
Tell us what you're working with and we'll give you an honest assessment. Pricing is published, and you can see work we've delivered with the clients named.
Have a project in mind?
Get a fixed quote from a Port Harcourt team.