Motta Industries Blog

The end of a website project usually comes with a launch announcement, a final invoice and a friendly email. What it often lacks is the material a business needs to keep the site running without the person who built it. Months later, when a plugin breaks, a staff member leaves or the business wants to switch providers, the owner discovers that the passwords, settings and instructions lived only in the developer’s head.

A handoff package fixes that. It is a set of documents and access records that should arrive with every finished project, whether the work came from an agency, a freelancer or an in-house team. This guide explains what belongs in it, why each piece matters and how to ask for it before the project starts.

Why handoff documentation matters

Websites depend on more parts than most owners realize: a domain name, DNS records, hosting, a content management system, plugins or extensions, payment and email services, analytics, and the code and design files themselves. Each one has an account, a login and settings someone chose for a reason.

The National Institute of Standards and Technology’s Cybersecurity Framework 2.0, published February 26, 2024, puts this kind of record-keeping near the center of managing risk. Its Identify function calls for maintaining inventories of hardware, software, services and systems, inventories of services provided by suppliers, and inventories of data. It also says assets should be managed throughout their life cycles and that backups should be created, protected, maintained and tested. The framework was written for organizations of every size, and its logic applies neatly to a small business website: you cannot protect or move what you have not written down.

Plan the handoff before the work begins

The best time to ask for documentation is in the proposal, not at launch. Once a project is finished and paid for, a developer has less reason to spend hours writing instructions.

The Cybersecurity Framework addresses this in its section on supply chain risk. It recommends that requirements for managing cybersecurity risk be written into contracts and other agreements with suppliers, and that plans include provisions for activities after a partnership or service agreement ends. For a website, that means the contract should list the handoff package as a deliverable, with a due date and a clear statement of who owns what.

The Cybersecurity and Infrastructure Security Agency makes a similar point in its Secure by Demand Guide, published in August 2024. The guide was written for organizations buying software, but its framing fits website projects well: customers should explicitly demand security as part of procurement, and they can build product security expectations into questions before purchase, contract language during purchase and ongoing assessment afterward.

What belongs in the package

A complete handoff package has five parts, described below. The exact format matters less than completeness: a shared folder of plain documents works as well as a polished binder.

Part 1: An account and access inventory

A list of every service the site uses, with the account owner, login email, billing contact and renewal date. At minimum:

• Domain registrar
• DNS provider, if different
• Hosting or server provider
• Content management system administrator accounts
• Email sending services used by forms
• Payment processor and any ecommerce extensions
• Analytics, Search Console and tag management
• Third-party tools such as booking, chat or newsletter services

Each account should be registered to a business email address the owner controls, not the developer’s personal address. Passwords should be shared through a password manager, never in a plain email or spreadsheet. The CISA guide stresses multi-factor authentication and moving away from default passwords, so confirm that every important account has multi-factor authentication turned on and that no default credentials remain.

Part 2: A software and component list

A record of the content management system version, theme, plugins, custom code and any external libraries, with notes on which are free, which are paid and when licenses renew. The Secure by Demand guide asks software makers for a software bill of materials that lists third-party components. A website project does not need a formal one, but a plain list serves the same purpose. When a security update appears, you can check in minutes whether it affects your site.

Part 3: Configuration and hosting notes

How the site is set up: server type and version, caching, security settings, scheduled tasks, form routing and email delivery settings, and any special configuration a future developer would need to know. Include a copy of current DNS records. These details are the ones most often lost when a site changes hands.

Part 4: Backups and recovery instructions

Where backups are stored, how often they run, how long they are kept and step-by-step instructions for restoring the site. The Cybersecurity Framework’s guidance that backups be tested matters here. A backup that has never been restored is a hope, not a plan. Ask the developer to demonstrate one restore to a staging site before handoff.

Part 5: Editing guides and ownership records

Short instructions, with screenshots, for the tasks your team does most often: adding a page, updating a menu, replacing an image, editing a form or posting to the blog. Add a written statement confirming that the business owns the domain, content, design files and custom code, along with copies of any license terms for paid components.

