What to Check Before You Move a Project to a New Agency

I regularly get enquiries from companies whose relationship with their current agency has gone bad. Slow responses, invoices nobody can account for, a new account manager who does not understand the product. The reasons vary.

Taking a project over is fine. Starting without checking a short list costs about double the quote, and the extra is not rebuilding anything. It is time spent finding out where things are.

Here is what to confirm before you sign anything, in priority order.

First: who owns the domain and the accounts

This comes before everything, including anything technical.

The domain. Whose name is it registered in. Registration in the agency's name does happen. In that state a transfer needs their cooperation, and after the relationship has soured that can take a while.

DNS. Where it is managed. Owning the domain is not enough if the DNS sits under their account, because you cannot switch anything over.

Servers and hosting. Who the contracting party is. If you are riding on their account, you cannot move it yourself.

Analytics and verification. Google Analytics, Search Console, ad accounts. If these live under the agency's account you may not be able to take the history with you, and history is the one thing you cannot recreate later.

Do not open any other conversation before those four are settled. However tidy the code is, work cannot start until access is yours.

And all of it is dramatically easier to confirm while the relationship is still good.

Second: source code and design files

Source code. Do you have it. If it is on GitHub, is the repository under your organisation. A repository under their account disappears the moment permissions are revoked.

Original design files. The Figma files, or whatever came before them. If all you have is exported images, every future change means recreating the source.

Build and deploy steps. This is the one most often missing. Having the code without knowing how it reaches production adds real time before the first release.

Third party keys. Payments, email delivery, maps, authentication. Who holds the contract and who holds the key.

A project can be taken over with any of these missing. It just adds investigation, which has to go in the quote, so knowing in advance lowers the number.

Third: the contract

Notice period and termination terms on the maintenance agreement. How many months of notice, and whether it renews automatically. Switching without checking creates a period where you pay twice.

Ownership of the work. Who holds the rights to what was produced. Contracts here are sometimes silent on this, and when they are, rights generally stay with whoever made it. That affects whether you can modify and reuse it.

Licences on the CMS, themes and plugins. Paid themes and plugins are sometimes running on the agency's licence. Those stop working the day you switch.

Send me the contract and I can walk through these three. I am not a lawyer and will not give you a legal opinion, but I can tell you what stops being technically possible.

What cannot be handed over

Being honest about this.

The reasons. Code transfers. Judgement does not. The fact that this piece of logic exists because a specific customer asked for it three years ago is information that is almost always lost.

That is the real cost of a handover. The new team does not know which parts break when touched. You either spend time discovering that, or you discover it by breaking something.

The unwritten operational rules. That this task runs on a particular day each month, that this field is corrected by hand. If anyone on your side remembers these, tell me. It is the most valuable handover document there is.

So even if your impression of the outgoing agency is poor, it is worth commissioning a handover document from them. Paying for a few hours of someone writing down why things are the way they are is much cheaper than rediscovering it. Emotionally it is unappealing. Financially it is clearly the better deal.

Should you just rebuild everything

I get asked, so here is my answer: usually no.

By the time a handover conversation is happening, the existing thing is running. Whatever is wrong with it, something that runs has reasons buried in it for why it runs. Rebuilding from scratch means rediscovering all of those.

The workable order is this. Take it over, keep it running. Use it in that state for a month or two and see where the problems actually are. Then rebuild only those parts.

If an agency proposes rebuilding everything in the first conversation, ask why. Sometimes there is a good reason. Sometimes the reason is that it is a larger contract.

When to tell the outgoing agency

That is your call and I will not tell you how to handle it.

I would suggest confirming account ownership before you have the conversation rather than after. Raising access after the news has landed can be harder than it needs to be.

Checking who owns what is ordinary administration. There is nothing odd about doing it first.

What helps at the enquiry stage

If you are considering a handover, four things let me be concrete in the first conversation.

Whose name the domain is in. Where the source code lives. The termination terms on the maintenance contract. And the single thing that is bothering you most right now.

If you do not know all four, that is fine. Not knowing is itself the first piece of work.