Website Ownership Transfer: What Changes Hands by Platform

Executive Summary

A website ownership transfer is a coordinated handover of the platform project, account permissions, domain control, subscriptions, working materials, and operating responsibilities. Giving a client an editor login completes only part of that package. WordPress.com explicitly separates ownership from Administrator permissions, while Webflow lets clients pay site bills while the project stays in the supplier's Workspace. Neither arrangement should be treated as evidence that every account has changed hands. ^{[1] [2]}

The platform differences are material. An eligible Webflow Freelancer or Agency Workspace can transfer a hosted site with its Site plan and connected domains. Framer cancels the existing Site plan on acceptance, credits unused time to the original owner, and requires the recipient to choose any needed plan. Shopify distinguishes merchant-owned collaborations, client-transfer stores, and dev stores that cannot be transferred to clients. These are separate workflows, rather than interchangeable versions of a generic handover button. ^{[3] [4] [5]}

Downloadable materials also differ. A typical self-hosted WordPress recovery needs both files and the database. A Webflow code export omits important hosted capabilities, including content-management and ecommerce functionality. Framer does not offer standalone Hypertext Markup Language (HTML) export for self-hosting. A source archive, an editable hosted project, and a functioning replacement deployment should therefore be separate acceptance items in the build scope. ^{[6] [7] [8]}

The practical decision is who can operate the site after the supplier leaves. Before authorizing changes, name the receiving business account, the person who accepts transfers, the billing owner, and the person who demonstrates recovery. Keep domain registration separate from the domain's connection to a website: connecting an externally registered domain to Shopify leaves registration and renewal with the existing provider. Use the dated platform matrix, account inventory, and functional record below to document the handover. ^[9]

Acceptance should record observed results, including a harmless publishing change, a form reaching its intended destination, key navigation, appropriately simulated commerce behavior, and the agreed recovery route. This report describes documentation-based checks as of October 30, 2026; no demo transfers or production changes were performed. A short successful sample is evidence about that sample. The World Wide Web Consortium (W3C) likewise describes its accessibility Easy Checks as preliminary, requiring more robust assessment for a comprehensive evaluation. ^[10]

Introduction and Background

The useful commissioning question is: what must the business control to make its next update without depending on the outgoing supplier? The answer starts with an agreed handover package, before the build begins. For a development supplier such as Tapflare, that means defining the receiving account and acceptance evidence in the scope. This comparison examines the platform and operational decisions a founder, marketing lead, or agency operator should settle.

An agency-built website has several ownership questions. Copyright and licensed rights concern the creative work; platform ownership concerns an account role; domain registration concerns the registrant; hosting and integrations have their own subscriptions. The World Intellectual Property Organization (WIPO) advises addressing commissioned-work ownership in writing and explains that national law and contractual agreements affect the result. A platform transfer cannot substitute for that agreement. (Source: www.wipo.int)

Before commissioning work, the scope should identify:

• Receiving organization: the business-controlled platform account, registrar account, and operational email addresses.
• Deliverables: the editable project, agreed source files, content exports, configuration notes, and a recoverable backup where applicable.
• Rights and dependencies: what is assigned, what remains licensed, and which subscriptions the recipient must arrange.
• Acceptance and support: the checks, responsible people, unresolved-item record, and agreed support period after handover.

These are recommended scope fields, rather than a claim that every platform bundles these deliverables. For example, WordPress's content export excludes configuration options and attachment files themselves, and a Framer hosted project has no official HTML self-hosting export. Asking for an export without specifying its intended use leaves an important ambiguity. ^{[11] [8]}

Owner, administrator, editor, and collaborator are product-specific roles. WordPress Administrator capabilities apply within the installed site. Google Analytics Editors can control property settings but cannot manage users, while Administrators can. Record the exact product and role, rather than a single checkbox saying “admin access supplied.” Have qualified local counsel settle unclear assignment or licensing terms where the contract requires it. ^{[12] [13]}

Webflow: Hosted Transfer, Billing Handoff, and Code Export

Capabilities

Webflow offers distinct operations. Its paid-plan client-transfer guide allows a site in a Freelancer or Agency Workspace to move to the client's Workspace with its Site plan and connected custom domains. The client accepts the transfer. Its client payments feature instead moves site billing to the client while the site can remain in the supplier's Workspace. The scope should say which outcome is intended. ^{[3] [2]}

