Ownership Transfer Terms

These Ownership Transfer Terms describe when a customer may become eligible to receive ownership, control, access, export, or handoff of customer-specific website deliverables and related customer-controlled accounts or data for the applicable Sites customer relationship.

1. Role Of These Terms

1.1 Transfer framework. These Terms describe the conditions and process for transfer review, Transfer Package preparation, Sites Asset exclusions, third-party license limits, platform handoff, domain/account/data access handoff, default-related transfer holds, and post-transfer responsibilities.

1.2 Relationship to Order Form. The Order Form controls customer-specific commercial facts, selected plan, term, launch destination, customer domain, platform assumptions, migration scope, add-ons, and any customer-specific transfer entries.

1.3 Relationship to MSA. The Master Services Agreement controls the core relationship, intellectual property framework, customer responsibilities, platform/vendor dependencies, warranties/disclaimers, and risk allocation.

1.4 Relationship to payment and default documents. The Subscription / Payment Terms, Payment Authorization, and Default / Nonpayment Terms control payment status, Account Standing, default, disputes, chargebacks, settlements, write-offs, restoration, and transfer withholding for unresolved payment or default issues.

1.5 Relationship to scope and migration documents. The Scope Appendix and Migration Appendix control website scope, migration scope, customer materials, platform limits, access, Launch, Move-in Complete, and related records.

1.6 No immediate transfer of Sites-controlled items. Customer does not receive immediate ownership, unrestricted control, project export, workspace transfer, source files, design files, reusable Sites assets, or transfer rights in Sites-controlled items at signup, kickoff, build, review, Launch, or before satisfying the transfer eligibility conditions in these Terms. This does not limit Customer's pre-existing rights in Customer Materials, customer-owned domains/accounts, or customer business data.

1.7 No public-material expansion. Pricing pages, sales discussions, proposals, account messages, Help Center articles, checkout screens, onboarding flows, support messages, and portfolio or case-study references do not expand transfer rights unless the expanded transfer right is included in the signed Order Form, signed amendment, signed transfer package, or signed settlement-transfer record.

1.8 Issue-specific priority. These Terms control ownership-transfer eligibility review, Transfer Package records, itemized transfer methods, Sites Asset exclusions, third-party license treatment, platform handoff records, domain/account/data access handoff records, credential/offboarding transfer records, and ownership-transfer claim controls. The Order Form controls customer-specific facts and customer-specific transfer entries. The Scope Appendix and Migration Appendix control website, migration, launch, and platform records. Payment authority and payment economics are controlled by the payment documents. Default/remedy treatment and transfer holds are controlled by the Default / Nonpayment Terms and required default records. Tax and accounting treatment remains subject to tax/accounting records.

2. Defined Transfer Terms

2.1 "Customer-Specific Website Deliverable" means the completed customer-specific website implementation created for Customer under the signed Order Form and signed scope, excluding Sites Assets, nontransferable third-party assets, Sites systems, platform accounts, and items excluded by these Terms. This definition does not by itself decide copyright ownership, work-made-for-hire status, assignment status, implied-license scope, tax treatment, or platform transfer capability.

2.2 "Customer Materials" means Customer-provided content, copy, images, videos, logos, trademarks, brand assets, business information, account data, and other materials supplied by Customer or on Customer's behalf.

2.3 "Sites Assets" means Sites' reusable templates, reusable platform components, design systems, Sites systems, reusable methods, operational materials, proprietary methods, generic materials, non-customer-specific materials, and reusable service assets.

2.4 "Transfer Package" means the specific customer-specific items, access, files, control changes, records, and exclusions approved for handoff after transfer eligibility review.

2.5 "Transfer Eligibility" means Customer satisfies the conditions in Section 4 and Sites completes the required transfer eligibility record.

2.6 "Account Standing" means all material amounts required for transfer eligibility under the signed documents are paid or otherwise resolved under a signed customer-visible payment, settlement, credit, waiver, restoration, or Default Resolution Record that expressly states the account-standing result and transfer effect, with no documented unresolved payment default, unresolved dispute after triage, unresolved chargeback, suspension condition, or transfer-blocking issue that is material to the requested transfer. An accounting write-off, uncollectible invoice status, chargeback loss, accounting cleanup, or processor report does not by itself create Account Standing, waive rights, approve transfer eligibility, close a dispute, or decide tax/accounting treatment.

