Website Handover: What to Demand From Your Developer or Agency

A proper website handover is the difference between owning your website and renting it from the person who built it. I have spent twelve years building WordPress sites for small businesses and agencies across Germany, the UK, the USA and Australia, and I have spent a surprising share of that time rescuing owners who discovered – usually at the worst possible moment – that they hold nothing: the domain sits in a developer’s personal account, the hosting is billed through an agency that stopped answering emails, the plugin licences die with the relationship, and the only administrator login belongs to someone who no longer picks up the phone. The site they paid thousands for is, in every practical sense, someone else’s property.

None of that is normal, and none of it is something you should accept. This guide is written from the developer’s side of the table: what a professional handover actually contains, the exact list of things you must hold when a project ends, how to verify each item in minutes rather than take anyone’s word for it, the red flags that tell you a handover is going wrong, and the recovery paths if you are already locked out of a site you paid for. Whether you are finishing a project this month or you signed off years ago and never checked, the checklist is the same – and running it takes less than an afternoon.

Table of contents

• The hostage patterns: how owners lose their own websites
• The handover checklist at a glance
• Credentials: every login, transferred properly
• Domain, DNS and hosting in your own accounts
• Ownership of code, content and images – in writing
• Plugin and theme licences: transfer or document
• Documentation and the training session
• Backups: where they live and whether you can restore
• Maintenance: agree who does what before you part
• The graceful exit test and handover red flags
• Taking over an abandoned or hostage site
• Frequently asked questions

The hostage patterns: how owners lose their own websites

Very few hostage situations start as deliberate traps. They start as convenience. The developer says “I’ll register the domain for you, it’s quicker” – and it is quicker, and three years later the domain renews on a card belonging to someone the owner has not spoken to since launch. The agency says “hosting is included in our package” – which sounds like a benefit until the owner wants to leave and learns that “included” meant “in our reseller account, under our master login, priced into a monthly fee you cannot itemise”. The freelancer keeps the only admin account “for security reasons”. Each choice is defensible on its own. Together they mean the owner controls nothing.

The patterns I see again and again when a new client asks me to take over an existing site:

• The developer owns the domain. Registered in their name, their email, their account. Legally and practically, the single most valuable digital asset the business has belongs to a contractor.
• Hosting is a black box. The owner pays a monthly fee but has no control panel login, no idea which host it is, and no way to move without the developer’s cooperation.
• No administrator access. The owner has an Editor login, or nothing at all. Every change, however small, is billable by definition.
• Licences live in the developer’s account. The page builder, the forms plugin, the SEO tool – all licensed to the developer. Leave, and the site slowly degrades as licences lapse.
• Knowledge exists in one head. No documentation, no training, no record of what the plugins do or why. Even with full access, the owner cannot operate the site.

Some of this is occasionally malicious – a retention strategy dressed up as service. Most of it is drift: nobody agreed anything at the start, so everything defaulted to whoever set it up. That is why the fix begins before the project does. When you evaluate a developer or agency, ask the handover questions in the first conversation (my guide to choosing a WordPress developer or agency covers this), and put the handover terms in the brief itself – a line in your website brief saying “all accounts in our name, full handover at completion” costs nothing and prevents almost everything below.

The handover checklist at a glance

Here is the full list I hand to clients at the end of every project, condensed into one table. Every item has a home it must end up in and a quick way to verify it – do not tick anything on trust. The rest of this guide walks through each group in detail.

The test hiding inside this table is simple: for every row, could you act alone? Not “does the developer send it when asked” – could you, tonight, with nobody’s help, log in, download, restore, renew? If the answer is yes for every row, you own your website. If it is no for any row, that row is your homework this week.

Credentials: every login, transferred properly

Start with access, because access unlocks everything else. A complete credential handover covers more accounts than most owners expect:

• WordPress: an Administrator account with your own email address – not a shared “admin” login the developer also keeps using.
• Hosting: the main control panel (cPanel, Plesk or the host’s own dashboard), plus SFTP and database credentials if they exist separately.
• Domain registrar: the account where the domain renews – often forgotten because it is touched once a year.
• Email: the admin console for your mailboxes (Google Workspace, Microsoft 365 or host-based email), which is frequently tangled up with the website setup.
• Third-party services wired into the site: the SMTP sender, the analytics property, Search Console, the newsletter tool, any payment or booking service. Each one is a login.