Plan for future moves

Even a site you love will eventually move: to a new host, a new domain or a new structure. Google’s June 2014 post, Making site moves easier, describes two broad kinds of move. A move without URL changes swaps the underlying infrastructure, such as a different hosting provider, while the addresses stay the same. A move with URL changes alters the protocol, the domain name or the URL paths. The post also notes that site owners have implemented moves incorrectly or skipped steps that would have made success far more likely.

A good handoff package makes either kind of move easier. A list of every page URL, any existing redirects and the sitemap location gives the next developer a map to work from. Without it, redirects get missed and visitors land on error pages.

Common gaps to watch for

Even developers who provide documentation tend to miss the same few items.

Renewal dates. Domains, certificates, paid plugins and hosting all renew on different schedules. A missed domain renewal can take a site offline and, in the worst case, let someone else register the name.

Email delivery settings. Contact forms often rely on a separate email service or special DNS records. When those details are missing, forms quietly stop sending messages and nobody notices for weeks.

Custom code locations. Small changes added through a theme file or a code snippet plugin are easy to forget and easy to overwrite during an update.

Third-party scripts. Tracking tags, chat widgets and embedded booking tools each add an account and a dependency. List them all, along with who at the business can sign in.

If you never received a handoff package

Many owners reading this already have a site with no documentation. The fix is to build the package yourself, ideally with help from your current provider.

Start with the accounts. Find the registrar, host and content management system logins, and make sure each one is tied to a business email you control. Turn on multi-factor authentication. Then list the plugins and theme from the admin dashboard, note the versions and check which ones have paid licenses.

Next, confirm backups exist and ask someone to test a restore. Finally, write down the five tasks your team does most often and how to do them. A partial package built in an afternoon is far better than none, and it can be completed gradually.

Questions to ask your developer

Use these questions in the proposal stage:

• Will a written handoff package be included, and what will it contain?
• Will all accounts be created in our business name and email?
• How will passwords be transferred?
• Which components require paid licenses, and who holds them?
• Will you show us a backup restore before handoff?
• Who owns the custom code and design files?
• What support is included after launch, and for how long?

A developer who answers these clearly is usually one who has handed off sites before. Hesitation on ownership is a clear warning sign.

Decide who holds the keys

Before handoff, name at least two people in the business who will have administrator access to the most important accounts. One person is a single point of failure: if they leave, fall ill or lose their phone, the business is locked out of its own site.

Give the developer a lower level of access once the project ends, enough to provide support if you have a maintenance agreement, and remove it entirely if you do not. Keep a log of who has access and when it was reviewed.

Keep the package current

Documentation goes stale. Plugins change, staff leave and new tools get added. Assign someone in the business to own the package, and review it at least twice a year and whenever a significant change happens. The Cybersecurity Framework’s emphasis on managing assets throughout their life cycles is a reminder that the inventory is a living record, not a one-time deliverable.

Store the package somewhere secure that more than one trusted person can reach, separate from the website itself. If the site goes down, the instructions for fixing it should not be on the same server.

A fictional example

Consider a dental practice whose website was built by a freelancer who has since moved on. When a booking plugin stops working, the office manager finds that the hosting account is in the freelancer’s name, the plugin license expired a year ago and nobody knows how forms send email.

Recovering access takes two weeks. The practice’s next project starts with a contract that lists a handoff package as a deliverable. At launch, the new developer delivers an account inventory, a plugin list with renewal dates, hosting and DNS notes, a recorded backup restore and a short editing guide. A year later, when the practice adds online forms for new patients, the work starts in hours instead of days. This example is fictional and meant only to show how the pieces fit together.

Making handoff part of every project

A website is a business asset, and like any asset it should come with records. Asking for a handoff package is not a sign of distrust. It is how a business protects itself and makes future work faster and less expensive.

If you are planning a new project, our services include documented handoffs as a standard part of delivery. Learn why business owners choose Motta Industries for long-term website care, or contact us to review what your current site is missing.