The Website Handover Checklist Agencies Hope You Skip

Say a business decides to move its website to a new developer three years after launch. The first thing anyone asks for is the domain. The registrar login goes to an address at the old agency. The registrant contact on the record is the agency's company name. The authorisation code needed to move the domain gets sent to that contact — the one that isn't yours. A fifteen-minute administrative job turns into a negotiation with a company that has no commercial reason to hurry.

That isn't a story about a villain. It's the ordinary result of a handover that never formally happened, and it's one of the most common findings in the site audits we run. The build was fine. The launch was fine. Nobody ever sat down and moved control of the assets across.

Here's the position worth arguing about: a handover is not a file transfer at the end of a project. It's the moment control of a set of accounts changes hands, and if it isn't done deliberately — on a specific day, against a written list — it doesn't happen at all. Launch is not handover. They aren't even the same kind of event.

Studios that skip it usually aren't malicious — handover is unbilled admin at the end of a project everyone's tired of. But the effect is identical to deliberate lock-in, and three years later the difference in intent is worth nothing.

What a proper handover actually contains

Six categories. Every one is an account or a record that either sits in your name or doesn't, and there's no partial credit.

Ask for that list in writing before the contract is signed. If the site is already live, ask anyway — a studio with nothing to hide sends it back the same week.

The domain is the item that ends businesses

Almost everything else is a recoverable inconvenience. Lose hosting and you redeploy. Lose the CMS and you rebuild the admin. Lose the domain and your email stops, your rankings evaporate and every business card in the office is wrong.

Two details specific to Australia. A .com.au isn't property the way people assume — it's licensed under the rules set by auDA, and the licence carries an Australian presence requirement tied to a specific entity. Whose ABN sits behind it is a real question with a real answer, and not always the one the business expects.

Second, the registrant contact controls the transfer. Move a domain between registrars and the authorisation code goes to whoever holds that record. If the agency put their own details there — often for the reasonable operational reason that they handled DNS — they hold the keys, whether or not anyone intended it.

So the check is specific. Log into the registrar yourself. Look at the registrant name, the registrant email, the ABN and the expiry date. Three of those four should reference your business. If any names the agency, fix it first, while everyone is still friendly.

The best time to sort out domain ownership is the week you're happiest with your agency. The worst time is the week you're not.

Every account in your own name, not theirs

The pattern to insist on is the same everywhere: you own the account, the agency is invited into it. Not the reverse. It costs nothing at setup and it's the whole difference between an amicable exit and a hostage situation.

Hosting is where this gets resisted. Plenty of studios genuinely prefer running infrastructure on their own accounts, and there's a defensible argument about consistency. Fine. The compromise that works is an account created under your billing details on day one, operated by the agency as a collaborator. If a studio won't do that, you've learned something useful about how the relationship ends. We've written about what platform lock-in actually costs once it's allowed to compound.

Measurement deserves attention because the damage is silent. Google Search Console treats verified ownership and user access as different things: an owner can add and remove users, and a user can be removed by an owner. If the agency verified the property and added you as a user, they can revoke you. Verification runs through a DNS record or a file on the server — another reason the domain sits at the top of the list.

Analytics is worse, because the history can't be recreated. Three years of traffic, conversion and channel data lives inside a property attached to somebody's Google account. If that account belongs to a contractor who stops answering emails, the history is gone. Not delayed. Gone.

The same principle covers the rest of the estate: Google Business Profile, the DNS provider if it's separate from the registrar, the platform wired to your contact forms, the payment gateway on an ecommerce build, any uptime monitoring. Each is either yours or it's a future problem.

Code, licences, and the deployment path written down

Three items that don't feel urgent at launch and become urgent at exactly the wrong moment.

The repository. Source code belongs in a repository owned by your organisation account with commit history intact, not a final zip attached to an email. History matters because it's the only documentation of intent most projects get. What ownership of that code means contractually is a separate question worth reading up on before signing: the clauses that quietly keep your website with the agency are usually four lines long and buried on page seven.