The wider transfer guide describes different conditions for Starter, Core, Growth, and Enterprise Workspaces, and transfers into Enterprise. Those paths require a Starter downgrade and subsequent hosting, domain, and publishing work; the documentation explicitly identifies downtime. Do not apply the eligible Agency/Freelancer workflow to every account configuration. ^[14]

Adoption and receiving roles

The transfer recipient needs a Webflow account and Workspace. Ask the initiating account holder to confirm that the relevant transfer action is available for the actual site and plan; this report does not reproduce untested interface steps. If ongoing supplier access is agreed, the client can invite an eligible Freelancer or Agency provider as a guest after transfer. ^{[14] [3]}

• Confirm the path: record source and destination Workspace types, the current Site plan, and any ecommerce exception.
• Separate the payer: write down whether the client is receiving the project, assuming billing, or both.
• Retain working access deliberately: agree who can publish and recover the site after acceptance.

Webflow's general guide separately says an ecommerce recipient needs a new Ecommerce plan and must re-enable checkout. Its billing documentation also distinguishes prorated Workspace credit when the supplier paid from uninterrupted billing when the client already paid. Record the applicable outcome before acceptance. ^{[14] [2]}

Strengths and limitations

A paid Workspace can export HTML, Cascading Style Sheets (CSS), JavaScript, and assets; a paid Site plan alone does not grant code export. Exported code excludes important hosted services, including content management system (CMS) and ecommerce functionality, and Webflow form processing and search do not carry over as working services. CMS data exports must be considered separately from the code archive. ^[7]

For recovery, confirm that the receiver has the Site manager permission needed to access backups. For domains, Webflow states that it is not a registrar. A connected domain moving with a site therefore does not establish control of the external registration account. ^{[15] [16]}

WordPress: Site Administration Is Only One Layer

Capabilities

For self-hosted WordPress, separate the installed site's administration from the hosting relationship. An Administrator has administration capabilities within that site. A host may require different account-level permissions: WP Engine, for example, requires Owner or Full-with-billing permission on both hosting accounts for its site-transfer workflow. A WordPress login alone is not the complete hosting handover. ^{[12] [17]}

Specify a matched files-and-database backup. WordPress's official handbook explains that both are needed for a typical full backup; the database is not simply included when the site's directory is downloaded. By comparison, the WordPress eXtended RSS (WXR) content export omits site configuration and attachment files themselves. Label these artifacts accurately so the recipient knows what can be restored. ^{[6] [11]}

Adoption and receiving roles

The recipient should have an agreed site role, host account access, and a documented recovery location. Where hosting is being moved, use that host's procedure and identify who supplies destination permissions. WP Engine's documentation notes that some transfers require server migration or manual Domain Name System (DNS) changes, and that product extensions need reactivation at the destination. ^[17]

• Receive the installation: document the administrator, hosting account, database, and file storage separately.
• Receive the recovery set: identify the matched backup and the person authorized to restore it.
• Receive dependencies: list theme and plugin subscriptions, external services, and their renewal owners.

WordPress.com needs its own branch. Only its site owner can transfer ownership; the documented transfer includes that owner's plan, paid upgrades, and registered domains. The prior owner remains an Administrator, subject to removal by the new owner. Historical billing remains with the old account, while future transactions attach to the new owner. Do not apply this managed-account workflow to an arbitrary self-hosted installation. ^[1]

Strengths and limitations

The WordPress handbook provides a concrete recovery sequence: restore files, restore or import the database, and update configuration if database credentials changed. That gives the parties a demonstrable recovery task. If a domain is also changing, its migration guidance cautions that careless database replacement can affect serialized data. Treat the domain change as a separate technical operation with its own check. ^{[6] [18]}

Shopify: Identify the Store Type Before Handoff

Capabilities

Shopify's current partner documentation distinguishes collaborations, which give approved access to merchant-owned stores, client-transfer stores, intended for client handoff, and dev stores, which cannot be transferred to clients. Establish the store type first. A team replacing its developer on an existing merchant-owned store may need an access transition rather than a change of merchant ownership. ^[5]

For a client-transfer build, the client selects a plan when receiving the transfer. The developer documentation describes sending the invitation to the client's email from the Dev Dashboard. A store built for testing should not be assumed eligible for that route merely because its builder calls it a development store. (Source: shopify.dev)