2.7 "Platform-Limited Handoff" means a transfer, access change, export, collaborator change, account handoff, customer rebuild package, or no-transfer decision based on platform capability, account ownership, license terms, security review, and technical feasibility.

2.8 "Transfer Method" means the exact approved mechanism for a Transfer Package item, which may include assignment, license, access change, collaborator-role change, export, copy, credential rotation, account handoff, third-party subscription transition, continued hosted access, no-transfer decision, or another written pathway. No Transfer Method is approved unless it is listed in the final transfer record.

2.9 "Write-Off Record" means an accounting or collections record for an amount Sites does not expect to collect or has chosen not to pursue in a particular accounting workflow. A Write-Off Record is not a customer-visible waiver, settlement, credit, restoration, release, Account Standing decision, transfer approval, bad-debt tax conclusion, or collection decision unless a separate signed customer-visible record states that exact effect.

2.10 "Transfer-Blocking Status" means a documented unresolved condition after triage that is material to the requested transfer item or Account Standing and prevents transfer review from closing, such as unresolved payment default, unresolved good-faith dispute, unresolved chargeback, unresolved settlement condition, unresolved security/access incident, unresolved platform ownership issue, unresolved license block, unresolved customer-location/tax record, or unresolved legal, tax/accounting, platform, privacy, or security review item. The historical existence of a refund, credit, reversal, chargeback, dispute, settlement, or write-off is not transfer-blocking after the signed resolution record resolves its transfer effect.

3. Transfer Principles

3.1 Conditional transfer model. Customer may become eligible for review and preparation of a Transfer Package only after full successful completion of the 24-month managed-service commitment, Account Standing, no unresolved Transfer-Blocking Status, completed transfer records, platform capability review, third-party license review, Sites Assets exclusion review, chain-of-title review, and completed offboarding/access review or signed exception record.

3.2 Customer-specific only. Transfer eligibility applies only to customer-specific deliverables and customer-controlled accounts/data. It does not apply to Sites Assets, reusable systems, platform accounts retained by Sites, nontransferable third-party assets, or items excluded by these Terms.

3.3 Platform capability condition. No transfer term promises a Framer project export, Framer project transfer, Framer workspace transfer, source-code transfer, design-file transfer, platform account transfer, full archive export, static self-host export, HTML export, or identical standalone copy unless the current platform capability, project facts, plan/account permissions, licenses, security review, and transfer record support that specific handoff.

3.4 Records-backed handoff. Transfer requires a transfer eligibility record, Transfer Package record, exclusion record, license record, account/access record, and final customer acknowledgment.

3.5 No automatic IP conclusion. Payment, Launch, Move-in Complete, term completion, Account Standing, transfer review, settlement, write-off, credit, chargeback outcome, or platform handoff does not by itself create a copyright assignment, work-made-for-hire conclusion, implied-license expansion, trademark transfer, platform account transfer, domain transfer, source-file transfer, or tax/accounting conclusion. The final transfer record must identify the exact Transfer Method and approved item.

4. Transfer Eligibility Conditions

Customer becomes eligible for transfer review only if all required conditions are satisfied:

4.1 Transfer term math record. Before term completion supports transfer eligibility, the record must identify signed Term Start, signup-payment treatment, whether the signup payment counts as term month 1, pre-launch service period, credit against a post-Launch invoice, deferred item, or other recorded treatment, required post-Launch invoice count, actual post-Launch invoices paid or resolved, no-duplicate-period review, first recurring service period, and last service period counted toward term completion.

4.2 No automatic eligibility. Satisfying one eligibility gate does not satisfy the other gates. Transfer eligibility is determined only after all required gates are complete or resolved by a signed exception.

4.3 No automatic transfer. Transfer Eligibility permits transfer review and Transfer Package preparation only. Actual transfer or handoff of any item still depends on itemized approval, platform capability, rights clearance, security/offboarding completion, and a signed transfer record identifying the exact item and Transfer Method.