The licence register. Nobody hands this over. Commercial webfonts are licensed on terms — pageview tiers, named domains, or a subscription living inside a designer's account that stops working when it lapses. Stock images are licensed to the purchasing account and frequently aren't transferable, so the photo on your homepage may be licensed to a company you no longer work with. Premium plugins carry keys tied to a site and an annual renewal. Ask for a plain document: every item, the entity named on the licence, the renewal date, the cost.

The deployment path. Write down how a change gets from a laptop to the live site. Which branch deploys, to which service, the build command, where environment variables and API keys are stored, and how to roll back. Two pages is enough. It's the difference between a new developer being productive on day one and burning a paid week on plumbing — and the most valuable page in the pack if your developer disappears.

Red flags in the last fortnight of a build

By the time you're two weeks out, the signals are audible if you know what they sound like.

"We'll just manage all that for you." Management is a service, and a fine one to buy. Ownership is not the same thing, and the sentence blurs them. The correct answer is: manage it, on our accounts.

"You don't need access to the code." A custom build you paid for and can't read is a rental with a purchase price.

Credentials arriving in a plain email. Beyond the security problem, those messages sit in mail archives forever and get forwarded to people who leave.

Hosting billed at a markup with no underlying invoice. Ask what the account actually costs. Reasonable studios pass it through or bundle it transparently.

No written response to a handover checklist. "All good, we'll sort it after launch" is not a plan. Final payment is the only real pressure you have, and it disappears the moment you make it.

FAQ

What should a web agency hand over at the end of a project?

Six things: control of the domain with your entity as registrant, a hosting account in your name, source code in a repository you own, an administrator account on the CMS that you created yourself, ownership-level access to analytics and Search Console, and a written record of every font, image and plugin licence on the site. Alongside those, a short document describing how the site gets deployed and how to roll a change back. Anything less and you have a website you're renting.

Who should own the domain name for my business website?

Your business entity, always. The registrant contact should name your company and your ABN, and the registrar account should be reachable by at least two people inside the business. Agencies and developers belong there as technical contacts or account collaborators, never as the registrant.

Is it safe to receive website passwords by email?

No, and it's a reliable signal the handover wasn't planned. Email and chat archives keep credentials indefinitely, get searched, and outlive the staff who received them. Use a password manager such as 1Password and share a vault — or better, have each person create their own account and set their own password, so there's no shared secret to leak. Any credential that has travelled through email should be rotated during handover.

What if my website is already live and the handover never happened?

Work through the handover items in order: domain first, then hosting, measurement, source code and licences. The domain leads because losing it takes your email and rankings down with it; analytics ownership comes early because lost history can never be rebuilt. Most of it can be corrected without touching the live site, and a cooperative developer will help. The awkward conversation is short; the alternative is discovering the problem mid-emergency.

Does a website handover cost extra?

It shouldn't. Transferring accounts and writing a two-page deployment note is a few hours at the end of a project that already cost thousands. On a custom build starting at $8,000 AUD, treating handover as a chargeable extra is a pricing decision worth questioning out loud before you sign.

Running the handover, and what to do if you've already missed it

Book an hour, screen shared, with whoever will hold these accounts internally — ideally two people, because one resignation shouldn't reset your access to everything.

Work down the six items in order. For each one, don't accept a description of access: log in yourself while the agency watches. Change the password on the spot. Turn on two-factor authentication and store the recovery codes somewhere the business controls, not an individual's phone. Confirm your role reads "owner" or "administrator", not "user" or "editor". Then have the agency remove any account of theirs you no longer need, and note the ones you're deliberately keeping and why.

Finish with three documents: the licence register, the deployment note, and a one-page list of every account, its login URL, and who inside the business holds it. Store all three somewhere that isn't a single laptop. When a rebrand or rebuild comes along later, that pack is also what makes a clean handover between studios possible rather than painful.

If the site is already live and none of this exists, the order is domain, hosting, measurement, code, licences — and the time is this month, while everyone is still on speaking terms. An afternoon of admin now, against a rebuild you didn't budget for later.

Every custom build we do ships with this pack as standard, because a site you can't take somewhere else isn't really yours. If you're mid-project with another studio and want a second opinion on what you've been given, book 20 minutes and bring the list — we'll tell you what's missing, whether or not you ever work with us.