How they arrive matters almost as much as whether they arrive. Passwords in a Word document attached to an email are a security incident waiting to happen. The professional route is a password manager transfer: the developer shares a vault or sends items through the manager’s sharing feature, you accept them into your own vault, and then – this is the part people skip – you change every password after the handover is confirmed complete. Not because your developer is untrustworthy, but because good security does not depend on trust, and because their copy of the credentials may live on a laptop that gets stolen two years from now. While you are at it, move any two-factor authentication to your own phone or hardware key; a 2FA code that only the developer’s device can generate is just a politer version of not having the password.

One more subtlety: keep the developer’s access if you are continuing to work together – but as their own named user with an appropriate role, which you can disable in one click when the relationship ends. Shared logins make clean offboarding impossible.

Domain, DNS and hosting in your own accounts

The domain is the crown jewel. Rankings, email, brand recognition – all of it hangs off that one string of letters, and unlike a website it cannot be rebuilt from scratch if you lose it. So the rule is absolute: the domain lives in a registrar account you own, with your organisation as the registrant, renewing on your payment card, with the account recovery email pointing at an address you control. If the developer registered it “to be helpful”, ask for a registrar transfer or an account-level push to your account. Any professional will do this without friction; most registrars make it a ten-minute process.

Hosting deserves the same treatment, with one honest caveat. There are legitimate models where an agency hosts client sites on its own infrastructure – it can genuinely simplify maintenance, and I work with agencies that do it well. The difference between a service and a trap is exit terms: a good agency will state, in writing, that on request they will hand you a full copy of the site and cooperate with a migration within a defined period. If you host directly, the account and the billing are yours, and the developer gets a collaborator or team login – most serious hosts support exactly this so that nobody has to share master passwords.

DNS is the quiet third member of this group. Whoever controls DNS can point your domain anywhere, take your email offline, or hold a migration hostage without touching anything else. Know where your DNS is managed (usually the registrar or a service like Cloudflare), make sure that account is yours, and export a copy of the current records into your documentation folder. It is a two-minute job that has saved several of my takeover projects from days of archaeology.

Ownership of code, content and images – in writing

Here is the uncomfortable legal default in most jurisdictions: the person who creates a work owns the copyright unless a contract says otherwise. Paying an invoice does not automatically transfer ownership of custom code or design work. In practice this rarely explodes into a courtroom problem – but it does surface exactly when relationships sour, which is exactly when you have the least goodwill to draw on. The fix costs one paragraph.

• Custom code and theme: the contract (or a confirming email, which is far better than nothing) states that on full payment, all custom code, the theme and its assets belong to you, with no licence lock and no obligation to return for future changes.
• Content and copy: if a copywriter or the agency wrote your pages, the same sentence covers the text.
• Images: the trickiest category. Photos taken for you should be assigned to you; stock images are licensed, not owned, so ask for the licence record – which stock service, which licence tier, purchased under whose account. If stock was licensed under the agency’s account, the licence may not even cover your continued use after you part ways. A list of image sources belongs in the documentation.
• Design source files: the Figma (or XD or Sketch) file, shared to your account with edit rights, not a PDF export. The next designer you hire will thank you, and you will save real money not paying someone to reverse-engineer your own brand.
• The database and exports: your content lives in the database. Confirm you can generate a full export – most hosts and backup tools make this trivial once you have the access from the previous sections.

If your project is long finished and no contract mentioned ownership, do not panic – send a short email asking the developer to confirm in a reply that you own the delivered code and content. Most will answer yes within a day, and that email is now your paper trail.

Plugin and theme licences: transfer or document

Almost every WordPress site runs on a handful of paid components – a premium theme or page builder, a forms plugin, an SEO tool, perhaps a backup or performance plugin. And here the industry has a genuinely legitimate practice that still catches owners out: developer licences. I hold unlimited-site licences for several tools I use on client projects, as do most agencies, because it is dramatically cheaper for the client than buying every licence individually. There is nothing wrong with it – as long as it is documented and the exit is planned.

The problem arrives when you part ways. A plugin licensed under the developer’s account keeps working, but stops receiving updates – and an un-updated plugin is a slowly opening security hole and an eventual compatibility failure. Six months later something breaks or a vulnerability lands, and you discover you have no licence, no account and no idea what the renewal even costs. So the handover must include a licence inventory:

• What is installed and why: every paid plugin and theme, with one line on what it does for your site.
• Whose licence it runs on: yours (with the account details in your password manager) or the developer’s (clearly marked as such).
• What it costs to stand alone: the annual renewal price if you had to buy your own licence tomorrow. This number belongs in your budget.
• Renewal dates: so nothing silently lapses.