5. Items That May Transfer Or Be Handed Off

Subject to Transfer Eligibility, platform capability, license limits, security review, and the transfer record, the Transfer Package may include:

• Customer-Specific Website Deliverable or control pathway where platform-supported;

• customer-provided content;

• customer-owned logo, trademarks, brand assets, media, and files provided by Customer;

• customer business data and customer-provided data;

• domain control if Customer owns or controls the domain;

• DNS access handoff, revocation, or adjustment where Customer owns or controls the domain/DNS account;

• analytics access, Search Console access, or connected account access where Customer owns or controls the account;

• form submissions, CMS records, and integration data where platform-supported and security-cleared;

• customer-specific launch, migration, redirect, and handoff records reasonably needed for transition; and

• customer-specific export or access package if the platform supports it and the transfer record approves it.

5.1 Transfer method required. Each Transfer Package item must identify the Transfer Method, item owner if known, included/excluded status, platform capability, third-party license status, security/offboarding step, customer responsibility, and tax/accounting record if the item has payment, settlement, write-off, credit, domain, platform, or separately priced value implications.

5.2 No all-assets transfer. A phrase such as ownership transfer, handoff, website ownership, or Transfer Package must not be interpreted to include every file, account, source, component, record, asset, license, credential, Sites-controlled system, reusable method, operational material, template, domain, platform, integration, or third-party tool unless that specific item is listed as included in the final Transfer Package.

5.3 Transfer Package schedule. The Transfer Package record should use an itemized schedule or equivalent before any item is marked transferable. The schedule should identify the included item, item owner if known, transfer path, exclusion status, platform limits, license limits, required access changes, customer responsibility, and payment or tax/accounting record where applicable.

5.4 Chain-of-title record. Before a customer-specific deliverable, source/design file, code component, plugin, integration, media asset, AI-assisted output, contractor output, subcontractor output, or vendor material is marked transferable, the record should identify authorship/source chain, contractor assignment evidence if applicable, subcontractor flow-down evidence if applicable, pre-existing materials disclosure, AI-tool output record if applicable, third-party license status, open-source/copyleft status if applicable, no-transfer/no-sublicense restrictions, and unresolved IP questions.

6. Items That Do Not Transfer

Unless a later signed amendment expressly says otherwise after IP/platform review, Sites does not transfer:

• reusable templates;

• reusable platform components;

• reusable design systems;

• generic design patterns;

• Sites systems, reusable methods, and operational materials;

• business systems;

• records not customer-specific;

• proprietary methods;

• non-customer-specific materials;

• source files or design files not listed in the Transfer Package;

• platform workspaces or projects Sites must retain for other customers or service operations;

• third-party assets, fonts, plugins, media, scripts, software, subscriptions, or licenses that cannot transfer;

• contractor/vendor work product that Sites cannot transfer under applicable license or assignment terms;

• open-source/copyleft, marketplace-template, platform plugin/code component, AI/model-output, stock/font, hosted-service, vendor-account, or no-sublicense/no-transfer materials that are not cleared for the exact Transfer Method; or

• any item not listed in the final Transfer Package.

6.1 Retained records. Sites may retain records, logs, notes, accounting/tax records, claim substantiation records, support records, legal-risk records, security records, and audit records needed for legal, tax, accounting, security, dispute, compliance, support, or service operations purposes, even if a customer-specific deliverable or customer-controlled account is handed off.

6.2 Retention and hold routing. Retained-record treatment should identify record category, retention reason, retention period or review date, return/export path if applicable, deletion/archive trigger, legal/accounting/security hold status, and customer-data sensitivity for credentials, form submissions, analytics exports, customer data, incident records, platform logs, transfer records, tax/accounting records, and support records.

7. Framer And Platform Handoff

7.1 Active-term control. During the active term, Sites may control or manage the Framer workspace/project and related platform setup to host, maintain, update, support, secure, and protect the service.

