What should you receive when your business website is handed over?
Direct answer. Use seven handover groups: account access, editable content, source and deployment, backups, working enquiries, recurring services and support. Approve the transfer by testing access and recovery, rather than by receiving a folder of files alone.
Commissioning work now? Compare the Business website deliverables, or send the project details for a scope check.
Define handover while the project is being scoped
The best time to decide what you receive is before work starts. A brochure site, a hosted store and a custom application will not produce the same artefacts. Write down the accounts, files, exports and instructions that your chosen platform actually supports. A source-code ZIP is useful only when someone can identify its version and run or deploy it.
This guide covers operational access and continuity. Copyright and licence terms are separate questions: consult your agreement and appropriate advice rather than treating possession of a password as proof of ownership. Our code ownership guide covers that separate issue. Keep the operational checklist attached to the deliverable list.
Create an account register you can maintain
List the domain registrar, DNS service, hosting, CMS, email delivery, analytics and any paid plugins or connected APIs. For each, name the business account, responsible person, renewal contact and the access the supplier retains. Use each platform’s invitation or role mechanism where available. Do not paste passwords, recovery codes or secret API keys into a public project document or general enquiry form.
Log in from the business’s own account and confirm that you can perform the agreed administrative tasks. Verify recovery contacts with the person who controls them. A working developer login is not the same evidence as a business administrator who can recover access after the developer leaves.
| Group | What to receive | What to test |
|---|---|---|
| Accounts | Account register and agreed invitations | Business access and recovery contacts |
| Content | Editing instructions and content inventory | Change and revert a sample draft |
| Source/deployment | Agreed source, version and deployment note | Identify the deployed release |
| Backups | Defined backup set and restore process | Restore in a separate test environment |
| Enquiries/orders | Workflow map and destination owners | A labelled end-to-end test |
| Recurring services | Renewals, licences and external costs | Who pays and receives renewal notices |
| Support | Open issues and support boundaries | Named contact and reporting route |
Test a backup as an operational deliverable
For WordPress, the official administration handbook explains that a complete backup includes both files and the database. A download of the site directory alone does not necessarily contain the posts and settings stored in its database. Ask what the supplied backup covers, where a second copy lives and how restoration is checked.
A sensible handover demonstration restores an agreed backup into a separate test environment, checks important pages and confirms that the data corresponds to the backup date. That is a proposed acceptance test, not something to run against production without a plan. Record any exclusions such as external email, payment records or assets stored in another service.
Check the customer journey after the transfer
Open the important pages on phone and desktop. Submit a clearly labelled test enquiry through the existing agreed workflow and match it to the destination notification or saved record. If the site takes orders, agree a permitted test checkout with the business and payment provider; do not create unexplained real charges just to tick a box.
When URLs change, require an old-to-new URL map and test representative redirects. Google’s site-move guidance describes preparing mappings, redirects and monitoring both sets of URLs. A migration should not be sold as a guarantee that every ranking remains unchanged. Keep the redirect and monitoring work distinct from the design sign-off.
Write a maintenance boundary instead of assuming unlimited help
Ask which defects the post-launch period covers, how to report one and which work is a change request. Keep domain renewals, hosting charges, plugin licences and ongoing content work visible. A support window needs an owner and a contact route; it should not be an undocumented promise that any future work is free.
Example handover note: “Approved version: the agreed release. Business admin invitation accepted. Deployment location recorded. Backup set and restore instructions supplied. Test enquiry received by the named mailbox. Renewals and supplier access listed. Remaining issue: one agreed item, with the responsible person and next check.” Replace the example with actual evidence; do not sign it while a required test is still missing.
Decide whether you need a new build or a handover intervention
If the website already works, you may need account recovery, documentation or one technical fix rather than a replacement. Ask for a specific assessment. If you are commissioning a new site, compare the current five-page website scope and list the handover additions you need. Our development quote checklist helps make exclusions explicit.
ZoopCoder publishes this checklist as a supplier of website work. It is not independent certification of a project or a substitute for checking the actual deliverables. Your acceptance record should say what was demonstrated and what remains open.
Questions before you commission the work
Is a website ZIP enough for handover?
Not usually. You also need the accounts, deployment context, data and recovery instructions applicable to your platform.
Does downloading WordPress files include the database?
Not necessarily. WordPress stores important content and settings in a separate database; define both parts in the backup set.
Should the developer retain access?
Agree the access needed for the support period, record it and use platform roles where available. Review it when the engagement ends.
Sources and scope
Primary documents checked 3 November 2026. The commissioning tables and sample briefs are editorial suggestions, not platform requirements or measured client outcomes. Live service pages govern the current price and included work.