For licences that can be transferred, transfer them. For developer-licence tools, agree what happens on exit: typically you buy your own licence and the developer helps you switch the key – a fifteen-minute job when planned, a small crisis when discovered. If the developer resists even documenting the licences, that is not a licensing question any more; it is a red flag, and we will get to those.

Documentation and the training session

Access without knowledge is only half a handover. I have taken over sites where the owner had every password and still could not change the phone number in the footer, because nobody ever showed them where anything lived. Professional documentation does not need to be a fifty-page manual – mine is usually a short document plus a recording – but it must cover:

• How to edit each type of content: pages, posts, the homepage sections, menus, the footer, and any special content like team members, projects or products – with the actual clicks, not “use the editor”.
• The plugin list with purpose: what each plugin does and what would break without it. This single page prevents the classic disaster of a future helper deactivating “that plugin nobody recognises” that turns out to run the booking system.
• The hosting and deployment picture: where the site lives, whether a staging site exists, how caching is set up, anything unusual about the configuration.
• The image and licence inventories from the previous sections.

Then insist on a live training session – thirty to sixty minutes where the developer walks you (and whoever will actually edit the site) through the everyday tasks on the real site. And record it. The recording matters more than the call: six months later, when you need to add a team member at 9pm before a launch, you will not remember the clicks, but you can scrub through a video. Any modern meeting tool records with one click; a developer who delivers a walkthrough video without being asked is telling you something good about how they work.

A fair note on cost: documentation and training take real hours, and on a cheap fixed-price build they may not be included. That is fine – but then they should be offered as a priced option, not silently omitted. “Documentation was not in scope” is an acceptable sentence in a quote and an unacceptable surprise at handover.

Backups: where they live and whether you can restore

Ask a simple question at handover: “If the server died tonight, where is the copy of my site, and can I reach it without you?” The answer reveals a lot. Backups that exist only on the same server as the site are not backups; backups that land in the developer’s personal Dropbox are backups you do not have; a host’s “we keep backups” promise is worth checking against the host’s actual retention policy, which is often shorter than owners assume.

What a healthy setup looks like at handover:

• Automated backups run on a schedule appropriate to how often the site changes – daily for stores and busy sites, weekly for calm brochure sites.
• Copies go off-server to storage in an account you can access – your cloud storage, or the host’s backup system reachable from your own hosting login.
• You have downloaded one full backup yourself, from your own login, as part of the handover. Not watched it be downloaded – done it.
• A restore has been demonstrated once, ideally to a staging copy, so “restorable” is a fact rather than a hope.

That last point separates a real safety net from a decorative one, and it takes twenty minutes. If the current setup fails any of these tests, fix it before the developer leaves, while the person who knows the configuration is still in the room. I go deeper on schedules, tools and restore drills in my WordPress backup and disaster recovery guide – for handover purposes, the headline is: the backups must survive the relationship ending.

Maintenance: agree who does what before you part

A WordPress site is not a finished object; core, themes and plugins ship updates continuously, and unapplied updates are the number one way sites get hacked. The handover is the moment to decide – explicitly, in writing – who carries that duty, because the default is that nobody does. The three honest options:

• The developer continues on a maintenance plan: updates, backups, security monitoring, small fixes, a monthly report. This is what I offer most clients through my WordPress maintenance and security service, and for owners who do not want to think about updates it is the right answer – provided the plan is a documented service with named deliverables, not a vague retainer.
• You take it on yourself: entirely viable for a simple site, if the training covered the safe update routine and you actually do it on a schedule. Budget an hour or two a month and be honest about whether it will happen.
• A third party takes over: in which case the handover documentation is what makes their onboarding cheap instead of expensive.

Whichever you choose, write it down: who updates, how often, who is called when something breaks, and what response time is promised. The worst outcome is the assumption gap – the owner thinks the developer “looks after the site”, the developer considers the project closed, and eighteen months of missed updates later the site is compromised and both sides feel wronged. One paragraph in the handover email prevents it.

The graceful exit test and handover red flags

Everything in this guide compresses into one question, which I encourage owners to ask their developer directly and without apology: “If we part ways tomorrow, what exactly do I hold?” A professional will answer with a list – your accounts, your logins, your backups, your documentation – and the answer will match the table above. The question is not hostile; I would happily answer it for any client, and the developers worth hiring feel the same. A defensive, vague or offended response tells you the answer is “not much”, and it is better to learn that while the relationship is still cordial.

