Ownership Transfer Terms

These Ownership Transfer Terms are incorporated into the Order Form, Master Services Agreement, Scope Appendix, Migration Appendix, Subscription / Payment Terms, Payment Authorization, Default / Nonpayment Terms, and any signed add-on, amendment, settlement, transfer, or offboarding record between Sites (“Sites”) and the customer identified in the applicable Order Form (“Customer”). They describe when Customer may become eligible to receive ownership, control, access, export, or handoff of customer-specific website deliverables and related customer-controlled accounts or data.

1. Role Of These Terms

2.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.

2.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.

2.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.

2.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.

2.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.

2.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.

2.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.

2.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

3.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, internal 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.

3.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.

3.3 “Sites Assets” means Sites’ reusable templates, reusable platform components, design systems, internal systems, reusable methods, operational materials, proprietary methods, generic materials, non-customer-specific materials, and reusable service assets.

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

3.5 “Transfer Eligibility” means Customer satisfies the conditions in Section 4 and Sites completes the required transfer eligibility record.

3.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 internal 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.

3.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.

3.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.

3.9 “Write-Off Record” means an internal accounting or collections record for an amount Sites does not expect to collect or has chosen not to pursue in a particular accounting workflow. An 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.

3.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 Authority Challenge, 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, Authority Challenge, settlement, or write-off is not transfer-blocking after the signed resolution record resolves its transfer effect.

3.11 “Agency / End-Client Role Matrix” has the meaning stated in the Payment Authorization and identifies the contracting Customer, any agency or representative, any end client or site owner, billing party, payer, Payment Method owner, Launch Approval approver, requester roles, and customer-owned account or offboarding carveouts relevant to transfer or offboarding.

3. Transfer Principles

4.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.

4.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.

4.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.

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

4.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:

5.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.

5.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.

5.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.

6.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.

6.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, internal 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.

6.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.

6.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;

• internal systems, reusable methods, and operational materials;

• operating systems;

• service 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 internal 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.

7.1 Service records. Sites may retain service 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 internal operations purposes, even if a customer-specific deliverable or customer-controlled account is handed off.

7.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

8.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.

8.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.

8.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.

8.4 Reusable asset protection. If a customer-specific project contains Sites Assets, reusable components, templates, internal 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.

8.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.

8.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

9.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.

9.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.

9.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.

9.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.

9.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.

9.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.

9.7 Account ownership classification. Each material account should be classified as customer-owned, agency-owned, end-client-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, agency-owned, end-client-owned, prior-agency-owned, or disputed ownership should remain a transfer blocker or exception item until resolved under the signed documents, Agency / End-Client Role Matrix, or written transfer process.

9.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.

9.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.10 Access/export/token failure review. If Customer asserts blocked access, lost access, incomplete export, missing customer-owned data, residual Sites access, failed revocation, failed rotation, failed replacement, failed reconfiguration, credential misuse, token misuse, or incident-response failure for a transfer, handoff, access, export, revocation, rotation, offboarding, or customer-owned preservation item, the transfer record should identify the access/export/token incident packet, affected systems and accounts, ownership and customer-admin status, access chronology, export manifest, credential or token remediation record, source-of-truth conflict or gap memo, incident decision record if implicated, restoration or reconfiguration status, customer acknowledgment if any, and unresolved blockers before Sites completes, withholds, or closes the transfer or offboarding item.

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

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

10.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.

10.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.

10.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.

10.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

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

11.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.

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

11.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.

11.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 internal systems.

11.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.7 Customer-owned preservation proof. If a transfer hold, default review, suspension, access restriction, cancellation, Authorization Revocation, support dispute, lead-capture dispute, or offboarding issue affects a customer-owned domain, customer-owned account, customer business data, customer-controlled content, required notice route, security/privacy communication, incident communication, or required offboarding access, the transfer or offboarding record should identify the ownership classification, known admin, Sites access role, native access or audit record where available, customer admin status, export or restoration path, restriction reason if any, urgent restriction record if any, and final preservation status.

11. Transfer Withholding, Default, And Early Termination

12.1 No transfer during unresolved material blocker. Customer is not eligible for ownership transfer if a documented payment, term, default, dispute, Authority Challenge, 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, Authority Challenge, settlement, or write-off is not transfer-blocking unless the signed resolution record says it remains transfer-blocking.

12.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.

12.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.

12.3A Authorization revocation boundary. Authorization Revocation, payment-method removal, portal cancellation, or customer request to stop automatic billing does not by itself create transfer eligibility or a transfer hold. Transfer impact depends on the Cancellation Resolution Review, payment status, Account Standing, disputed and undisputed amount allocation, Default Resolution Record if any, customer-owned carveout review, and any signed settlement or transfer exception.

12.3B Authority challenge boundary. An Authority Challenge does not by itself create transfer eligibility or a transfer hold. Transfer impact depends on payment review, Good-Faith Dispute Hold status, disputed and undisputed amount allocation, Default Resolution Record if any, customer-owned carveout review, and any signed settlement or transfer exception.

12.3C Agency / end-client transfer boundary. If a transfer, handoff, access, domain, account, data, or offboarding request involves an agency, end client, third-party payer, domain/account owner, or other non-identical role, the transfer review should identify the Agency / End-Client Role Matrix, requester identity, requester authority basis, account/data ownership classification, customer-owned carveout status, disputed and undisputed amounts if any, and any end-client acceptance or agency authority certificate before Sites releases, withholds, transfers, exports, revokes, or closes the affected item.