Adoption and receiving roles

The ordinary merchant-store ownership procedure can be initiated only by the store owner. It requires separate preparation of billing, payout details, and relevant third-party payment accounts. For client-transfer stores, active Shopify Payments, including test mode, Balance, Credit, or Capital prevent transfer under the documented rules; the prescribed resolution differs by product. Agree the responsible person before changing these services. ^{[19] [5]}

• Classify the store: merchant-owned collaboration, client-transfer store, or nontransferable dev store.
• Check prerequisites: identify the accepting email, intended plan, and applicable financial-product restrictions.
• Verify retained access: record actual supplier and client permissions after acceptance.

The ordinary merchant-store guide has a different financial-products checklist: Capital or Credit prevents transfer; Balance requires emptying the account and contacting support. Do not merge that checklist with the client-transfer-store rules. The ordinary guide also calls for payout changes across active payment methods and updates to separately billed apps. ^[19]

Strengths and limitations

Comma-separated values (CSV) exports and a downloaded theme are useful materials, but not a complete clone. Shopify documents manual settings work and app reinstallation when duplicating a store; orders cannot be imported through the Shopify admin. Paid theme licensing is store-specific, so moving a theme to another store is a different issue from changing the owner of the same store. ^{[20] [21]}

For an externally registered domain, connecting it to Shopify leaves registration, renewal, and DNS management with the domain provider. Keep those accounts in the inventory even when the storefront is already working. ^[9]

Framer: Project Ownership and Subscription Replacement

Capabilities

Framer's project transfer makes the accepting recipient the project owner. Its documentation says the site stays online and connected custom domains continue working during transfer. That statement describes Framer's documented process; this report did not test it on a live project or measure availability. ^[4]

The subscription consequence is distinct: acceptance cancels the existing Site plan, unused subscription time is credited to the original owner, and the recipient chooses and pays for any required plan. The receiving team should arrange its billing responsibility before acceptance rather than assume that a previously paid subscription has been assigned. ^[4]

Adoption and receiving roles

Only the project owner or a Workspace administrator can initiate the documented transfer, and the sender can choose to remain an editor. The handover record should name the receiving account and state whether that editor relationship is wanted. Continued editing access is an operational decision, not evidence that the sender still owns the project. ^[4]

• Prepare acceptance: confirm the business-controlled receiving account and the person accepting the invitation.
• Prepare the plan: record the required subscription and the authorized payer before acceptance.
• Prepare continuity checks: verify publishing, forms, custom domains, and the agreed recovery procedure afterward.

Use a checklist with separate fields for project received and plan arranged. Leave an unresolved item open if the recipient cannot demonstrate the required paid capability. Require the receiving owner to confirm its plan status and required functions after acceptance. The useful commissioning requirement is a named person who can confirm the actual account outcome and resolve any missing capability.

Strengths and limitations

Framer explicitly says it does not offer HTML export for self-hosting. Its documented platform services are part of the deployed site, so receiving an editable project should not be described as receiving a standalone website package for another host. If independent hosting is a requirement, resolve that architecture question before commissioning the build. ^[8]

Keep external domain registration on the separate account checklist. The documented continuity of a connected domain is evidence about that connection during transfer; it is not an assertion that the registrar account, renewal payment method, or registrant contact has changed. Those should each have their own receiving-party confirmation.

Feature Comparison

Table 1 compares the handover layers documented by the platforms. Verification date: October 30, 2026. The receiving team should recheck its actual account and plan at execution; the entries are documentation-based, not tested interface instructions.

The matrix supports a practical choice: keep a functioning hosted project within its platform when that meets the business requirement; specify an independently deployable package only where it is supported and included in scope. A billing-only handoff, content export, and hosted-project transfer should each have their own acceptance status. None should be used as shorthand for all the others.

Registrar control deserves its own evidence. GoDaddy delegates cannot accept incoming domain transfers or manage payment methods, despite having delegated access. Namecheap's internal account push preserves DNS settings, but related hosting, Private Email, and certificates may need additional actions. Those examples show why “domain access” is too vague for a receiving checklist. ^{[22] [23]}

Performance and Benchmarks

There is no measured migration-speed or downtime benchmark in this report. The appropriate performance evidence is an observed functional record, scoped to the site's important journeys. A successful login or a visible home page is a useful observation, but neither demonstrates that a lead reaches the intended inbox or that the new team can recover the site.

