A useful handover includes source files, deployment instructions, content and clear account control. Verify access while the delivery team is still available. Ask a new maintainer to locate the current source, identify the production host and explain how a small text change is published. A zip file alone may be insufficient when the build requires undocumented services or secrets.
Separate possession of files from control of accounts
Receiving a folder named “website” does not necessarily give you the ability to keep the site running. The domain, DNS, hosting, source repository and business email may all live in different accounts. A proper handover identifies each service, its account owner, its purpose and the person responsible for renewal or recovery. Store this inventory privately; it is not content for a public documentation page.
Prefer ownership arrangements that survive a change of supplier. Where practical, the business holds the main accounts and grants collaborators appropriate access. Sharing one password among several people makes later changes harder to audit. Confirm recovery email addresses and access methods while the original supplier is still available. Do not put passwords, recovery codes or deployment secrets into the source repository.
For example, a business can own its domain while a supplier owns the hosting account. That can be a deliberate arrangement, but the customer should understand what happens if maintenance ends. Ask whether the site can be exported, what it depends on and what work a move would require. A clear answer is more useful than a broad statement that “everything belongs to you.”
Ask for a package another developer could use
The source code should include the files needed to reproduce the site, together with package information and build instructions. A copy of the rendered pages alone may be sufficient for viewing but insufficient for editing the underlying design cleanly. Conversely, a source repository without installation steps or configuration notes can leave a future developer guessing.
Request a short explanation of public configuration, private runtime settings and secrets that must be supplied separately. Names of required settings belong in documentation; their real values do not. If the site uses a database, include its schema and migration process without exposing customer records. Original content, licensed media references and any editable design sources should be listed explicitly in the agreed delivery scope.
A practical handover exercise is to have an authorised person follow the instructions in a fresh local folder. Can they install dependencies, build the site and understand which external accounts are still required? This is a more convincing check than the supplier demonstrating a working copy that depends on undocumented settings from their own computer.
Record the live state and continuing responsibilities
At the time of handover, note the live domain, deployment date, published version and known limitations. Include the form's operational path: where submissions are saved, who reviews them and how to notice a service failure. If notifications are optional, distinguish a missing notification from a missing database record. The business should know which source represents the actual enquiry history.
Agree what support follows delivery. Correcting a defect in the agreed work, changing a service description and adding a booking engine are different tasks. A defined support arrangement avoids treating every future request as either automatically free or automatically outside responsibility.
Before closing the project, remove unnecessary temporary access and keep any retained access intentional. Verify the site and form after account changes, because permissions can affect deployment or storage. A good handover finishes with files, control and understanding together: the owner knows what was delivered, what it costs to operate and how another authorised person could continue the work.
Use a handover rehearsal. Ask the owner or another authorised maintainer to identify the domain account, find the current source version and explain where enquiries are reviewed. Then ask them to locate the instructions for rebuilding the site without exposing any secret. The exercise often reveals missing links between otherwise complete files.
Write down any access that remains with the supplier and why. A maintenance agreement may justify continuing access, but the scope should be intentional. If an account cannot be transferred, document the export or migration route instead of promising unrestricted ownership. Include who can authorise changes to DNS and billing so routine requests do not accidentally affect another project.
Keep a final delivery list with dates and acceptance notes. It should describe the actual files and working processes received, not merely repeat the original sales proposal. When something depends on an owner's still-missing account information, mark it clearly. This lets a future collaborator distinguish an unfinished external setup from code or content that was never delivered.
Practical checklist
- Collect repository access
- Document domain and DNS
- Record backup and restore steps
A concrete example: Ask a new maintainer to locate the current source, identify the production host and explain how a small text change is published.
A boundary to keep clear: A zip file alone may be insufficient when the build requires undocumented services or secrets.
Your next step
Tell Orvunweb about your project