7.2 No unconditional Framer transfer promise. No term promises a Framer workspace transfer, project transfer, project duplication, static self-host export, HTML export, source-code export, design-file export, or standalone replacement package unless current Framer capability, the specific project, plan, licenses, account permissions, reusable-asset protection, and transfer record support that pathway.

7.3 Possible handoff pathways. A Framer/platform handoff may use one or more of the following pathways:

• transfer of customer-specific project control where supported;

• collaborator access change;

• account ownership or workspace role adjustment where supported;

• CMS/data export or customer rebuild package where supported and verified for the specific project;

• domain/DNS access change;

• continued hosted access under a post-term support or hosting arrangement;

• no-transfer decision for platform-limited or license-limited items;

• future non-Framer or changed-platform export pathway only if the official platform capability, project facts, and transfer record support it; or

• another signed transfer pathway listed in the transfer record.

7.4 Reusable asset protection. If a customer-specific project contains Sites Assets, reusable components, templates, service structures, or third-party materials, Sites may remove, replace, retain, disable, license, or exclude those items before transfer to protect Sites and third-party rights.

7.5 Platform fees and accounts. Customer is responsible for any post-transfer platform fees, hosting fees, domain fees, app/integration fees, subscription fees, account setup, vendor approvals, and account maintenance unless a signed post-transfer service arrangement says otherwise.

7.6 Platform verification record. Before a Framer or platform handoff is approved, the transfer record must identify workspace/project owner, account ownership classification, project ID or equivalent identifier, current plan/workspace status, site-plan/billing owner, collaborator roles, transfer/export capability, hosting/custom-domain dependency, reusable Sites Assets present, third-party materials present, platform fees and payment path, customer account readiness, offboarding steps, remaining Sites access if any, no-transfer reason if any, and known limitations.

8. Domain, DNS, Analytics, Search Console, Forms, CMS, And Integrations

8.1 Domain. The transfer record must identify domain owner, registrar, DNS provider, account owner, account ownership classification, delegated-access status, launch destination, active DNS dependencies, MFA status, registrar-lock status, DNS record inventory, emergency access path, authorized change and rollback path, final post-handoff access state, and any access, lock, or offboarding issue. Customer controls Customer-owned domains; the signed documents may define Sites' delegated access, management role, support role, or transition steps, but do not transfer Customer's domain ownership unless they expressly say so.

8.2 Domain handoff. After Transfer Eligibility, Sites may return, revoke, adjust, or document Sites' delegated domain/DNS access based on account ownership, security, platform capability, and transfer records. This does not authorize Sites to revoke Customer's ownership or control of a Customer-owned domain.

8.3 Analytics and Search Console. The transfer record must identify owner/admin, account ownership classification, property IDs, Search Console property type, verified owner, permission level, connected email/account, verification method, verification token location, token removal or transfer path, tag/container IDs if applicable, Sites access role if any, transfer/offboarding path, final evidence, customer admin confirmation, and platform limits for Customer business data, analytics data, Search Console data, and related customer accounts. Sites may need access during the term to manage, maintain, migrate, report, and support the website.

8.4 Forms, CMS, and integrations. Forms, CMS records, integrations, API keys, tags, pixels, CRM connections, booking tools, menu tools, and other connected accounts may be handed off, exported, revoked, rotated, converted, or excluded depending on platform capability, account ownership, security review, privacy review, vendor terms, and transfer records.

8.5 Secrets and credentials. API keys, passwords, tokens, secrets, OAuth grants, delegated access, and collaborator permissions must be handled under the credential/access/offboarding process. Secrets may need rotation, revocation, replacement, or customer reconfiguration at handoff.

8.6 Privacy/cookie/security handoff. Forms, pixels, tags, CRM connections, booking tools, email/SMS tools, analytics properties, API keys, and integrations may require privacy, cookie, security, and vendor review before handoff, revocation, export, or continued use. Transfer does not authorize silent tracking carryover or unmanaged credential transfer.