Table 2 is a receiving-party record to complete in the agreed environment. Proposed checks are recommendations, not claims that any website has passed them.

The result column should contain what happened, rather than a blanket “website approved.” Stripe recommends sandbox transactions that move no funds and documents test scenarios; use the applicable processor's instructions instead of improvising a real charge. The account's payout and business settings remain a separate confirmation from simulated checkout behavior. ^{[24] [19]}

For forms, verify the destination and the integration's actual rules. Mailchimp, for example, has audience-level notification settings and says integration-based subscription notifications require double opt-in in the integration settings. A missing notification can reflect configuration, not simply whether a visible form submitted. Record the expected outcome before running the check. ^[25]

For accessibility, include relevant W3C Easy Checks, such as keyboard access, visible focus, forms, headings, and text resizing. W3C explicitly says the checks are preliminary. Passing the selected checks cannot establish comprehensive accessibility conformance, and this report makes no such determination. ^[10]

Recovery evidence should match the platform. For a WordPress backup, identify both components and demonstrate the documented restore route. For Webflow, confirm the receiving role can actually access backups. Agree responsibility and continuity before rotating credentials, removing supplier access, or changing production settings. ^{[6] [15]}

Data Analysis and Evidence

The quantitative value of this comparison is documented operating conditions, not invented migration prices or estimated downtime. The audit covers four platforms, with a separate WordPress.com distinction. No account-specific subscription quotes were collected, so there is no defensible universal ongoing-cost total. Similarly, no transfer was executed, and the report cannot supply a measured completion time or failure rate.

Timing has different meanings. Shopify's developer documentation says pending client-transfer invitations expire after seven days. ICANN's applicable transfer policy describes a 60-day inter-registrar lock following a change of registrant, with a possible registrar-offered opt-out before the change. These are an invitation deadline and a registrar-transfer restriction, not website migration durations. Check the relevant top-level domain and registrar; do not generalize this framework to every country-code domain. (Source: shopify.dev) ^[26]

ICANN also describes a five-calendar-day response window after a registry transfer notification, with default approval if the registrar does not respond. That clock has a specific trigger. It does not establish an end-to-end handover promise, nor does it measure DNS propagation, content migration, testing, or the receiving team's acceptance work. ^[26]

Billing continuity is conditional. Webflow distinguishes a supplier-funded site's prorated Workspace credit from a client-funded site's continued billing. A domain account push has another service boundary: Namecheap says related services need separate actions. Reconcile each existing account and its continuing services before calculating the recipient's future cost. Record credits separately from new charges, using the actual account statements. ^{[2] [23]}

For an ongoing-cost worksheet, use only the reader's actual quotes:

• Monthly equivalent: divide an annual recurring charge by the months it covers, while separately recording the actual annual cash payment.
• Comparable total: add only items in the same currency and on the same tax basis; keep usage-based or unquoted charges separate.
• Complete inventory: include platform hosting, apps, fonts, forms, email, monitoring, and maintenance where they are actually subscribed.

A license can change the continuity calculation without changing project ownership. Adobe Fonts says a client's site must use the client's Creative Cloud subscription; canceling the existing subscription makes its web fonts unavailable. Google Fonts permits local self-hosting subject to the chosen font's license and places manual updates with the developer. Record the actual dependency before estimating renewal cost. ^{[27] [28]}

Role counts also matter. Google Tag Manager recommends at least two active administrator accounts, individual logins, and management within the organization. Its container Edit role cannot create versions or publish. The inventory should therefore record both account administration and the publishing capability needed for the next change. ^[29]

Implications and Future Directions

The next supplier transition becomes easier to assess when the business has an account inventory that can be checked against actual logins, bills, and recovery methods. The template below is a working document, not a place to collect passwords, recovery codes, private keys, or payment-card details. Stripe specifically recommends keeping live application programming interface (API) keys in a secrets vault or environment variables. ^[24]

Table 3 is a blank inventory template. Create separate rows for products that use different accounts or billing relationships, even when they support the same website.

The inventory makes unresolved dependencies visible without pretending they transfer automatically. Mailchimp permits only one Owner even though several Admins are possible. Google Analytics has separate user-management permissions. Stripe has its own owner-transfer process, requiring an eligible user and acceptance of a team invitation first. Confirm each service independently. ^{[30] [13] [31]}

