Sooner or later almost every site owner faces it: the old developer has gone quiet, replies once a week, or has doubled their price — and you realise it’s time to move on. Then comes the uncomfortable question of how to hand your website over to another developer without losing data, stalling sales, or ending up locked out of your own project. The problem is rarely technical. Moving a site technically is a matter of hours. The hard part is that access, knowledge and arrangements are usually scattered across people’s heads, old chat threads, and someone else’s accounts you didn’t even know existed.

This article is a practical order of operations: what to gather, in what sequence, and what to watch for so that changing providers goes calmly instead of turning into a week of downtime and stress.

Why a Handover Is a Risk, Not a Formality

A website feels like “something out there on the internet” that simply works. In reality it sits on a chain of services: domain, hosting, database, email, payment integrations, analytics, sometimes a dozen small tools only the person who set them up knew about. If even one link is tied to your old developer’s personal account, you depend on their goodwill.

The worst case looks like this: the domain is registered to the developer rather than to you, hosting is paid from their card, and database access runs only through their panel. While the relationship is good, none of this shows. The moment you decide to leave, it turns out the site isn’t really yours. That’s why a handover should start not with code but with an inventory: what exists, where it lives, and whose name it’s under.

The second reason not to rush is data. Orders, your customer base, the history, the content you spent years building. None of it can be rebuilt from scratch. Before any action there must be a fresh backup that sits with you — not “somewhere on the server.”

What to Gather First: Accesses and Accounts

Before you hand your website over to another developer, make a simple list of everything that needs a login. In practice, owners remember half of it only when something stops working. The minimum list:

  • Domain — the registrar account where your site’s name is renewed. This is the most important one: whoever controls the domain controls the site. Make sure it’s in your name or your company’s.
  • Hosting / server — where the site physically lives. Control panel, login details, plan and billing information.
  • The site’s own admin panel — an account with full administrator rights, not just an editor.
  • Database — access, or at least a fresh export.
  • Working email and mailboxes on your domain.
  • Payment and shipping integrations — dashboards, keys, settings.
  • Analytics and advertising — traffic counters, ad accounts, webmaster tools.

The key rule: all of these accounts should be registered to you, not “shared” from someone else’s profile. If anything is tied to the developer’s personal email, that’s the first thing to transfer while they’re still reachable.

Code, Files and Data: The Technical Part

Once access is gathered, it’s time for the technical handover. Here it matters to receive not a “site in one archive file” but a complete, working set: the site’s source files, the database with content and orders, the configurations, and a list of the external services the site relies on to run.

Ask separately for the change history of the code, if one was kept. This isn’t a nice-to-have — the history shows how the site evolved, where the fixes were, and why things were done a certain way. Without it, a new team works blind and burns hours reconstructing what could have been read in minutes.

Another quiet risk is undocumented details. A script that pushes orders into accounting once a day. An automatic backup. A rule that catches spam. You don’t see these while they work, and you very much notice when they vanish. So a handover isn’t just “give me the files” — it’s also the question: what else is running around this site that I need to know about?

The Knowledge That Isn’t in Any Archive

The most valuable thing when changing providers isn’t the files — it’s the context. Why a particular solution was chosen. Which parts of the site are fragile and shouldn’t be touched without testing. What was already tried and didn’t work. This knowledge lives in no archive; it’s in the head of the person who’s leaving.

So it helps to hold a short handover conversation with the old contractor while they’re still willing to help. Not a technical lecture, just answers to plain questions: where things are configured, what payment is tied to, what to do if the site goes down, where to look when there’s trouble. Half an hour of that saves the new team days of investigation — and saves you the money those days would cost.

If contact with the old developer is already lost, don’t panic. An experienced team can reconstruct the picture of a project on its own, from the site and the accesses. It takes longer, but it’s entirely doable. The essentials are simply a complete set of accesses and a fresh copy of the data.

How to Move Over Without Downtime

A proper handover doesn’t look like “switch the old off, switch the new on” — it’s a smooth transition. First the new team receives access and stands up an exact copy of the site in a test environment. Everything gets checked there: do the pages open, do orders go through, do email and payments work. Meanwhile customers notice nothing — the live site keeps running as before.

Only once the copy is fully confirmed does the switchover happen, and it usually takes minutes. This approach removes the owner’s main fear — that “something breaks during the move and sales stop.” With a proper plan there’s no downtime at all, or it’s measured in a few minutes at night when traffic is lowest.

At the studio we’ve been supporting websites since 2018 and have taken on projects in every possible state — from neatly documented to ones without even an admin password. The sequence is always the same: first secure your full control over the accesses, then take a copy, understand the structure, and only then change anything. Our own infrastructure and support let us keep this whole process in hand rather than depending on someone else’s promises.

Where to Start

If you’re weighing up how to hand your website over to another developer right now, you don’t need a ready list of accesses — we’ll help you sort that out. Start simple: send us a short note about your site and what you’d like to change. On a brief first call we’ll point out which accesses to gather first and what to watch for in your specific situation, so the move goes calmly and nothing gets lost.