The Website Handover Checklist: Everything Your Developer Should Give You When the Project Ends

Your web designer just told you the project is “done.” They’re ready to hand it over. You’re excited — but also a little nervous. What exactly should they be giving you? How do you know you’re getting everything you need? And what happens six months from now when you need to make a change and your designer has moved on to other projects?

The handover phase is one of the most overlooked parts of any web design project — and it’s where a shocking number of business owners get burned. They receive a login, a quick walkthrough, and a “good luck.” Then, months later, they discover they don’t have access to their own source code, their SSL certificate is about to expire and nobody knows how to renew it, or their designer’s hosting account is the only place their website actually lives.

According to research compiled by Sweor, 75% of users judge a business’s credibility based on its website design. If your site goes down because of a botched handover or expired credentials nobody tracked, that credibility evaporates overnight.

This checklist exists so that doesn’t happen to you. Whether your project is wrapping up now or you’re planning ahead for a future build, bookmark this page. It covers everything your developer should hand over — and everything you should demand if they don’t offer it first.

TL;DR — The Non-Negotiable Handover Items

At minimum, you must walk away with: full admin access to your domain registrar, hosting control panel, CMS (WordPress, etc.), and all analytics platforms. You need a complete backup of your website files and database stored somewhere you control. You need all design source files (Figma, Photoshop, Illustrator). You need documentation covering how to update content, where things are hosted, and what third-party services the site depends on. You need all API keys and third-party credentials transferred to accounts you own. And you need a clear understanding of what ongoing maintenance is required and who’s responsible for it. If your developer pushes back on any of these, that’s a red flag — and you’ll want to know about other warning signs that should make you reconsider the relationship.

Section 1: Access Credentials and Logins

This is the foundation of everything. Without proper access, you don’t truly own your website — you’re renting it from your developer.

Domain registrar login. Where your domain name is registered (GoDaddy, Namecheap, Cloudflare, Google Domains). You need full admin access to the account where your domain lives — not just the ability to log in. Ideally, the domain should be registered under your own account with your own email and payment method. If it’s under your developer’s account, transferring it to yours should be part of the handover. This is the single most important asset — without domain control, you can lose your entire web presence.

Hosting control panel. Whether it’s cPanel, Plesk, Vercel, Netlify, AWS, DigitalOcean, or any other platform — you need independent admin access. You should be able to manage files, databases, email, and SSL certificates without going through your developer. Check that the hosting account is billed to your own payment method. If the hosting is in your designer’s name, your site is effectively a tenant on someone else’s property.

CMS admin credentials. If your site runs on WordPress, Shopify, Webflow, or any other content management system, you need the top-level administrator account. Not an editor role. Not a contributor. The full admin with the ability to install plugins, change themes, manage users, and export data. Your developer can keep a separate admin account for maintenance purposes, but yours should be the primary.

Email accounts. If your developer set up business email through your hosting or a service like Google Workspace or Microsoft 365, you need the admin credentials for the email platform — not just your individual mailbox login. This ensures you can add or remove email accounts as your team changes.

Analytics and search tools. Google Analytics, Google Search Console, Google Tag Manager, Facebook Pixel, any tracking or analytics platforms. These should be set up under your own Google/business account. If your developer set them up under their account, they need to transfer ownership (not just share access). Shared access can be revoked. Ownership can’t.

DNS records documentation. Even if you have domain access, you should receive a document explaining your current DNS configuration — what each record does, where your email is pointed, whether you’re using a CDN, and what would break if records were changed. DNS is the invisible plumbing of your website; understanding it prevents accidental outages.

Section 2: Website Files and Code

Your website is made of code, and you should have an independent copy of all of it.

Complete source code. Every file that makes your website run — HTML, CSS, JavaScript, PHP, Python, whatever your site is built with. If the project uses version control (Git), you should have full access to the repository with complete commit history. If there’s no version control (a red flag in itself for custom work), you need a downloadable archive of all files.

