What the business decision involves
A proper handover is more than a working homepage. Owners need clarity on domain and hosting control, source ownership, content, approved access, maintenance responsibilities and recovery options.
An illustrative small-business scenario
Consider this hypothetical situation: A contractor hands over a working website but not its source, registrar access or backup instructions. Acceptance should check contract-specific deliverables before the project is closed.
The point is not that every business has the same needs. For what should a website developer hand over after completing your project, first identify the real decision, the person responsible and which evidence will show that the selected option worked.
A sensible checklist
Request the agreed source or export, domain/hosting account map, administrator access procedure, asset licensing information, backup method, tested links/forms and a list of outstanding issues.
What to verify before committing
Deliverables follow the contract; do not assume unrestricted rights to licensed templates or private supplier accounts. Remove temporary access after acceptance.
A practical next decision
A responsible handover includes editable source or agreed deliverables, domain and hosting access ownership, asset licences, redirects, form destinations, backup method and maintenance instructions. Confirm who can publish future changes. A screenshot of the design is not a recoverable website.
Define handover as evidence, not a farewell email
A website is not fully handed over merely because the developer sends a link and says the project is finished. The business needs to know what was built, where it runs, which accounts control it, and how another authorised person can maintain it. Agree on the handover checklist before final acceptance, ideally while the project scope is being written. Separate the delivered website from ongoing support obligations: a completed build does not automatically include unlimited future changes. Ask for a dated package of files, account ownership information, instructions, test results and unresolved items, with a named person responsible for each.
Confirm domain registrant and registrar access
The domain name is a business asset whose registration must be distinguishable from website hosting. Request the registrar's name, the registered domain, expiry date, registrant organisation and administrative contact. The owner should know how to sign in through an approved business-controlled account and how to recover access. A developer may manage DNS or renewals without being the legal registrant; record those roles separately. Do not accept a screenshot of the website as proof of domain control. If a transfer is planned, obtain the appropriate registrar instructions and approval rather than assuming that changing hosting automatically transfers the domain.
Document the DNS configuration without changing it
A handover should include a current record of authoritative nameservers and the DNS entries needed for the website, mail and domain verification. Typical entries may include A or AAAA records for web traffic, MX records for email, TXT records for verification and mail authentication, and CNAME records for aliases. Record the intended purpose and responsible provider for each critical entry. Avoid distributing credentials or private tokens in a general handover document. A written inventory makes future troubleshooting safer, but it is not authorisation to edit live DNS. Any later change should have a separate impact assessment, approval and rollback plan.
Provide hosting details and account boundaries
The owner should receive the hosting provider's name, product or plan, renewal date, administrative contact and the method for requesting support. Describe the web root, database arrangement and any resource limitations relevant to maintenance without exposing server secrets. If a reseller manages hosting, clarify whether the business has its own control-panel account or relies on the reseller for changes. Record which party performs backups, software updates and incident response. A vague promise that the developer will always handle the server is not an adequate substitute for an agreed support scope and a documented recovery contact.
Deliver website files and explain the format
Ask for the actual deliverables specified by the contract: published site files, approved source assets and, where applicable, editable project files. A static website may consist of HTML, CSS, JavaScript and images; a content-managed site can additionally depend on themes, plugins, databases and configuration. Explain which files are source material and which are generated output, because uploading an old generated folder may overwrite later work. Include a simple directory map and version identifier. The right to receive and reuse design assets depends on agreed intellectual-property and licence terms, so do not assume every third-party component is transferable.
Treat content exports and full backups differently
For a WordPress project, the Tools Export function produces a content export that can contain posts, pages and related records. That is useful for portability but should not be confused with a full copy of site files, installed extensions, media dependencies and server configuration. cPanel documentation similarly distinguishes partial backups from full-account backups and notes that full restoration generally needs WHM or provider involvement. Ask the developer to identify exactly what each supplied archive contains. A business should be able to explain how it would restore the working site, not merely point to a file named backup.
Hand over database information safely
A dynamic site may depend on a database containing pages, settings, form submissions or transactional records. The handover should identify the database platform, backup format, ownership and restoration dependencies. Do not place database passwords, customer records or production dumps in a broadly shared document. Provide a secure transfer process approved by the business, and explain whether any sensitive data should be redacted or retained separately. For a static site with no database, explicitly state that the database item is not applicable. This avoids both unnecessary technical work and the dangerous assumption that every website can be recovered from files alone.
Record every third-party service and licence
The completed site may use fonts, stock photography, form services, booking tools, maps, email delivery, analytics or paid themes. For each integration, identify the provider, business account owner, licence terms, renewal date and any usage or subscription limits. Distinguish a licence purchased for one project from a reusable company-wide entitlement. If a developer owns the subscription, ask what happens when the support relationship ends. An undocumented integration can fail months after launch when a card expires or a vendor changes terms. The owner needs a service register, not just a list of brand logos.
Transfer access using least privilege
The business should control its own key accounts while developers retain only the permissions needed for agreed support. Cloudflare's member and role documentation illustrates how account access can be scoped by role and resource rather than sharing one master login. Ask for an access inventory showing account owners, administrators, temporary collaborators and recovery channels. Confirm that departing contractors can be removed without disabling the owner's access. Multi-factor authentication and recovery codes should be handled through the company's approved secure process. Do not email passwords or API tokens as part of a general project summary, and never assume a screenshot proves an access transfer succeeded.
Provide a page and feature acceptance inventory
List the delivered pages, language variants, forms, navigation elements, downloadable files and integrations against the approved project scope. A homepage loading successfully does not prove that every enquiry form or mobile layout works. Record the expected behaviour of each feature, the test device or browser, and the evidence captured. Mark anything not tested as pending rather than passed. If a feature was removed or changed during the project, link the owner's approval for that scope decision. This creates a practical acceptance record and prevents disputes over whether an omitted page was intentionally excluded or accidentally forgotten.
Include bilingual content and editorial responsibility
For an English and Bahasa Melayu website, the handover must identify the approved text in each language, the pages it belongs to and who may revise it later. A translated title alone does not establish equivalent meaning throughout the page. Keep the final copy in a format the business can edit and link it to the published page versions. Record the status of terminology, product claims, contact details and any human language review. Do not claim independent translation approval when only automated drafting was performed. When a future promotion changes, the owner needs to know which two language versions require coordinated updates.
Document SEO and search ownership without promising rankings
Handover should include canonical URLs, page titles, descriptions, sitemap location, robots directives and any structured data that the project was contracted to deliver. Google Search Central explains how crawlable links and sitemaps help discovery, but does not guarantee indexing or ranking. If Search Console was configured, document the verified property and the business-controlled ownership arrangement without sharing private access tokens. Distinguish a source-level SEO check from an actual public crawl or search-engine observation. The owner should receive the evidence of tests performed and a list of remaining checks, not a claim that every page is already indexed.
Specify image rights and original brand assets
A business should receive its approved logo files in the agreed formats and know which images are original, licensed or supplied by the client. Record permitted use, attribution requirements and any restrictions on transferring a stock asset to another supplier. Provide image alternatives and descriptive filenames where included in scope. Do not replace an approved organisation logo with a decorative article illustration or a generated substitute. For a multilingual site, verify that meaningful image descriptions suit each language. The handover inventory should identify which visual assets remain pending approval rather than silently treating every file in the project folder as accepted.
Explain backup frequency and recovery ownership
Ask the developer to state when backups are made, where copies are stored, how long they are retained and who can restore them. A downloadable archive is useful only when its contents and recovery process are understood. cPanel documentation notes that a full-account backup is not automatically restored from the ordinary cPanel interface; provider or WHM assistance may be required. If a restoration test was performed, record its date, environment and result. If none was performed, label it untested. Avoid promising a fixed recovery time without a service agreement and evidence that the required people and files are available.
Set a maintenance and update boundary
The handover should answer who updates website software, renews licences, monitors broken forms, reviews security alerts and changes business content after acceptance. A static website and a WordPress installation require different maintenance tasks. WordPress guidance recommends updates and backups, but that does not mean a developer's original build fee includes indefinite management. Ask for a care proposal only if the business needs that service, with frequency, exclusions, support hours and approval rules. Record any warranty period separately from an optional ongoing contract. The owner should be able to decline extra services without losing access to its own completed deliverables.
Supply a change and incident contact sheet
A website owner should know whom to contact for a spelling correction, a failed enquiry form, a hosting outage and a domain billing problem. Those incidents may belong to different providers. Create a contact sheet with supplier names, official support routes, account references, business hours and escalation rules. Do not put customer data or passwords into support tickets unless an approved secure process requires them. State which issues the developer will investigate and which must be referred to a third-party provider. Clear ownership reduces delays when a website appears broken but the underlying cause is an expired domain or unrelated mail service.
Record known limitations and unfinished items
A trustworthy handover includes unresolved issues, accepted limitations and decisions postponed by the owner. For each item, record its effect on visitors, severity, temporary workaround, responsible person and proposed next step. Do not mark a feature as tested simply because it was demonstrated once on the developer's computer. If browser or mobile testing was incomplete, state exactly what was not checked. Keep changes requested after acceptance separate from defects in the agreed scope. This protects both customer and supplier from treating an incomplete release as fully approved or from expanding the project without a documented commercial decision.
Use a structured final acceptance meeting
During acceptance, the developer can demonstrate the delivered pages, show the handover inventory, explain account ownership and walk through one safe routine update. The owner can then check the evidence against the signed scope and list remaining exceptions. Record the meeting date, attendees, version identifier and what was accepted or rejected. Do not infer approval from silence, a paid invoice or the fact that the site is accessible. If a release or production deployment requires separate authorisation, keep that gate explicit. A concise signed or otherwise approved acceptance record is more useful than a long unverified checklist.
Consider a hypothetical supplier change
Imagine a Malaysian service business whose developer has completed a bilingual five-page website. Before paying the final milestone, the owner asks for the domain registrar details, source files, hosting plan, content inventory, form test evidence and a secure access handover. The developer identifies a paid booking tool and explains its renewal separately. The owner verifies that the company controls the domain and can contact hosting support, then records an outstanding mobile form defect for correction. This example shows how evidence and exceptions guide acceptance; it is not a claim that any OnHypp customer project has passed those checks.
Sources & further reading
Ready to explore a related service?
See the related OnHypp service and decide whether it fits your business needs.
Email & hostingDomainsWebsite design