Website Handover: What to Ask for Before a Project Ends

The website is live and the final invoice is ready. Before the project closes, there is one more practical question: can you run the site with confidence? A successful handover should leave you knowing what you own, how routine changes work and who to contact when something goes wrong.

You do not need to become a developer. You do need enough information to avoid depending on one person’s memory for every update, renewal or support request.

Confirm ownership and account access

Check who controls the domain registration, hosting account and WordPress administration. These are separate services and may have different renewal dates. The business should know which account holds each one and how to maintain access if a supplier changes.

Use individual accounts with appropriate permissions instead of sharing one login with everyone. Exchange credentials through an agreed secure method, not in a public document or a long email thread. Keep an account inventory that records the service and responsible person without exposing passwords.

Ask for editing guidance using your actual pages

A general WordPress tutorial is less useful than a short demonstration of the tasks you will perform. Ask how to change a service description, publish an article, replace an image and check the mobile result. Find out which design elements are deliberately controlled and which parts you can safely edit.

Try a routine task yourself before the handover meeting ends. If you cannot complete it without help, the documentation or training needs another pass. A recording or concise guide can make occasional tasks easier to repeat months later.

Understand backups and recovery

Ask what is backed up, how often it happens, where copies are stored and how long they are retained. WordPress consists of both files and a database. Its backup documentation explains why both matter. A copy of uploaded photographs alone is not a complete website backup.

Agree who can restore the site and whether restoration is included in support. Ask when recovery was last tested. An automatic backup notification is useful, but it does not by itself demonstrate that a full restore will work.

Separate fault correction from ongoing maintenance

A delivery agreement may include a period for correcting faults in the agreed work. That is not the same as an ongoing service for updates, monitoring, new pages or changes to third party tools. Ask for the distinction in writing, with dates and a clear route for reporting problems.

A hypothetical example is a contact form that fails because the original build was incomplete, compared with a request to add a new booking system months later. The first may fall within fault correction; the second is new scope. The actual agreement determines the boundary.

Record licences, renewals and dependencies

List paid themes, plugins, fonts and external services used by the site. Confirm who pays, who receives renewal notices and what happens if a licence expires. Some software may continue running but lose access to updates or support. The implications depend on the product, so ask rather than assume.

Also establish who tests updates. WordPress recommends a backup before updating. For an important business site, agree how changes are checked and how a failed update is handled instead of leaving that responsibility undefined.

Finish with a usable support agreement

Know where to send a request, what details to include and when a response can reasonably be expected. A response target is not the same as a guaranteed resolution time. Hosting, email delivery and external platforms may also sit with different providers.

Keep the final scope, access inventory, editing guide, renewal details and support boundaries together. Those documents are part of the value of the project. Our web development service explains the wider delivery model, while our approach shows how decisions move from planning to handover.