When an IT support provider leaves a project or hands over responsibility to someone new, the difference between a smooth transition and weeks of avoidable chaos often comes down to one thing: documentation. A handover document that covers what was built, how it works, who owns what, and what to do when things break gives the next person a genuine starting point.
Without it, even straightforward tasks can take hours of reverse-engineering. The person inheriting the setup spends their first days chasing access credentials, figuring out why the booking system connects to the database the way it does, and discovering that the SSL certificate renews through an account nobody can find. This guide covers what a practical IT support handover document should include, with specific sections UK small businesses, agencies, and growing companies can adapt to their own setup.
Why IT handover documentation matters more than most businesses expect
A handover document is not a luxury for large enterprises. If your business runs on a custom-built website, a configured server, a booking system, or any combination of third-party tools that someone set up and manages, you have an IT dependency. When that person leaves, changes provider, or simply needs to hand off day-to-day responsibility, the absence of written context creates real risk.
Practical risks include lost access credentials that lock out the business, undocumented custom code that breaks silently, forgotten renewal dates for domains or SSL certificates, and server configurations that nobody can replicate. These are not edge cases. They are the normal result of relying on undocumented institutional knowledge. A written handover document is essentially business insurance for your technical setup.
The risk becomes more acute when the departing person built the system over time, making decisions in response to specific problems without writing down why those decisions were made. The new person faces not just an unfamiliar system, but a system where the reasoning behind it is invisible. This is why a handover document should include context as well as configuration.
What an IT support handover document should actually contain
There is no single universal template that fits every business. The right handover document depends on what your IT infrastructure includes. However, most useful handover documents share a recognisable set of sections. Below is a practical breakdown of what to include, with notes on why each section matters.
1. System overview and architecture summary
Start with a plain-language description of how the technical setup fits together. This section should answer the question "what do we actually have running?" for someone who has never seen the system before.
Include a simple diagram or list showing the main components, what each one does, and how they connect. For example:
- Primary website hosted on a VPS with a LAMP stack
- Email handled through Google Workspace
- Domain DNS managed through Cloudflare
- Database running on the same server as the application
This overview does not need to be exhaustive. It needs to be accurate enough that the reader understands the basic structure before diving into the details. A new IT provider reading this section should be able to draw a rough architecture diagram without making assumptions.
2. Hosting and server access details
This section records where things live and how to get access. Include the hosting provider, server type, and control panel URL if applicable. For server access, record:
- SSH connection details or remote desktop access method
- The port used for SSH access if it is non-standard
- Where credentials are stored securely, rather than writing them directly in the document
For websites running on shared hosting or managed servers, note the control panel login and any relevant server-level settings that affect how the site works. If your site runs on PHP, include which PHP version is currently active, because mixing incompatible versions is a common cause of unexpected errors after a handover. This is one of the first things an incoming support provider will check, and having it documented avoids a diagnostic detour.
For server-level access, note whether the hosting uses a custom control panel, cPanel, Plesk, or a provider-specific dashboard. Each has a different troubleshooting workflow when something goes wrong, and knowing which interface to log into is fundamental.
3. Domain names and DNS configuration
Domains are easy to forget until they expire or transfer unexpectedly. Record each domain name, the registrar, renewal date, and what DNS records are configured and why. Include the key DNS entries such as:
- A records pointing to server IPs
- MX records for email routing
- CNAME records for subdomains and CDN configuration
- TXT records for SPF, DKIM, and domain verification
For businesses using custom email, SMTP configuration details matter here. Record the mail server hostname, authentication method, and which ports are in use, particularly if you are running your own mail server rather than relying on a third-party provider.
If DNS changes are made without understanding what each record does, email deliverability problems and website downtime are common results. A clear DNS section prevents both. When documenting DNS, include a brief note on why each record exists. For example, a CNAME pointing a subdomain to a CDN is straightforward to understand on its own, but knowing that it was added specifically to handle a spike in traffic six months ago gives useful context about the system behaviour.
4. Website and application specifics
For websites built in WordPress or custom PHP applications, document the specific details that someone inheriting the project will need immediately. This includes:
- CMS version and any custom modifications made to the core installation
- List of active plugins or extensions with their versions and purpose
- Custom code additions, including where custom PHP functions are stored
- Database name, location, and any non-standard table structures
- Admin area URL and any access restrictions such as IP allowlisting
For custom applications, document the framework used, the repository location, deployment process, and any environment variables or API keys the application requires. If there are background jobs or scheduled tasks, list them with their frequency and what they do.
Understanding how the IT support experience behind a project shapes the documentation quality matters here. Someone with a background in technical troubleshooting will typically document edge cases and known failure modes that a less experienced provider might not think to record. When reviewing an existing handover, look for whether the document captures not just what was built, but how it behaves under pressure.
5. Third-party services and integrations
Most small business IT setups involve multiple third-party services connected together. Include a list of every external service that is integrated with your systems, including:
- Payment gateways and how transactions are processed
- Email marketing platforms and their connection method
- CRM or accounting software integrations
- API keys and webhooks in use, with a note on whether they are live or in test mode
- SSL certificate details, including provider and renewal process
For each service, note who owns the account and where renewal or billing is handled. Service accounts owned by a departing IT provider are a surprisingly common source of business disruption. If the account belongs to the provider rather than the client, transferring ownership should be part of the handover process before the relationship ends.
6. User accounts and access management
Document who has access to what, and where those access rights are managed. This covers server logins, hosting accounts, domain registrars, email accounts, and any admin panels. Include the account type for each user rather than listing every individual, particularly for larger teams where individual account lists become outdated quickly.
If you use Google Workspace or Microsoft 365 for business email, note the admin console location and who holds the super-admin role. This is critical for security and continuity, especially if the departing IT person set up the initial configuration. The super-admin account is often the hardest to recover if it is lost, and in many cases it is tied to a personal email address that the business does not control.
7. Known issues and active problems
One of the most useful sections in any handover document is an honest record of what is not working properly. Include issues that are being managed rather than fixed, workarounds in place, and any known limitations of the current setup. This prevents the incoming support provider from spending time investigating issues that are already documented.
For example, a note might read:
- Contact form submissions occasionally fail during high-traffic periods due to server memory limits
- The legacy booking system requires a manual restart every Monday morning
- One plugin is currently disabled pending a compatibility review with the upcoming PHP version update
Documenting known issues honestly sets realistic expectations and gives the next IT provider a clear starting point for prioritising improvements. It also protects the business from discovering too late that a workaround was masking a problem that needed more urgent attention.
8. Support contacts and escalation paths
List the key contacts for every service in the stack. Include provider support URLs, ticket systems, and direct contact details where relevant. If specific issues need to go to specific providers, document that escalation path clearly.
For managed services, note the support tier, response time expectations, and any contract details. If you have a support retainer or service agreement, reference it here and include a link or note on where the full agreement is stored. For a related practical guide, see Website Support Retainers: What Small Businesses Should Actually Expect.
When evaluating IT support options, understanding what a website support retainer covers is practical. Knowing exactly what support entitlements exist and how to access them makes the handover more useful from day one.
Common mistakes when creating IT handover documentation
Writing a handover document is straightforward in principle, but there are several mistakes that make them less useful than they should be.
Including credentials directly in the document is a security risk that should be avoided. Instead, store sensitive details separately and reference where they are kept. Password managers, encrypted documents, or secure note systems are better homes for login information than a shared document. If the handover document is compromised, having live credentials inside it creates an immediate security incident on top of the transition disruption.
Writing vague descriptions is another common problem. Phrases like "server configured for performance" or "email set up correctly" tell the next provider nothing useful. Be specific. Name the server specifications, list the exact email authentication records, describe what was optimised and how it was measured. The goal is to answer the question "what do we have and why?" before the reader has to ask.
Out-of-date documents are nearly as bad as missing ones. A handover document that was written six months ago and never updated will mislead rather than help. Build a review into your regular IT maintenance schedule. Reviewing the document quarterly or whenever a significant change is made keeps it accurate. One practical approach is to treat the handover document as part of the change management process: every time a service is added, removed, or modified, the document is updated before the change is marked complete.
Focusing only on current state and not including history is a narrower mistake. Knowing why something was set up a certain way is often as important as knowing what the current state is. A short note on the reason for a particular decision helps the next person avoid undoing work that was done for a specific business reason. For instance, noting that a particular plugin was disabled because it caused database timeouts under specific conditions prevents someone from re-enabling it as a quick fix without understanding the consequence.
How to structure the handover for maximum usability
A handover document that is comprehensive but poorly structured is hard to use under pressure. When something is down or a deadline is tight, the person reading the document needs to find what they need quickly.
Use a clear table of contents at the start. Number each section and subsection so that references within the document can point to specific sections. Keep each section focused on a single topic. Mixing server details with email configuration details in the same section makes both harder to find.
For longer documents, consider separating critical information from detailed reference material. Put the most time-sensitive information, such as access credentials and immediate troubleshooting steps, in the first sections. Move detailed logs, change histories, and configuration minutiae into appendices. A new support provider who needs to restore a broken website does not need to read through three years of change logs first.
Version control the document itself. Track when it was last updated and what changed. A changelog at the end of the document, or a version history table, helps anyone reviewing the document understand whether it reflects the current state of the system. Version control is also useful when multiple people contribute to the document over time, as it makes it easier to identify who made which changes and why.
When a freelance IT specialist can help with handover documentation
Some businesses have the internal capacity to document their own IT setup. Others benefit from bringing in someone external to review the setup, identify gaps, and write the handover document from scratch. This is particularly useful when the current setup has grown organically without a clear record of decisions made along the way.
An IT specialist with experience across website development, server management, and technical support can map an existing setup, identify undocumented dependencies, and produce a handover document that covers both the current state and the practical knowledge needed to maintain it. This kind of review also often surfaces small problems before they become serious ones, such as SSL certificates close to renewal or hosting accounts that are about to auto-renew at a higher price. For a related practical guide, see How IT Support Experience Improves Web Development Projects.
If you are comparing IT support options, the quality of documentation a provider produces is itself a signal of their professionalism. Providers who document their work clearly tend to manage systems more carefully overall. When reviewing a potential IT support provider, asking to see a sample of their handover documentation gives you a practical view of how they work, not just how they describe their approach.
For UK small businesses that rely on a handful of technical tools, a website, and server access, the cost of producing a proper handover document is usually modest compared to the cost of extended downtime or emergency recovery if something goes wrong without documentation. A single incident where nobody knows how to restore a backup or where a critical service is hosted can cost more in lost revenue and emergency callout fees than weeks of proactive documentation work.
Supporting your handover with runbooks and knowledge base articles
A handover document covers the "what and where" of your IT setup. Runbooks cover the "how to fix" when something goes wrong. Separating these two concerns keeps both documents more useful. The handover document tells someone where to look. Runbooks tell them what to do once they are looking.
Building an IT support runbook library alongside your handover documentation creates a more complete knowledge base for your technical setup. Each runbook can cover a specific scenario, such as how to restart a service, how to restore a backup, or how to investigate slow website performance.
Runbooks and handover documentation together support knowledge management across your IT operations. Capturing critical knowledge before any transition happens is one of the most practical steps a small business can take to protect itself from technical disruption. The effort invested in documentation pays back every time someone needs to work on the system unexpectedly.
IT handover documentation as part of a service agreement
If you are hiring an IT support provider, ask about handover documentation before you start. The best time to agree on documentation standards is at the beginning of the relationship, not at the end when a handover is already underway. A clear IT support contract should specify what documentation will be produced, in what format, and when it will be updated.
Providers who are used to working with small businesses in the UK understand that clients need to be able to continue operating without them if necessary. Good documentation is a sign of professional practice and respect for the client's long-term interests. When reviewing website support retainers, check what documentation obligations are included, as this varies between providers.
When scoping a website project or planning ongoing technical support, building documentation expectations into the brief helps both sides. It sets a standard from the start and makes the handover process less awkward if the relationship needs to change. This is also relevant when choosing between WordPress and custom PHP for a new project, because the documentation approach may differ depending on the platform. WordPress sites typically have more standardised documentation requirements, while custom applications often need more bespoke documentation of specific functionality.
Making documentation a standard part of every project delivery means the business never finds itself in a situation where critical knowledge is held by one person. It also makes it easier to switch support providers if needed, because the new provider has something concrete to work from rather than starting from a blank page.
IT handover documentation checklist for UK small businesses
Before finishing a handover document, work through the following checks to confirm the document is complete:
- System architecture overview with component list and connections
- Hosting provider, server type, and control panel access reference
- SSH or remote access method, including non-standard ports if applicable
- Current PHP version for website applications
- Domain registrar, renewal dates, and DNS record list with purpose
- Email configuration, including SMTP hostname, authentication, and ports
- CMS version, active plugins or extensions, and custom code locations
- Database name, location, and any non-standard structures
- Third-party services list with account ownership and billing details
- API keys and webhooks, noting live versus test environments
- User account summary with admin role holders identified
- Known issues, active workarounds, and documented limitations
- Provider support contacts, escalation paths, and contract references
- Credentials stored separately with reference location documented
- Version history or changelog showing last update and changes
Reviewing this checklist against your current documentation is a practical way to identify gaps before they become problems. If your business has never produced a handover document, starting with this checklist gives you a structured starting point.