Database export. If your site uses a database (WordPress sites use MySQL, for example), you need a full database export. This contains all your content, user data, settings, and configuration. Without it, your site’s files alone won’t be enough to rebuild if something goes wrong.

Media files. Every image, video, PDF, and downloadable file on your website. These are often stored separately from the code and can be surprisingly large. Make sure you have original, full-resolution versions — not just the compressed versions displayed on the site.

Design source files. The original design files — Figma projects, Adobe Photoshop or Illustrator files, Sketch files, whatever your designer used. These are essential if you ever need to create new pages that match the existing design, update graphics, or hand the project to a different designer in the future. Without source files, even simple design changes may require starting from scratch.

Custom fonts and licensed assets. If your website uses premium fonts or licensed stock photography, you need to know which licenses were purchased, under whose name, and whether they need to be renewed. Some font licenses are tied to a specific domain or number of pageviews — confirm you’re covered.

Environment and build documentation. If your site uses a build process (common with modern frameworks like Next.js, React, or Vue), you need documentation on how to set up the development environment, install dependencies, run the build process, and deploy changes. Without this, even a skilled developer would need to reverse-engineer your setup before making changes.

Section 3: Third-Party Services and Integrations

Modern websites rarely stand alone. They connect to payment processors, email marketing platforms, CRMs, booking systems, and more. Every one of these connections needs to be documented and transferred.

Payment processing. Stripe, PayPal, Square — whichever payment gateway your site uses. The account should be in your business name with your banking information. API keys should be generated under your account, not your developer’s.

Email marketing. Mailchimp, ConvertKit, ActiveCampaign, etc. Make sure the account is in your name and you have admin access. Your email subscriber list is one of your most valuable business assets — it should be fully under your control.

CRM and business tools. HubSpot, Salesforce, Zoho, or whatever CRM your website feeds into. Ensure the integration is documented and the API credentials are accessible to you.

CDN and performance services. If your site uses Cloudflare, a CDN, or any caching service, you need to know about it and have access to manage it. These services can affect your site’s availability if they lapse or are misconfigured.

SSL certificate. Know where your SSL certificate comes from (Let’s Encrypt, Cloudflare, your hosting provider) and when it expires. An expired SSL certificate means browsers will warn visitors your site is “Not Secure” — which can devastate both traffic and trust.

Social media and directory integrations. If your website connects to your Google Business Profile, social media accounts, or industry directories, document these connections. Some integrations use API keys that expire or need periodic renewal.

Section 4: Documentation

Good documentation is what separates a professional handover from a “good luck, figure it out” handoff. It’s also the thing most commonly skipped.

Technical documentation. A document or README file that explains: how the site is structured, what technologies it uses, how to set up a local development environment, how to deploy changes, and any quirks or workarounds the developer implemented. This doesn’t need to be a novel — a clear, well-organized 2–3 page document is usually sufficient. Without it, your next developer will spend their first 5–10 billable hours just figuring out how your site works.

Content management guide. A walkthrough — ideally with screenshots or a short video — showing you how to perform common tasks: updating page content, adding blog posts, changing images, managing navigation menus, and moderating comments or form submissions. This is especially important if you’ll be managing day-to-day content yourself without developer support.

Maintenance schedule. What needs to happen on a regular basis to keep your site healthy? WordPress core updates, plugin updates, security patches, backup verification, SSL renewal, domain renewal. A simple calendar or checklist of what to do monthly, quarterly, and annually can prevent small oversights from becoming expensive emergencies.

Emergency procedures. What do you do if the site goes down? Who do you contact? Is there a monitoring service in place? Where are the backups stored, and how do you restore from one? Having this documented before you need it is the difference between a 30-minute fix and a 3-day panic.

SEO and analytics setup notes. How is tracking configured? What goals or conversions are set up in Google Analytics? Are there any custom event tracking scripts? What’s the sitemap URL? Is there a robots.txt file with special rules? If you ever need to switch web designers, this documentation makes the SEO transition dramatically smoother.