12.3D Credit / cancellation / default transfer boundary. A credit, make-good, no-credit outcome, settlement, cancellation request, Good-Faith Dispute Hold, manual invoice, corrected notice, default pause or release, or accounting write-off does not by itself create Account Standing, transfer eligibility, transfer ineligibility, transfer hold, or transfer release. Transfer effect should be stated in the Credit / Cancellation / Default Resolution Record, Default Resolution Record, settlement-transfer exception, or final transfer record before Sites relies on that item for transfer, handoff, access, export, or offboarding decisions.

12.3E Source-of-truth transfer and offboarding boundary. A processor status, dashboard label, support note, screenshot, internal summary, missing export, or corrected notice does not by itself decide transfer eligibility, transfer hold, customer-owned access, data export, or offboarding status. If those facts are disputed or incomplete, the transfer review should identify the designated source of truth, native export or audit trail where available, conflicting record if any, corrected notice status if any, customer-owned preservation status, and reviewer before Sites relies on the item for transfer, handoff, access, export, or offboarding decisions.

12.3F Access/export/token incident boundary. An access restriction, missing export, token or credential issue, residual Sites access issue, customer-admin disagreement, or incident triage issue does not by itself decide transfer eligibility, transfer hold, customer-owned preservation, or offboarding completion. If those facts are disputed or incomplete, the transfer review should identify the access/export/token incident packet and any affected payment, default, privacy/security, platform, support, customer-owned, or offboarding records before Sites relies on the item for transfer, handoff, access, export, or offboarding decisions.

12.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.

12.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.

12.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.

12.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.

12.8 Internal write-off neutrality. An 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

13.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.

13.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, Agency / End-Client Role Matrix if applicable, requester authority basis if applicable, 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.

13.2A Native record and preservation review. Where transfer or offboarding depends on access history, account ownership, platform capability, customer data, default status, support status, corrected notice status, or customer-owned carveout status, the review should identify native platform, vendor, processor, support, account, access, export, or audit records where available; any internal reconstruction or screenshot limits; any unresolved gaps; and any preservation, restoration, export, revocation, rotation, or customer-admin confirmation evidence.

13.2B Access/export/token incident review. Where transfer or offboarding depends on actual access, export completeness, customer-owned data preservation, credential/token remediation, residual Sites access, or incident handling, the review should identify access chronology, export completeness manifest, credential/token remediation path, incident decision record, source-of-truth conflict or gap memo, customer-admin confirmation, restoration or reconfiguration evidence, customer-visible communication status, and reviewer status.

13.2C Service impact and event-level causation review. Where transfer or offboarding depends on an alleged outage, partial outage, failed event, missing submission, missed booking, delayed routing, unavailable surface, vendor limitation, platform limitation, DNS issue, customer-account issue, customer-owned data issue, export/reconciliation issue, or mixed-cause service impact, the review should identify the service impact and event-level causation review record, affected event window, affected system or surface, vendor or platform status, customer dependency status, Sites-controlled configuration or support status, per-event reconciliation where available, export or missing-item explanation if any, source-of-truth conflict or gap memo if any, customer-visible communication status, and reviewer status.

13.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.

13.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.

13.5 Transfer evidence record. The Transfer Package record must also identify document basis, Order Form ID, customer ID, payment/account-standing evidence, signed Term Start, term-month numbering, signup-payment treatment, first post-Launch recurring service period, required post-Launch invoice count, no-duplicate-period check, payment records, Default Resolution Record, dispute/chargeback/refund/credit/write-off/settlement status, Launch and Approval date, term-completion evidence, migration/Move-in Complete status, customer-controlled account evidence, account ownership record, chain-of-title record, license record, customer-owned carveout review, privacy/security/offboarding status, incident status, retention/hold status, tax/accounting record, and final decision record.

13.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.

13.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-processor and accounting reconciliation.

13.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

14.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.

14.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 internal operations purposes.

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

14.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.

14.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 ID;

• Order Form ID;

• selected plan;

• Launch and Approval date;

• term start date;

• term completion date;

• signup-payment treatment;

• first post-Launch recurring service period;

• post-Launch invoice count;

• no-duplicate-period check;

• payment records;

• payment standing;

• Account Standing record;

• Default Resolution Record;

• default/dispute/chargeback/refund/credit/write-off/settlement status;

• Transfer-Blocking Status review;

• add-on/extra work status;

• migration and Move-in Complete status;

• customer-delay/abandonment gate if applicable;

• transfer request date;

• domain ownership/control status;

• account ownership record;

• Framer project/workspace status;

• site-plan/billing-owner status;

• export/handoff/platform capability status;

• reusable asset exclusion record;

• chain-of-title record;

• contractor/subcontractor/vendor assignment evidence if applicable;

• third-party license record;

• analytics/Search Console handoff record;

• forms/CMS/integration record;

• credential/offboarding record;

• access revocation/deletion/rotation evidence;

• source-of-truth record if transfer or offboarding status depends on disputed or reconstructed records;

• native export or audit trail where available;

• corrected notice record if applicable;

• customer-owned preservation manifest if implicated;

• access/export chronology if implicated;

• unresolved source-of-truth gap memo if applicable;

• privacy/security incident status;

• retention or hold routing status;

• Transfer Package record;

• final transfer decision;

• final customer acknowledgment;

• exact Transfer Method for each included item;

• excluded asset record;

• platform limitation record;

• settlement/credit/write-off reference if applicable;

• settlement allocation record if applicable;

• tax/accounting record for transfer events, included value, domain/vendor fees, settlement items, write-offs, credits, refunds, or separately priced handoff items; and

• privacy/security/cookie/offboarding status.

15. Transfer Claim Controls

16.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.

16.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.