{"id":6129,"date":"2026-11-10T18:20:00","date_gmt":"2026-11-10T18:20:00","guid":{"rendered":"https:\/\/www.cmsgalaxy.com\/blog\/?p=6129"},"modified":"2026-11-10T18:20:00","modified_gmt":"2026-11-10T18:20:00","slug":"eight-things-website-handover","status":"publish","type":"post","link":"https:\/\/www.cmsgalaxy.com\/blog\/eight-things-website-handover\/","title":{"rendered":"Eight Things to Hand Over When a Website Project Ends"},"content":{"rendered":"

A website project rarely fails at launch. It fails three months later, when the person who built it has moved on and the person who inherits it cannot work out why the contact form sends mail to an unfamiliar address. The launch is visible; the website handover<\/strong> is where long-term quality is decided. This list sets out eight items that a clean end-of-project handover for a CMS-driven site should cover, with the reasoning behind each. Use it as a closing checklist for agency work, freelance work or an internal build.<\/p>\n

Why the handover deserves its own deliverable<\/h2>\n

Web projects accumulate invisible decisions: which plugin does what, why a setting was changed, which page depends on a custom template. Those decisions are cheap to record while fresh and expensive to reconstruct later. Anyone who has inherited an undocumented site knows the pattern. The first week is spent in forensic mode, clicking through settings and reading code to answer questions that a single page of notes would have settled.<\/p>\n

The argument for treating handover as a deliverable is simple. It converts private knowledge into shared knowledge at the moment the builder is most informed and the client is most attentive. After that window closes, both conditions weaken.<\/p>\n

The eight items<\/h2>\n

1. A plain statement of what was delivered<\/h3>\n

Start with a short, dated list of what the project produced: pages, templates, forms, integrations and content types. Match it against the original scope. Anything agreed but not built should appear in a separate list, so there is no later argument about whether it was forgotten or dropped.<\/p>\n

2. The half-finished and the deferred<\/h3>\n

Every real project ends with loose threads: a page awaiting copy, an integration paused until the vendor responds, a design tweak postponed. Record each one with its reason and its next step. This section protects the owner from false assumptions and spares the next developer from guessing which unfinished pieces were intentional.<\/p>\n

3. An accounts and access register<\/h3>\n

List every account the site depends on: hosting, domain registrar, DNS, CMS admin users, analytics, email services, backup storage and any paid extension licences. Beside each, record who owns it and how recovery works. The key principle is that business-critical accounts belong to the business, not to the builder. Moving ownership is slow when a verification email goes to a former contractor.<\/p>\n

4. The map of where things live<\/h3>\n

Describe the structure: where the code repository sits, how content is organised, which folder holds uploads, where backups are stored and how often they run. A rough diagram, even hand-drawn and photographed, often communicates more than paragraphs. Include the staging copy, if there is one, and say clearly which environment is the real one.<\/p>\n

5. A list of customisations and why they exist<\/h3>\n

Record every plugin, theme modification and custom snippet, and give each a one-line reason. “Disabled comments on service pages to reduce spam” is far more useful than a bare list of tool names. When an update later breaks something, this register points straight to the suspects.<\/p>\n

6. The routine tasks and their timing<\/h3>\n

Updates, backups, certificate renewals, content reviews and form tests each have a rhythm. Write down what needs doing, how often, and what normal looks like. Include how to check that a backup actually restores, because an untested backup is a hope rather than a safeguard.<\/p>\n

7. Known issues and watch points<\/h3>\n

Be candid about fragile areas: a slow page, a template that behaves oddly on certain screen sizes, a dependency nearing the end of support. Evidence-led handovers include what was measured, when, and with which tool, so that the next person can repeat the check rather than rely on opinion.<\/p>\n

8. People to ask and a follow-up window<\/h3>\n

List the individuals holding context: the original builder, whoever owns the copy, the vendor representative. State when the builder will answer questions after the handover, and for how long. A defined, short window is more honest and more useful than an open-ended offer that fades.<\/p>\n

Where handovers usually go wrong<\/h2>\n

Looking across typical projects, a few failure modes recur. The first is timing: the pack is assembled in the final hour, so it records only what the builder happens to remember. The second is audience: it is written for a fellow developer, though the real reader may be a marketing manager who has to renew a licence. The third is drift, where the pack is accurate on delivery day and then never touched again, even after a plugin is swapped or a hosting plan changes.<\/p>\n

Each has a modest remedy. Begin the pack at the project midpoint and add to it as decisions are made. Write each section so a non-specialist can act on it, with plain verbs and no assumed context. And assign an owner to keep the pack current, with a short entry in the calendar to review it after each significant change. None of this requires special tooling; a shared document with dated headings is enough.<\/p>\n

A related habit worth adopting is the dated change line. Whenever something in the site is altered after launch, add one sentence to the pack: what changed, when, and why. Over a year this becomes a compact history that answers many of the questions a newcomer would otherwise raise.<\/p>\n

What the evidence suggests about website structure<\/h2>\n

The eight items are easier to write when a site has a sensible structure to begin with. Well-organised sites have clear service pages, a trustworthy about section and a considered homepage, and each of those has a defined owner. Articles on the pages every business site needs<\/a> and on building service pages that convert visitors<\/a> are useful because they establish what a complete site contains, which is precisely the inventory item one asks for. If planning was thin at the start, the handover will expose it, as the discussion of planning a site before development begins<\/a> makes clear.<\/p>\n

Handover and the freelance model<\/h2>\n

The checklist matters most when the builder is not a long-term employee. Many organisations hire external specialists for defined periods: a migration, a performance fix, a deployment pipeline for the site. The engagement ends on a known date, so the quality of the exit is part of the job. A portal like DevOps FreeLancers, a directory of DevOps freelancers organised by country<\/a>, represents that style of short, specialist engagement, and it is a reminder to ask any outside engineer what the handover pack will contain before the work starts.<\/p>\n

A quick audit of your own handover<\/h2>\n

To test a handover pack, give it to a colleague who did not work on the project and ask them to answer five questions using only the pack:<\/p>\n

    \n
  1. Who owns the domain and where is it registered?<\/li>\n
  2. How do I restore the site from last night’s backup?<\/li>\n
  3. Which customisations might break after the next update?<\/li>\n
  4. What was left unfinished, and why?<\/li>\n
  5. Who do I contact if something looks wrong?<\/li>\n<\/ol>\n

    Any question they cannot answer marks a gap in the pack. This is a better quality signal than the length of the document, since a short pack that answers all five beats a long one that answers two.<\/p>\n

    Final observations<\/h2>\n

    The reasoning behind all eight items is the same: knowledge has the highest value and the lowest cost at the point of departure, and loses value fast afterwards. A website is a living system with owners, accounts, routines and quirks, and a handover is the instrument that transfers those safely. Treat it as seriously as the launch, put it in the project plan with a date, and the site you deliver will still make sense to the next person long after your involvement has ended.<\/p>\n","protected":false},"excerpt":{"rendered":"

    A website project is not finished at launch. This list covers eight items that make the next person’s start easier, from access registers to known issues.<\/p>\n","protected":false},"author":14,"featured_media":6130,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1455],"tags":[],"class_list":["post-6129","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web-development"],"_links":{"self":[{"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/posts\/6129","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/users\/14"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/comments?post=6129"}],"version-history":[{"count":1,"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/posts\/6129\/revisions"}],"predecessor-version":[{"id":6204,"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/posts\/6129\/revisions\/6204"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/media\/6130"}],"wp:attachment":[{"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/media?parent=6129"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/categories?post=6129"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cmsgalaxy.com\/blog\/wp-json\/wp\/v2\/tags?post=6129"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}