Alongside the test, watch for the red flags that show up during handovers going wrong:

• Stalling on access requests. “I’ll send it next week” repeated across a month. Sending credentials takes minutes.
• Refusing admin access “for your safety”. There are honest versions of this concern; the honest response is an admin account plus a warning, not a locked door.
• Hosting or domain transfers that are always complicated. They are almost never complicated. Complexity claims are usually leverage claims.
• Fees invented at exit: a “release fee” or “handover charge” that appeared in no contract. Charging agreed hours for documentation is fair; inventing a ransom is not.
• No written answers. Everything is a phone call, nothing is confirmable, the story shifts. Professionals write things down.
• Licence secrecy. Refusing to say what is licensed under whose account, or what it would cost you independently.

One or two of these can be sloppiness rather than malice – freelancers get busy, agencies have staff turnover. The pattern is what matters. If you are seeing three of them, stop paying for new work until the handover items are delivered; outstanding invoices are, frankly, the only leverage that reliably works, so do not spend it before the handover is complete.

Taking over an abandoned or hostage site

If you are reading this too late – the developer has vanished, or the relationship has broken down and cooperation is over – the situation is recoverable more often than owners fear. The paths, in the order I use them on takeover projects:

• The domain first. If it is registered in your business’s name but the account is unreachable, registrars have recovery processes: proof of business identity, the registrant email, payment records. If it is registered in the developer’s name, a polite formal request works surprisingly often – transferring costs them nothing, and refusing creates legal exposure most people do not want. Escalation paths (registrar dispute processes, legal letters) exist for the rest.
• Hosting second. If the hosting account is yours, reset the password and you are in. If it is the developer’s, the host generally cannot hand you the account – but you may not need it: if you have WordPress admin access, a migration plugin or your own backup gets a full copy of the site onto hosting you control, and the old account becomes irrelevant.
• WordPress access third. With hosting-level access, an administrator account can always be recovered through the database – a routine job for any WordPress developer. With no access at all, the recovery runs through domain and DNS: once you control those, you control where the site lives next.
• The worst case – no domain cooperation, no access, no backups – usually ends in a rebuild on a new domain or a recovered one, salvaging content from the live pages and web archives. It is painful and it is precisely the outcome this checklist exists to prevent; it is also, sometimes, the moment to build the site properly, with ownership done right from day one – which is exactly how I structure my custom WordPress development projects.

When a new developer takes over, expect them to run this same checklist in reverse on day one: secure the accounts, rotate every credential, take a full backup, document what is installed, and only then start changing things. That first day of housekeeping is not padding on the invoice – it is what makes sure you are never in this position again.

Want a handover you can actually verify?

I build and take over WordPress sites for owners who want to hold their own keys: full credential and licence handover as standard, documentation and a recorded walkthrough with every project, and ongoing maintenance and security plans with clearly written exit terms. Have a look at my portfolio, or tell me about your site – whether it is a new build or a rescue, I reply within 24 hours.

Frequently asked questions

What is a website handover?

A website handover is the structured transfer of everything needed to own and operate a website – credentials, domain, hosting, licences, documentation, backups and confirmed ownership of code and content – from the developer or agency to the site owner at the end of a project.

What should a website handover include?

All logins transferred via a password manager, domain and hosting in your own accounts, a licence inventory, documentation plus a recorded training session, accessible backups with a tested restore, written confirmation of ownership, and an agreed maintenance arrangement.

Who should own the domain name?

You, always – registered to your business, in your registrar account, renewing on your payment card. A developer can manage DNS as a collaborator, but the registration itself should never sit in a contractor’s account.

What if my developer refuses to hand over access?

Put the request in writing with a reasonable deadline, withhold payment for any new work until it is delivered, and use the recovery routes: registrar processes for the domain, a site copy via WordPress admin, and legal escalation as a last resort.

Do I need the design source files?

Yes – ask for the Figma or equivalent file shared to your own account with edit rights. Without it, every future designer must reverse-engineer your brand, which costs far more than asking now.

What happens to plugin licences after a handover?

Licences in your name simply continue. Tools running on the developer’s licence keep working but stop updating once you part ways – so the handover must list them, with standalone renewal costs, and plan the switch to your own keys.

How long should a website handover take?

For a cooperative developer, a few days: one session to transfer credentials and licences, one training call, and a short document. Verifying everything from your side takes an afternoon – a small price for actually owning your website.