8.7 Account ownership classification. Each material account should be classified as customer-owned, Sites-owned, prior-agency-owned, mixed ownership, unknown ownership, or newly created. The classification should be captured for domain, DNS, registrar, Framer workspace/project/site, Google Analytics, Search Console, Tag Manager, forms, CMS, CRM, booking, email/SMS, tags, pixels, API keys, and material integrations. Unknown, mixed, prior-agency-owned, or disputed ownership should remain a transfer blocker or exception item until resolved under the signed documents or written transfer process.

8.8 Credential/access/offboarding evidence. Credential and access records should identify vault/delegated-access method, MFA status, raw-password exception reason if any, emergency access owner, token/API-key rotation date, access review date, contractor/vendor access issue if any, revocation evidence, deletion evidence, final remaining Sites access, customer admin confirmation, and incident/security exception status.

8.9 Incident and closeout gate. Transfer closeout should remain open if any privacy, security, platform-access, credential, domain/DNS, data-export, or tracking incident remains unresolved unless a signed exception record identifies incident owner, escalation status, corrective action, customer communication status, interim risk control, final signoff, and follow-up date.

9. Third-Party Assets, Licenses, And Vendor Materials

9.1 License condition. Third-party assets transfer only if the applicable license, vendor terms, platform capability, account ownership, and transfer record permit transfer.

9.2 Nontransferable items. Nontransferable fonts, media, stock assets, plugins, scripts, templates, components, vendor subscriptions, hosted services, platform accounts, marketplace templates, Framer plugins/code components, open-source/copyleft materials, AI/model-output materials, no-sublicense assets, no-transfer assets, or licenses must be excluded, replaced, licensed separately, or handled through another signed transfer pathway.

9.3 Customer-provided third-party materials. Customer is responsible for confirming that Customer-provided third-party materials may be used, migrated, published, transferred, or handed off.

9.4 Vendor accounts. If a vendor account must be created, transferred, assigned, or separately subscribed to, Customer is responsible for vendor approval, vendor fees, account setup, and compliance with vendor terms unless a signed scope says otherwise.

9.5 License evidence. Before transferring, licensing, exporting, replacing, or excluding a third-party item, Sites must record the item, source/vendor, account owner, license status, license category, attribution requirement, transfer/sublicense permission, open-source/copyleft flag, marketplace-template flag, Framer plugin/code component flag, AI/model-output restriction if any, hosted-service/vendor-account limit, restriction or uncertainty, replacement option if needed, and customer responsibility.

10. Customer Materials

10.1 Customer ownership. Customer retains ownership or control of Customer Materials, subject to Customer's rights, licenses, permissions, and third-party restrictions.

10.2 Customer license to Sites. Customer authorizes Sites and its service providers to use Customer Materials during the term and any required transition or offboarding period for the limited purpose of providing the services, building and maintaining the website, migrating content, publishing approved content, supporting integrations, and performing related service tasks under the signed documents.

10.3 Customer responsibility. Customer is responsible for the accuracy, legality, ownership, permissions, rights, and approval of Customer Materials.

10.4 Return or access. After Transfer Eligibility or offboarding, Customer Materials may be returned, made accessible, exported, left in customer-controlled accounts, or otherwise handled according to platform capability, security review, and transfer records.

10.5 Customer Materials do not expand transfer. Customer ownership of Customer Materials does not create ownership of Sites Assets, reusable templates, platform workspaces, source files, contractor/vendor materials, third-party assets, or Sites systems.

10.6 Customer-owned carveout. Transfer withholding or ineligibility does not by itself authorize Sites to block access to or retain customer-owned materials, customer-owned domains/accounts, customer business data, legally sensitive notices, security/privacy communications, required incident communications, or required offboarding access except through a documented risk workflow under the signed documents. This carveout does not expand transfer of Sites Assets, third-party assets, platform accounts, or unsupported export rights.

11. Transfer Withholding, Default, And Early Termination

11.1 No transfer during unresolved material blocker. Customer is not eligible for ownership transfer if a documented payment, term, default, dispute, chargeback, refund, settlement, write-off, access, security, platform, or transfer condition remains unresolved after triage and is material to the requested transfer item or Account Standing. A resolved historical refund, credit, chargeback, reversal, dispute, settlement, or write-off is not transfer-blocking unless the signed resolution record says it remains transfer-blocking.