Follow this transition order, adjusted to the site's agreed continuity requirements:

• Assign people: name the outgoing supplier, receiving owner, billing contact, publisher, and recovery operator.
• Confirm authority: verify transfer eligibility, destination account, licensed rights, and required subscriptions before changes.
• Capture the current state: save agreed exports, backups, integration references, and the existing DNS record inventory.
• Agree the sequence: specify which services move, which stay, and when acceptance and access changes occur.
• Execute the documented paths: have the authorized people initiate and accept each actual account transfer.
• Observe the site: complete the functional record and document billing, permissions, and recovery outcomes.
• Close deliberately: assign every open item, agree continued supplier access, and then implement the agreed access changes.

DNS changes deserve particular care in that sequence. Cloudflare says automatic record discovery is not guaranteed to find every record and instructs teams to review website and email records. Include mail exchanger (MX) and relevant Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) records as required by the mail provider. ^[32]

Code repositories also have their own transfer behavior. GitHub keeps webhooks, services, secrets, and deploy keys attached to a transferred repository, while GitHub Pages sites do not receive the repository's automatic redirects. Record external deployment ownership separately and verify the actual destination. A repository transfer is not evidence that every connected service changed owner. ^[33]

For recovery planning, identify the account's documented route while the relevant people are available. GoDaddy's recovery guidance distinguishes having access to the account email from losing that access. Do not treat possession of a delegated login as a substitute for an agreed owner and recovery contact. ^[34]

Frequently Asked Questions (FAQs)

What is included in a website ownership transfer?

Define it in the scope: project ownership, account roles, registrar and DNS control, billing, downloadable materials, licensed dependencies, integration settings, and acceptance evidence. The exact package varies. WordPress's WXR export, for example, excludes configuration options and attachment files themselves, so “all website files” needs a more precise definition. ^[11]

Who owns a website built by an agency?

Check the contract and applicable law, then check operational accounts separately. WIPO's commissioned-work guidance explains why written ownership terms matter. An agency's platform login, the client's payment of an invoice, and a folder of delivered graphics are not a substitute for clearly documented rights and licenses. (Source: www.wipo.int)

Must the domain and hosting move together?

They can be distinct operations. A connected Shopify third-party domain stays with its registrar. Namecheap's internal domain push preserves DNS but does not automatically move every related service. Record the required registration, DNS, hosting, and email outcomes separately. ^{[9] [23]}

What should be asked before approving the build scope?

• Where will the live project reside? Name the business-controlled destination and the supported transfer path.
• What can be downloaded? Specify source, content, media, configuration, and the intended recovery or deployment use.
• What needs a new subscription? Name the payer, license holder, quote, renewal date, and any usage charges.
• Who can make the next update? Specify publishing, user-management, and recovery roles, not just an editor invitation.
• What proves acceptance? Agree the observed functional checks, evidence, unresolved-item owner, and support arrangements.

What should the receiving party sign off?

Use a short acceptance statement: “The named receiving accounts have the recorded roles; the listed materials were received; the agreed checks produced the recorded results; remaining issues have named owners and next actions.” Keep the supporting inventory and functional record attached. Limit the statement to what was observed; W3C's distinction between preliminary checks and comprehensive evaluation is a useful model for that discipline. ^[10]

Conclusion

A useful website handover leaves the receiving organization able to make its next agreed change, pay the right subscriptions, reach its customers, and follow a documented recovery route. The handover package should make each of those outcomes reviewable. A project owner label is one piece of evidence, and the inventory and functional record supply the rest.

The platform comparison should guide the scope before commissioning and the sequence before transition. Choose the correct hosted-transfer path, identify the accepting account, distinguish any code or content export, and record the billing consequence. Treat external registration, licensed dependencies, integrations, and retained supplier access as named items with their own owners. Those distinctions prevent a single “website transferred” checkbox from hiding unfinished work.

The receiving team should accept evidence at the level actually tested. A form receipt supports that form journey; a restored backup supports that recovery exercise. Neither warrants an unqualified statement about every feature or future condition. Keep untested work and unresolved issues visible, with a responsible person and an agreed next step.

Finally, preserve continuity while responsibility changes. Agree the access and production-change sequence before acting, confirm the actual account outcomes, and retain the records needed by the next operator. The practical endpoint is a business that knows what it controls, what it licenses, what it pays for, and who can take the next action.