Taking over a website from another developer: the first 30 days

When the developer or agency behind a website moves on, the site doesn’t notice. It keeps taking inquiries, plugins keep releasing updates, and the domain keeps counting down to renewal. What leaves is the knowledge of how it all fits together.

Taking over a site well is mostly about order. Here’s the sequence I follow in the first month, and why each step comes where it does.

Week one: access, backups, and leads

Nothing else matters until these three are solid.

Access and ownership. Get logins for everything, and move each one into accounts the business owns: the domain registrar, DNS, hosting, the website admin, analytics, Tag Manager, ad accounts, form tools, the CRM, and email. If the outgoing team holds any of these in their own name, that’s the first thing to fix while they’re still answering emails.

A backup that actually restores. A backup nobody has tested is a hope, not a backup. Take a full copy of the files and the database, store it somewhere the business controls, and confirm it can be restored.

Leads still arriving. Submit every form on the site and follow each one to where it should land: the inbox, the CRM, the booking system. Forms quietly break during handovers more than anything else, usually because a notification address or an API key belonged to the person who left.

Week two: write down what’s there

Now take inventory, without changing anything yet:

Platform, theme, and page builder, with versions
Every plugin, what it does, and whether anything still uses it
Custom code, and where it lives
Integrations: forms, CRM, payment, booking, email
Tracking: analytics, pixels, ad conversion tags
Scheduled tasks and anything else that runs on its own

Then set up a staging site, a private copy where changes get tried before they reach the real one. Many sites have never had one. From here on, nothing gets changed live first.

Week three: updates and security

With a backup and a staging site in place, updates stop being a gamble:

Bring core, theme, and plugins current on staging, check the pages that matter, then repeat on the live site
Remove plugins nothing uses, and admin accounts for people who’ve left
Turn on uptime monitoring, so you hear about an outage before a customer does
Check that SSL, email records, and the domain renewal won’t surprise anyone

Week four: documentation and a plan

By now there’s a clear picture. Write it down: how the site is built, where everything lives, who has access, and how changes get made. Then make a short list of known issues and improvements, in order of what they cost the business.

That list becomes the plan for month two. The takeover is done when the site is safer than it was, and when the knowledge lives with the business instead of with one person.

What to ask the outgoing team

If they’re still reachable, a short handover call saves hours. Ask for:

Every account and login, and which ones are in their name
Anything custom they built, and where it lives
Anything that runs on a schedule or depends on a key or token
Known problems they never got to
What they’d do next if they were staying

What not to do in the first month

Don’t redesign. Don’t switch hosts unless you’re forced to. Don’t run every update at once on the live site. The first month is about making the site safe and understood. Improvements come faster afterward, because nobody is guessing anymore.

If your developer or agency is leaving, here’s how I handle the handoff. The sooner it starts, the more of their knowledge you get to keep.