11.2 Transfer withholding. Any transfer hold may apply only to the extent supported by the signed documents and requires a signed transfer-hold or default record, customer notice where required, and preservation of customer-owned materials, customer-owned accounts, required security/privacy communications, and required offboarding access under Section 10.6.

11.3 Early termination. Early cancellation, abandonment, nonpayment, suspension, or termination before Transfer Eligibility does not automatically trigger ownership transfer, project export, source-file transfer, platform handoff, or customer control transfer.

11.4 Settlement exception. Sites may approve a settlement-transfer exception only by signed record identifying the settlement amount, payment timing, account-standing result, transfer effect, release or non-waiver status, allocation among unpaid plan fees, taxes, add-ons/extra time, migration/scoped work, credits, write-offs, refunds, Transfer Package items, handoff/support items, and domain/platform/vendor fees, collection effect, tax/accounting record where applicable, Transfer Package, excluded assets, platform pathway, license limits, access/offboarding steps, and customer-visible resolution record.

11.5 Customer delay and abandonment transfer gate. Customer delay, abandonment, missing access, unresolved migration status, or missing approval may support a transfer hold only after the transfer record checks Sites-side delay, platform/vendor limits, unclear requests, good-faith disputes, refund/credit exception review, notices, objective work/capacity evidence, customer communications, next-action owner, and required escalation.

11.6 Rejected default remedies. These Terms do not make acceleration, liquidated damages, or automatic remaining-term collection the standard launch remedy. Default treatment is governed by the Default / Nonpayment Terms.

11.7 No accounting/tax treatment by withholding. Transfer withholding, settlement transfer, chargeback status, refund status, write-off status, credit status, or restoration status does not decide book revenue recognition, tax income inclusion, bad-debt treatment, refund/credit accounting, sales-tax treatment, or asset-transfer tax treatment. Those remain tax/accounting-policy review items.

11.8 Accounting write-off neutrality. A Write-Off Record does not by itself create Account Standing, waive customer obligations, authorize transfer, approve collection closure, establish bad-debt tax treatment, decide refund/credit accounting, or close a dispute. The customer-visible Default Resolution Record must state the account-standing, transfer, collection, tax/accounting, and customer communication effects.

12. Transfer Review Process

12.1 Transfer request. Customer may request transfer review after the 24-month term is complete or as part of a signed settlement or exception workflow.

12.2 Eligibility review. Sites must review and record term-completion math, Account Standing, Default Resolution Record status, Transfer-Blocking Status, settlement-transfer allocation if any, add-ons/extra work, migration status, customer-delay/abandonment gate, platform capability, account ownership classification, third-party licenses, Sites Assets, chain of title, customer-owned carveout, customer data, credential/access status, privacy/security incident status, retention/hold routing, tax/accounting record, payment reporting records if applicable, and offboarding tasks.

12.3 Transfer decision statuses. Sites may classify the transfer decision as:

• not eligible because term is incomplete;

• not eligible because payment default remains unresolved;

• not eligible because Transfer-Blocking Status remains unresolved;

• not eligible because of platform limits;

• not ready because required legal or tax/accounting input is incomplete;

• not ready pending privacy/security/offboarding review;

• not ready pending platform or license review;

• not ready pending account ownership review;

• settlement exception pending;

• eligible with exclusions;

• eligible and prepared for handoff;

• settlement-transfer exception;

• transfer completed; or

• transfer declined or closed.

12.4 Transfer Package record. The Transfer Package record must identify included items, excluded items, item owner, account ownership classification, Transfer Method, platform limitations, third-party license notes, Sites Assets exclusions, chain-of-title evidence, credential/access action, privacy/security status, tax/accounting record, customer responsibilities, access changes, post-transfer fees, and customer acknowledgment.

12.5 Transfer evidence record. The Transfer Package record must also identify the document basis, customer account, payment and account-standing evidence, Term Start, payment records, Default Resolution Record if any, dispute/refund/credit/settlement status if any, Launch and Approval date, term-completion evidence, migration status, customer-controlled account evidence, account ownership record, chain-of-title record, license record, customer-owned carveout review, privacy/security/offboarding status, tax/accounting record where applicable, and final transfer decision.

