Website Handover and Ownership Checklist: Do You Actually Control Your Site?
You control your website when your company, not the agency, holds the domain, DNS, hosting, source code, CMS and operational accounts, and when someone on your side can log in, publish a change, build the code from source, deploy a working copy and remove the supplier's access without borrowing anyone's identity. A finished, live site does not prove any of that. Before you sign final acceptance, run every asset through a named-owner check and a control test. This guide gives you the inventory, a 16-point readiness score, the contract decisions to lock in early, four lock-in traps and a five-part verification test.
WebStackRank is a Dubai-based digital agency that builds, ships and hands over web, SEO, mobile, e-commerce and automation projects for business decision-makers across the GCC and Europe. This checklist is written for founders, marketing leads, operations managers and procurement teams who need to verify ownership rather than accept an untested promise. According to WebStackRank's published pricing page (Pricing — WebStackRank, 1 July 2026), the agency uses fixed project pricing without mandatory retainers and gives the client ownership of the code at handover; that is a statement about WebStackRank's own published offer, not a rule binding other suppliers or an override of third-party licence terms.
What you get here that our other guides do not: the procurement, pricing and CMS guides explain how to choose and scope a build; this is the only page that proves, asset by asset, that you can run and move the site without us. Remove the inventory, the readiness score, the trap list or the control test and a buyer loses a complete way to demonstrate independence.
Decide ownership before development starts
Ownership obligations belong in the scope of work before a line of code is written. Left until launch, ordinary deliverables become a negotiation, and the buyer loses the leverage to reject an incomplete handover. Agree these at kickoff:
- Which accounts open in the client's name from day one. Domain, hosting, analytics and transactional email are cheaper and cleaner to open under the client than to migrate later.
- Where the source code lives. Name the client's repository organisation as the home for the code, with the agency added as a collaborator, not the reverse.
- What counts as a complete, buildable handover. Define up front that the deliverable includes dependency records, environment requirements and build instructions, so an empty repository or a running site alone cannot pass as done.
- When each item transfers. Tie each asset to a milestone, launch or final payment, and have qualified counsel review any conditions on intellectual-property transfer.
- Who signs off, and against what test. Name the person on your side who performs the control checks at acceptance. An agency demonstration proves the agency has access; it does not prove you can operate alone.
Turn "we'll give you access" into named owners and control tests
"We will give you access" is not a deliverable, because it names no owner, no recovery route and no test. Replace it, for every asset, with three concrete things: the person or company account named as owner, the recovery method that person controls, and the specific action they will perform at acceptance to prove control. Our 7-phase development process (Website Development Process — WebStackRank, 18 May 2026) commits calendar dates in week one and runs a weekly client demo, which is where these ownership decisions are recorded and checked.
The complete handover inventory: a named owner for every asset
This inventory connects each asset to the evidence you should receive, the party that should be named as owner, and one action a client can perform to confirm control. A list of passwords alone establishes neither account ownership, recovery control nor portability.
| Asset group | Evidence to receive | Named owner | Control check the client performs |
|---|---|---|---|
| Domain registrar | Registrar access, registrant details, renewal method and recovery route | The client company, in an account it controls | Inspect the domain record, billing and authorised users directly. |
| DNS records | Administrative access and a dated export of active records | The client, or a provider account the client administers | View and export the A, CNAME, MX and TXT records without agency help. |
| Source code repository | Source, relevant history, dependency record, environment requirements and build instructions | The client's repository organisation | Clone into a clean directory and produce the documented build. |
| Hosting and deployment | Administrative role, billing control, environment inventory and release steps | The client, or a documented transferable arrangement | Deploy a working copy to a non-production environment it controls. |
| CMS administrator account | A named administrator account and client-controlled recovery method | A person accountable to the client | Edit content, manage settings, and add or remove users. |
| Analytics and operational services | Access to analytics, tag management, transactional email, search tools, payment services and live integrations | The client as primary owner wherever the service supports one | Inspect users, connected domains, billing and active credentials. |
| Design source files | Editable files, exported assets, font records and available licence documentation | The client's design workspace or controlled file store | Open and edit the original source instead of recreating it from screenshots. |
| Operating documentation | Environment map, release steps, backup method, recovery notes and known limitations | The client's document store | A colleague who did not build the site can identify every system and follow the release steps. |
Keep secret values in the company's approved credential manager, not inside this inventory. The inventory names systems, owners, recovery routes and evidence; the credential system holds the sensitive strings.
Score your handover readiness before you sign off
This readiness score exists because "it feels mostly done" is not an acceptance standard. Score each of the eight asset groups above: 0 if it was not delivered, 1 if it was delivered but the control check has not passed, and 2 if it was delivered and the control check passed. That gives a maximum of 16.
The acceptance rule has three parts, and all three must hold: no asset may score 0; the two highest-risk assets, the domain registrar and the source code repository, must both score 2; and the total must reach 14 of 16.
Here is a worked example from a routine marketing-site handover. Domain 2, DNS 2, source repository 1 (a clean clone failed to build because two private packages and the environment template were missing), hosting 2, CMS 2, analytics and services 1 (the transactional-email account was still in the agency's name), design files 2, documentation 1 (the backup and recovery steps were written but never tested). The total is 13 of 16.
Thirteen out of sixteen looks close enough to accept, and that is exactly the trap. The source repository scored 1, which breaks the highest-risk rule, and two assets sit at 1. So this handover is not accepted: the repository build and the transactional-email transfer become named acceptance items with owners and dates. A high score never overrides a blocker, which is why the score and the pass rule are separate tests rather than one average.
Contract clauses to require up front: IP assignment, credential transfer and no lock-in
These three decisions describe the commercial outcome you need, not legal wording. They may not suit a particular jurisdiction, so ask qualified counsel to review the final drafting.
IP assignment for custom deliverables
Define which custom code, designs and content transfer to the client, when the transfer occurs and what is excluded. Pre-existing supplier tools, open-source software, fonts, plugins and other third-party components may carry separate terms. Access to a finished website is not the same as a documented transfer of every custom deliverable.
Credential transfer timeline and acceptance owner
Attach the inventory above to the acceptance process. Name the person who confirms receipt and the point at which each account must be under client control. A live website is insufficient evidence, because it can run while the buyer lacks registrar, hosting or repository authority.
No lock-in and a documented exit path
Require the proposal to explain how the site can be exported, rebuilt or moved, including any limits the chosen platform creates. This does not condemn every managed platform; it means the exit consequence must be visible before the platform is approved. The annotated web-development RFP template gives you a wider procurement structure to record these requirements, and counsel should assess enforceability, licences and jurisdiction-specific terms.
Four ownership traps: agency-owned domain, reseller hosting, shared logins and proprietary builders
Each trap begins with a convenient arrangement and ends with a business action the buyer cannot complete alone.
Agency-owned domain account
The site works normally while the domain sits in the supplier's registrar account. The dependency surfaces the moment you need to change DNS, replace the supplier or recover the domain. Safer: a company-controlled registrar account with a named agency user where delegated access is supported.
Reseller hosting with no agreed transfer route
You get a CMS login but no hosting administration, billing relationship or deployment path. Leaving then depends on an export whose contents and timing were never defined. Record whether the account itself can transfer and which files, databases and configuration will be supplied if it cannot.
Shared administrator login
Consider a three-person marketing team that shared one admin login with the agency during the build. When the project ends and they rotate the password to remove the departing agency, all three internal users are locked out at once, and the recovery email points to the agency's mailbox. One shared credential hides who changed what and makes selective removal impossible. Use named accounts and keep at least one recovery route under company control.
Proprietary platform with no usable independent build
Editable content does not mean portable source. Before approving a proprietary page builder or hosted arrangement, ask the supplier to demonstrate the agreed export, rebuild or migration route and to document what cannot move.
How do you verify ownership without risking production data?
Run a five-part control test on client-controlled accounts, using non-production environments, harmless reversible edits and no changes to live DNS or customer data; passing all five means your team can access, edit, rebuild, deploy and govern the site without the agency's identity. Receiving a folder proves files were delivered, while completing these actions proves usable control.
- Independent access test. From a browser session not already authenticated by the agency, open the registrar, DNS, hosting, repository, CMS and material third-party services through named client accounts, and confirm recovery routes without risky production changes.
- Editing test. Make a harmless, pre-agreed content edit through a client CMS admin account, publish it, verify it, then reverse it. Record the person and account used.
- Clean build test. Have a technical reviewer clone the repository into a clean directory, install the documented dependencies and produce the expected build. Missing private packages, environment instructions or config values are acceptance issues.
- Staging deployment test. Deploy that build to a non-production environment the client controls, and check key pages and agreed integrations without touching production DNS or live customer data.
- Access-revocation test. On a non-critical service, confirm the client administrator can remove and restore a named agency user. Do not test this on production-critical access without an agreed recovery plan.
Record each failed action as an acceptance item with an owner, required evidence and resolution date. A support agreement can continue after handover, but it should remain a choice rather than the only way to keep the site running.
Do I automatically own my website after an agency builds it?
No. Paying the invoice and receiving a live website does not by itself give you control of the domain, hosting, source code or CMS accounts. Ownership exists only when those assets sit in accounts your company administers and you can operate them without the agency. Contract interpretation should be handled by qualified counsel.
What should I ask for at website handover?
Ask for client-controlled access to the domain, DNS, hosting, repository, CMS and operational services, plus editable design files and usable build, deployment, backup and recovery documentation. Do not accept an emailed URL or password as complete evidence; confirm the account owner, billing contact, recovery route, administrative role and control check for each asset.
How do I know I am not locked into an agency?
You are not operationally locked in when your team passes the independent access, editing, clean build, staging deployment and access-revocation tests using company-controlled accounts and documentation. Ongoing support can still be useful; the distinction is whether you can change suppliers or operate internally without losing control of the site.
Close the handover without creating another dependency
Assign one person on the client side to own the inventory and the score. Give every unresolved item a responsible party and an acceptance date. Retain named agency accounts only where continuing support requires them, and replace any shared credentials used during delivery. For the wider supplier review, use the agency vetting questions, and check details of WebStackRank's own process with the accountable delivery team. A named WebStackRank delivery lead and qualified counsel should review the operational and contractual guidance respectively before publication.