Section 5: Ongoing Support and Warranties

The handover isn’t the end of the relationship — or at least, it shouldn’t be.

Bug fix warranty period. Most professional developers offer a warranty period (typically 30–90 days) after launch during which they’ll fix bugs at no additional cost. Make sure this is defined in writing — what counts as a bug versus a change request, how quickly they’ll respond, and what happens after the warranty expires. This should be spelled out in your web design contract.

Ongoing maintenance agreement. If your developer is offering ongoing maintenance (updates, security monitoring, backups), get the terms in writing. What’s included? What costs extra? What’s the response time? Understanding the real costs of website maintenance prevents sticker shock down the road.

Transition plan if the relationship ends. This might feel awkward to discuss when you’ve just finished a successful project, but it’s essential. If you part ways in the future, what happens? Will they provide a full handover as described in this article? Is there a knowledge transfer period? Setting these expectations now, while the relationship is strong, protects both parties.

Training for your team. If multiple people in your organization will be using the website, ask for a training session (live or recorded). A 60-minute walkthrough can save dozens of hours of confusion and support requests over the coming months. Good developers are happy to do this because it reduces the number of “how do I…?” emails they’ll receive later.

When to Ask for the Handover — Timing Matters

The best time to discuss handover expectations is before the project begins. Include it in your initial conversations and make sure it’s referenced in the contract. Don’t wait until launch day to ask, “So what am I getting?”

A professional designer will appreciate the question because it shows you’re organized and serious about the project. If they seem uncomfortable or evasive about handing over full access, that’s a warning sign worth paying attention to — and it’s worth understanding whether you’re actually getting custom work or a template with limited transferability.

For large projects, consider scheduling a formal handover meeting — separate from the launch — dedicated entirely to walking through every item on this checklist. Record the meeting so you can reference it later.

Frequently Asked Questions

What if my developer refuses to hand over source files?
This depends on your contract. If your agreement specifies that you own the deliverables (which it should), they’re legally obligated to provide them. If there’s no contract, default copyright law may assign ownership to the creator — which is why written agreements matter so much. If you’re in a dispute, a formal written request followed by a lawyer’s letter usually resolves things.

Should my developer give me their development environment?
Not their personal environment, but they should give you everything needed to replicate it. That means a README with setup instructions, a list of dependencies (with versions), and any configuration files required to run the project locally. A competent developer should be able to package this up in under an hour.

Do I need all of this for a simple brochure website?
Yes, though the specifics will be simpler. Even a basic 5-page website needs domain access, hosting access, CMS login, a backup, and basic documentation. The complexity of the checklist scales with the complexity of the site — but the core items are non-negotiable regardless of project size.

What if my site is on a website builder like Squarespace or Wix?
The handover is simpler (no source code to transfer, no database exports), but you still need admin ownership of the account, access to domain settings, analytics, and any integrations. The biggest risk with builders is that the account is in your developer’s name — make sure it’s in yours.

When should I ask for the handover checklist — before or after the project?
Before. Ideally, discuss handover expectations during the contract phase. A professional designer will appreciate the question because it shows you’re organized and serious. If they seem uncomfortable or evasive about handing over full access, consider that a warning sign.

What if my developer has gone silent and I never received a handover?
This is unfortunately common. If your designer has disappeared mid-project, you’ll need to take a different approach — securing what you can access independently and potentially engaging a new developer to recover and rebuild.

Take Ownership of Your Website — Literally

A professional web designer should want you to own everything about your website. They should proactively offer documentation, credentials, and source files — not make you chase them. If your current or future designer treats the handover as an afterthought, it’s worth asking why.

Your website is a business asset. Treat it like one. Make sure you own it fully, understand how it works, and have everything you need to maintain or transition it independently.

If you’re about to start a web project and want to make sure the handover is built into the process from day one, talk to Studio Aurora. We believe full transparency and ownership aren’t extras — they’re the baseline. Every client receives full access to everything from day one, complete documentation, and a structured handover that leaves nothing to chance.