12.6 Settlement allocation record. A settlement-transfer exception record must identify settlement amount, payment schedule, nonpayment/default status, Account Standing result, transfer effect, collection effect, release or non-waiver status, allocation among unpaid plan fees, taxes, add-ons/extra time, migration/scoped work, credits, write-offs, refunds, Transfer Package items, handoff/support items, and domain/platform/vendor fees, tax/accounting record where applicable, and any deferred or excluded items.

12.7 Transfer payment, tax, and accounting record. If the transfer event, settlement, write-off, credit, refund, handoff item, export item, domain/platform fee, vendor fee, included Transfer Package value, or post-transfer support has payment, tax, or accounting implications, the record should identify service period, allocation, earned or deferred treatment, customer location facts, sourcing/taxability review, exemption/tax ID status if any, filing or remittance status if applicable, refund/credit/reversal treatment, domain/vendor fee classification, and support for payment and accounting records.

12.8 Timing. Transfer timing depends on customer cooperation, Sites-side readiness, platform capability, account ownership, third-party vendor response, security review, incident closeout, license review, payment/account standing, tax/accounting input where implicated, and completion of transfer records. Customer delay, abandonment, missing access, unclear requests, or unresolved migration status should not be used as a transfer blocker unless the Section 11.5 gate is completed or a signed exception record explains the hold.

13. Post-Transfer And Offboarding

13.1 Post-transfer responsibility. After transfer or handoff, Customer is responsible for managing, paying for, maintaining, securing, updating, renewing, and backing up transferred or customer-controlled accounts, platforms, domains, subscriptions, integrations, and data unless a signed post-transfer service arrangement, express warranty, required security/privacy duty, or non-waivable obligation says otherwise.

13.2 Sites access. Sites may revoke, reduce, or convert its access after transfer or offboarding. Sites may retain limited records needed for legal, accounting, tax, security, support, audit, dispute, or service operations purposes.

13.3 Support after transfer. Post-transfer support is not included unless the Order Form, renewal, add-on, or signed support scope says otherwise.

13.4 No ongoing outcome obligation. Transfer does not create ongoing obligations for search results, platform behavior, uptime, integrations, vendor tools, customer edits, third-party changes, or post-transfer customer modifications except to the extent required by a signed post-transfer service arrangement, express warranty, Sites-caused issue, required security/privacy duty, or non-waivable obligation.

13.5 Post-transfer fee classification. Any post-transfer platform, domain, vendor, hosting, handoff, export, support, rebuild, or access fee should be classified before invoicing or recording as customer-direct vendor payment, Sites-billed pass-through/reimbursement, bundled service fee, separately priced handoff/export/support fee, settlement allocation item, included Transfer Package value, or excluded item. The record should identify tax/accounting treatment, customer-location information where relevant, payment path, and customer responsibility.

14. Transfer Records

Sites must maintain transfer records appropriate to the transfer pathway, including customer, plan, launch, term, payment standing, default, dispute, refund, credit, settlement, migration, account-control, platform-capability, reusable-asset, license, chain-of-title, analytics, credential, privacy/security, offboarding, transfer-package, customer-acknowledgment, excluded-asset, platform-limitation, and tax/accounting records where applicable.

15. Transfer Claim Controls

15.1 No broad transfer claims. Sites must not represent that Customer receives immediate ownership, full website ownership, source-code ownership, design-file ownership, Framer workspace ownership, platform account ownership, domain ownership, analytics ownership, Search Console ownership, all-assets transfer, all-files export, or standalone self-hosting capability unless the exact item and Transfer Method are supported by the signed documents, platform capability, license review, and transfer record.

15.2 Claim-specific evidence. Each ownership-transfer, platform-handoff, account-transfer, export, source-file, design-file, domain/DNS, analytics/Search Console, or post-transfer support claim must be supported by item-specific evidence and must identify the exact claim text, intended surface, signed scope or transfer record, known limits, customer responsibility, and supporting record.