Migration Appendix

This Migration Appendix describes migration-related scope for an existing website, domain, content, analytics, Search Console property, CMS, archive, account, or current online presence that Sites is asked to review, rebuild, consolidate, redirect, coordinate, or transition for the applicable customer relationship.

1. Migration Appendix Role

1.1 Role. This Migration Appendix governs migration-related scope for any existing website, domain, content, analytics, Search Console property, CMS, archive, account, or current online presence that Sites is asked to review, rebuild, consolidate, redirect, coordinate, or transition.

1.2 Relationship to Order Form. The Order Form controls customer-specific commercial facts, selected plan, launch destination, customer-specific migration entries, add-ons, and special terms.

1.3 Relationship to Scope Appendix. The Scope Appendix controls plan allowances, page allowances, support, Managed Time, Growth Time, integrations, add-ons, exclusions, and scope classifications.

1.4 Relationship to payment and default documents. The Subscription / Payment Terms and Payment Authorization control payment timing, authorization, add-on charges, refunds, credits, disputes, portal limits, and payment records. The Default / Nonpayment Terms control failed-payment, customer-delay, service-pause, suspension, default, and restoration workflows.

1.5 Relationship to Ownership Transfer Terms. The Ownership Transfer Terms control transfer eligibility, Account Standing, transfer package contents, platform handoff, domain/DNS handoff, account ownership, transfer withholding, and transfer exceptions.

1.6 No public-material expansion. Pricing pages, sales discussions, proposals, dashboard messages, Help Center articles, checkout screens, onboarding flows, support messages, status labels, and processor-generated notices do not expand migration scope, payment obligations, launch approval, ownership transfer, or search-related obligations unless the expanded term is included in the signed Order Form, signed amendment, signed migration scope, or written approval by both parties.

1.7 Issue-specific priority. This Migration Appendix controls migration categories, migration process records, page mapping, redirect planning, domain/DNS coordination records, analytics/Search Console coordination records, Launch and Move-in Complete migration records, migration exclusions, and migration claim controls. Customer-specific price and included scope are controlled by the Order Form and Scope Appendix. Charges and payment authorization are controlled by the payment documents. Default and service restriction consequences are controlled by the Default / Nonpayment Terms. Transfer consequences are controlled by the Ownership Transfer Terms.

1.8 No payment modification. This Migration Appendix does not create or modify payment obligations. Billing timing, taxes, add-ons, refunds, credits, disputes, failed payments, cancellation, and default consequences are controlled by the signed payment and default documents and related payment records.

2. Migration Principles

2.1 Process-based migration. Migration services are process-based. Sites provides defined review, planning, coordination, rebuild, redirect, content-carryover, launch, and closeout steps within the selected plan, written migration category, signed scope, platform capability, customer access, and signed documents.

2.2 No search outcome promises. Migration does not promise search rankings, traffic, indexing, crawl timing, canonicalization, redirect interpretation, Search Console processing, revenue, leads, third-party platform treatment, uninterrupted transition, or identical search visibility.

2.3 Scope and records control. Migration scope is controlled by the selected plan, Order Form, Scope Appendix, this Migration Appendix, written migration category, written add-on approval, written Exception Path scope, and migration records.

2.4 Customer cooperation. Migration timing and completion of scoped migration tasks depend on Customer providing accurate current-site information, content, approvals, access, domain/DNS readiness, analytics/Search Console access where applicable, platform access, page decisions, and timely feedback.

2.5 Platform and access limits. Migration depends on current platform capability, destination platform capability, export capability, account ownership, delegated access, domain/DNS control, third-party provider action, vendor limitations, and technical feasibility.

2.6 Regulated or sensitive content. Content involving health, wellness, medical, dental, legal, financial, accounting, real estate, medspa, privacy-sensitive, accessibility-sensitive, or other regulated or sensitive topics may require additional intake, claim review, privacy/security review, specialist review, or separate scope before carryover or publication.

2.7 No hidden migration expansion. Discovering additional pages, archives, integrations, redirects, account issues, content volume, platform constraints, or regulated-content issues does not automatically expand migration scope or create automatic extra work. The affected work requires classification, customer notice where applicable, and any required approval before it proceeds.

2.8 Delay neutrality. Customer-side delay, third-party delay, platform delay, access limits, unresolved disputes, or Sites-side inability to proceed must be recorded before it is used under the applicable signed payment, default, transfer, refund, credit, or launch terms to support launch timing, Move-in Complete timing, service-pause, default, refund, credit, or transfer decisions.

2.9 Account and ownership neutrality. Migration access, DNS coordination, temporary hosting, redirect setup, Search Console verification, analytics setup, content carryover, or platform coordination does not transfer ownership of any domain, registrar account, analytics account, Search Console property, platform account, reusable asset, source code, design file, or third-party account unless the signed documents expressly say so.

3. Migration Categories

4. Core Migration Allowances

4.1 Plan allowances. Core Migration page allowances are:

4.2 Page allowance only. Core Migration is a page-treatment allowance. It does not include every asset, post, archive entry, file, image, media item, CMS record, SEO setting, tracking setup, plugin, custom script, form workflow, database item, login area, user account, or third-party account unless the signed scope expressly includes it.

4.3 Page treatment. A page may be rebuilt, merged, redirected, deferred, excluded, archived, dropped, or separately scoped. Core Migration does not require every current page to become a separate destination page or a standalone reproduction.

4.4 Estimate and reclassification. The page count is based on the current-site inventory and available access. If the actual page count, content volume, CMS structure, archive size, platform condition, redirect complexity, account ownership, regulated content, or technical constraint differs materially from intake, Sites may document the changed condition, notify Customer where applicable, and require any needed written approval before affected out-of-scope work proceeds.

4.5 Complexity override. Work within a page allowance may still be reclassified if it involves unusual content volume, custom systems, account ownership issues, inaccessible platforms, complex redirects, regulated content, privacy/security issues, or large archives.

5. Migration Process

5.1 Standard process. The migration process may include:

1. current-site URL and access intake;

2. current-site review;

3. page inventory;

4. content inventory;

5. platform/CMS notes;

6. domain/DNS readiness check;

7. analytics/Search Console access coordination where applicable;

8. page mapping;

9. customer decisions on rebuild, merge, redirect, defer, exclude, archive, drop, or separately scope;

10. content carryover within signed scope;

11. destination-site rebuild or consolidation;

12. redirect planning and setup where appropriate, technically feasible, platform-supported, authorized, and within scope;

13. domain/DNS transition coordination where authorized, technically feasible, platform-supported, and within scope;

14. site-move process steps within signed scope;

15. customer review and approval;

16. launch coordination;

17. Move-in Complete review; and

18. migration records for completed, deferred, excluded, and separately scoped items.

5.2 No identical reproduction obligation. Migration does not require Sites to recreate the current site pixel-for-pixel, preserve every design element, reproduce every page structure, recreate every plugin, or carry over every file unless the signed migration scope expressly requires that item.

5.3 Customer approval. Customer must approve migration decisions that materially change current content, drop pages, consolidate pages, exclude content, affect launch readiness, affect redirects, or require separate scope.

5.4 No silence as approval. Silence, non-response, missed review windows, Sites status notation, production deployment, DNS connection, preview link delivery, screenshot delivery, or unresolved customer delay does not by itself create Launch Approval, migration approval, payment approval, recurring-billing trigger, transfer eligibility, or customer acceptance unless a signed document or written approval process expressly provides otherwise.

6. Customer Inputs And Access

6.1 Required inputs. Customer must provide accurate and timely:

• current-site URL;

• current platform/CMS information;

• current host and domain/DNS provider information;

• admin or delegated access needed for the signed migration scope;

• CMS, library, archive, or content access where applicable;

• analytics and Search Console access where applicable;

• sitemap, page list, or other current-site inventory if available;

• business information, services, menus, pricing, locations, and approved content to be carried over;

• images, media, files, brand assets, and license information Customer wants Sites to use;

• payment or tax location information required by the Order Form or payment records; and

• migration decisions, approvals, and launch blockers.

6.2 Access method. Customer should provide delegated, role-based, OAuth, or least-privilege access where available. If raw credentials are required because no delegated method is available, Sites may require additional security steps, limited access duration, credential rotation, or a written exception record.

6.3 Customer content responsibility. Customer is responsible for the accuracy, rights, permissions, and required approvals for Customer-provided content, media, files, claims, trademarks, logos, images, and account materials.

6.4 Access limits. Sites is not responsible for migration delay, missing content, missing redirects, missing tracking, missing exports, unavailable history, account limitations, platform restrictions, or third-party provider action caused by Customer's failure to provide required information, access, permissions, approvals, or decisions.

6.5 Customer delay. Customer delay may pause or extend affected migration tasks, Launch targets, Move-in Complete timing, and dependent work after the applicable delay record, notice, dispute, and dependency review under the signed documents. Customer delay does not by itself decide refund, credit, default, transfer, tax, or accounting treatment.

6.6 Legacy platform intake. If migration involves a prior agency, old host, old CMS, old forms, current tracking tools, account owners, third-party plugins, or legacy credentials, Customer must identify known account owners, access limits, vendor contacts, backup/export options, decommission decisions, and retention needs.

7. Current-Site Inventory And Page Mapping

7.1 Current-site inventory. Sites must create or maintain a migration record identifying the current-site URL, estimated page count, platform/CMS, key content types, current integrations, known forms, known tracking tools, domain/DNS status, and access status.

7.2 Page map. For migrations where page mapping applies, Sites must create or maintain a page map showing current pages and proposed treatment.

7.3 Page treatment categories. Page treatment categories may include:

• rebuild;

• merge;

• redirect;

• defer;

• exclude;

• archive;

• drop;

• customer decision needed; or

• separately scoped.

7.4 Page-map records. Page maps may identify current URL, proposed destination URL or treatment, priority level, redirect decision if any, content owner, customer approval record, excluded or deferred treatment, regulated or sensitive content flag if any, and related approval or billing reference if applicable.

7.5 Customer approval. Customer must approve page treatment decisions where the decision materially changes current content, drops pages, consolidates pages, excludes content, affects launch readiness, or requires separate scope.

7.6 Legacy-site closeout. If the current site, current host, current CMS, old agency account, current forms, or current tracking setup will be retired, disconnected, left active, archived, exported, or customer-retained, the migration record should identify the closeout decision, responsible party, export or retention path, customer acknowledgment, retention or deletion trigger where applicable, and post-launch issue-intake contact.

8. Redirects, Domain, DNS, And Launch Destination

8.1 Redirect planning. If redirects are applicable, Sites may create a redirect plan or redirect map for approved pages and URLs within scope.

8.2 Redirect setup. Redirect setup depends on current platform access, destination platform capability, domain/DNS control, hosting control, customer approval, URL structure, technical feasibility, and signed scope.

8.3 Domain/DNS transition coordination. Sites may coordinate domain/DNS transition tasks where technically available, authorized, platform-supported, and within scope. Domain ownership, registrar account ownership, DNS account ownership, platform account ownership, and delegated-access status should be identified in migration records where known.

8.4 No continuity promise. Domain/DNS coordination is not a promise of uninterrupted domain, DNS, hosting, search, email, analytics, business-listing, or customer-business continuity.

8.5 Required access. Customer must provide domain/DNS access, domain-provider access, hosting access, or delegated access needed for launch and migration.

8.6 Customer-side domain delay. Customer-side delay in domain/DNS readiness, access, verification, approvals, registrar lock, third-party provider action, or platform connection pauses or extends affected Launch and migration timing after the applicable dependency record.

8.7 Launch destination. The launch destination is the customer domain or other written launch destination listed in the Order Form or launch approval record.

8.8 No ownership transfer by migration. Migration access, DNS coordination, temporary hosting, redirect setup, Search Console verification, analytics setup, or domain connection work does not transfer domain ownership, registrar account ownership, analytics account ownership, Search Console ownership, platform account ownership, or reusable asset ownership unless the signed documents expressly say so.

8.9 Domain/DNS authorization. Sites must not make domain/DNS changes without recorded authorization, known control-status information, requested-change record, and available rollback or emergency contact note where applicable.

8.10 Domain/DNS change record. Before domain/DNS changes are made, the migration record should identify the known domain owner, registrar/DNS provider, access method, permission level, registrar lock or access issue if any, current connected services where known, requested changes, authorized approver, change window, emergency contact, rollback contact, rollback limits, post-change verification, remaining issue log, and offboarding or transfer notes where applicable.

9. Analytics, Search Console, Tracking, And Forms

9.1 Access coordination. Sites may coordinate analytics, Search Console, tag, pixel, form, CRM, booking, email/SMS, or tracking access where applicable and within scope.

9.2 Account ownership and access. Migration records should identify the known owner or administrator for Customer business data, analytics data, Search Console data, form submissions, customer-provided content, and customer accounts; Sites' access role if any; delegated-access status; transfer or offboarding status; and known platform limits.

9.3 Tracking limitations. Migration does not promise continuity of historical analytics, reporting comparisons, pixel behavior, tag firing, form behavior, Search Console data, platform reports, or third-party tool behavior.

9.4 Data and privacy review. Forms, analytics, pixels, tags, CRM connections, booking tools, email/SMS tools, and tracking tools may require privacy, security, cookie, vendor, consent, retention, or platform review before launch or publication.

9.5 No silent tracking carryover. Migration does not authorize silent tracking carryover. Carried-over or newly configured analytics, pixels, tags, forms, CRM connections, booking tools, email/SMS tools, or tracking tools must follow the applicable privacy, cookie, platform, and signed-scope workflow before publication.

9.6 Required records. Sites must record analytics/Search Console access status, account owner if known, connected tools, migration-related changes, launch notes, data-flow concerns where applicable, and offboarding or transfer notes where applicable.

10. Blog, Library, CMS, Archive, And Large Content Migration

10.1 Not automatically included. Blog, library, CMS, archive, file-library, gallery, menu database, product catalog, resource center, article archive, event archive, or large content migration is included only if it fits within the selected plan and signed migration scope or is approved in writing by both parties.

10.2 Classification. Large content migration may be classified as Migration Expansion, Migration Plan, Complex Migration, Growth Time, add-on work, or Exception Path work.

10.3 Content decisions. Customer must approve content decisions for archive carryover, consolidation, exclusion, rewriting, deferral, redirects, and publication.

10.4 Editorial work. Editorial decisions, content rewriting, claim review, regulated content review, search-content rewriting, media processing, taxonomy cleanup, and archive cleanup are not included unless the signed scope expressly includes them.

11. Migration Expansion

11.1 Trigger. Migration Expansion applies when the current site exceeds Core Migration allowance or needs additional migration work that is still bounded and not Complex Migration.

11.2 Required approval. Migration Expansion requires written approval, pricing or cap, scope, included page/content allowance, timing, service period or milestone where relevant, customer inputs, and Payment Authorization alignment where billed before out-of-scope work begins.

11.3 Boundaries. Migration Expansion does not include Complex Migration, custom development, custom applications, marketplace migration, login/user-account migration, regulated workflow migration, or large archive migration unless expressly included.

11.4 Charge classification. Migration Expansion charges must be tied to the applicable approval, invoice or payment record, service period or milestone where relevant, refund or credit issue if applicable, and tax/accounting record where applicable before billing.

11.5 Out-of-scope pause. Discovery that a migration exceeds Core Migration or approved Migration Expansion creates a reclassification record and pause/approval path for the affected work. It does not create automatic extra work, automatic extra charges, automatic term extension, automatic default, or automatic transfer withholding.

12. Migration Plan

12.1 Purpose. A Migration Plan is a structured planning-only process for larger, structurally complex, multi-location, multi-site, high-content, or high-risk migrations, including migrations where search visibility may be affected.

12.2 Possible contents. A Migration Plan may include:

• current-site inventory;

• page and content inventory;

• priority-page list;

• page treatment recommendations;

• redirect planning;

• domain/DNS readiness notes;

• analytics/Search Console access notes;

• phased migration plan;

• customer approval gates;

• deferred/excluded item list; and

• Launch versus Move-in Complete plan.

12.3 Planning only. A Migration Plan is a planning and process document. It does not include execution beyond Core Migration unless approved in writing by both parties, and it does not promise search-engine treatment, traffic, indexing, rankings, revenue, leads, or interruption-free transition.

12.4 Premium planning treatment. If Premium includes a Migration Plan when Sites classifies planning as needed, the included item is the planning process only. Execution beyond the Premium Core Migration page allowance still requires signed scope, pricing or written included-scope confirmation, service period or milestone record where relevant, and Payment Authorization alignment where billed.

13. Complex Migration

13.1 Trigger. Complex Migration applies to migration work that exceeds standard Core Migration, Migration Expansion, or Migration Plan scope.

13.2 Examples. Complex Migration may include:

• large sites;

• multi-site consolidation;

• custom platforms;

• complex CMS structures;

• large archives;

• login or membership areas;

• marketplace or ecommerce-like structures;

• custom database-backed content;

• complex redirects;

• regulated content libraries;

• custom applications or workflows; or

• substantial third-party platform constraints.

13.3 Separate scope required. Complex Migration must be separately scoped, priced or capped, approved, scheduled, classified, and aligned with the Payment Authorization where billed before work begins.

13.4 Reclassification. If the current-site condition, access limits, content volume, platform constraints, redirect complexity, account ownership, archive size, or regulated-content issues materially differ from the original intake, Sites may document the changed condition, notify Customer where applicable, and require any needed written approval before affected out-of-scope work proceeds as Complex Migration.

13.5 Reclassification record. Reclassification must identify the original estimate, discovered condition, affected scope, proposed revised category, pricing effect if any, amount or cap if any, launch effect, customer approval needed, Payment Authorization alignment if billed, service period or milestone effect where relevant, refund or credit issue if any, transfer impact if any, and whether work pauses pending approval.

13.6 Complex Migration pause. Complex Migration classification pauses the affected out-of-scope work until the required approval and classification records exist. It does not create automatic extra charges, automatic launch delay attribution to Customer, automatic default, automatic no-credit treatment, or automatic transfer withholding.

13.7 Included and paid migration records. Included Core Migration, included planning work, Migration Expansion, paid Migration Plan, Complex Migration, archive/library migration, Exception Path migration, reclassified migration work, and separately priced migration items should be tied to the applicable migration category, included/bundled versus separately priced status, customer approval, pricing or cap where applicable, service period or milestone where relevant, invoice or payment reference where billed, refund or credit issue if relevant, and tax/accounting record where applicable.

14. Launch

14.1 Launch definition. Launch means the Sites-built website is published or live on the customer domain or approved launch destination, core launch scope is complete under the signed scope, and an authorized customer representative has approved the launch through the required launch-approval process or another approved written approval channel.

14.2 Launch can precede Move-in Complete. Launch may occur before Move-in Complete if remaining migration items are deferred, nonblocking, separately scoped, post-launch cleanup, or not required for the live core site.

14.3 Launch Approval Record. Launch requires a launch-approval record shown to or confirmed by the authorized customer approver and retained by Sites. The record must identify the approver, timestamp, approval channel, launch destination, launch date/time, core scope status, migration status, domain/DNS status, analytics/Search Console notes if applicable, deferred or excluded items, known nonblocking issues, recurring-billing trigger status if applicable, next expected billing event if applicable, and any customer-disclosed blockers.

14.4 Recurring billing interaction. Move-in Complete alone does not modify billing. Recurring billing may be evaluated only under the Order Form, Subscription / Payment Terms, Payment Authorization, Default / Nonpayment Terms, and approved amendments, and only if the required Launch Approval Record and payment records exist.

14.5 No Sites-only approval. Sites-only notation, project-management status, production deployment, DNS connection, screenshot delivery, preview link delivery, silence, non-response, or unresolved customer delay does not by itself create Launch Approval or a recurring-billing trigger.

14.6 Launch is not a search event. Launch does not mean search engines have crawled, indexed, ranked, canonicalized, interpreted redirects, processed Search Console data, preserved search visibility, preserved traffic, or completed any site-move treatment.

14.7 Refund, credit, and dispute neutrality. Launch, delayed Launch, or Launch before Move-in Complete does not by itself decide refund or credit treatment, good-faith dispute status, default, suspension, transfer withholding, tax treatment, or accounting treatment unless the applicable signed payment, default, transfer, refund, credit, or launch terms and required records provide otherwise.

14.8 Payment economics. Any statement that Launch, approval, migration status, or Move-in Complete affects recurring billing, default, suspension, collection, transfer, refund, credit, tax, or accounting treatment must be supported by the applicable signed documents and required payment, default, transfer, refund, credit, launch, tax, or accounting records.

14.9 Launch closeout. Launch records should include final access-state evidence, remaining Sites access, customer access status, credential rotation or revocation status, Search Console verification-token status if applicable, analytics/tag/form status if applicable, privacy/cookie/tracking status if applicable, customer acknowledgment or blocker record, emergency contact, closeout owner if any, and post-launch issue-intake path. This closeout record does not create approval, payment rights, transfer rights, or search-performance representations by itself.

15. Move-in Complete

15.1 Definition. Move-in Complete means the post-launch migration/settling phase is complete, including remaining in-scope migrated pages, approved deferred migration items, cleanup, and confirmed migration tasks that did not need to block Launch.

15.2 Record. Sites must maintain a Move-in Complete record showing completed items, deferred items, excluded items, customer decisions, open support items, and any separately scoped migration work.

15.3 No expansion. Move-in Complete does not expand migration scope, add new archive obligations, create new search obligations, extend plan allowances, waive payment obligations, or alter ownership-transfer conditions unless a written amendment expressly says so.

15.4 Not a search-performance event. Move-in Complete is an operational migration status. It is not a representation that search engines have crawled, indexed, ranked, treated, or restored any page, redirect, listing, or search signal.

15.5 Tax and accounting neutrality. Payment timing, Launch status, Move-in Complete status, migration status, invoice labels, customer acknowledgments, and project-management status do not decide taxability, sales-tax collection, accounting treatment, tax income timing, earned or deferred accounting treatment, contract asset or liability treatment, refund or credit accounting, or allocation among plan, add-on, migration, tax, and transfer events.

15.6 Included work records. Included Core Migration and included Premium Migration Plan work may still require service-period, milestone, bundled-service, refund or credit, tax, and accounting records even when no separate migration charge is billed.

16. Search And Migration Claim Controls

16.1 Process-only language. Migration and site-move language must describe process, scope, records, and bounded technical steps only.

16.2 Restricted outcome categories. Sites must not promise:

• ranking preservation or ranking improvement;

• traffic preservation or traffic improvement;

• indexing outcomes;

• crawl timing;

• canonicalization outcomes;

• redirect interpretation;

• Search Console processing;

• search visibility outcomes;

• search-engine treatment;

• interruption-free transition;

• identical page reproduction;

• migration success measured by search outcomes;

• Google or other search-engine action;

• inclusion of all content outside plan limits or signed scope; or

• revenue, lead, conversion, speed, uptime, or performance outcomes from migration alone.

16.3 Permitted claim concept categories. The following concepts may be used only with required context, substantiation, customer-specific records where applicable, and required approval:

• Core Migration included by plan;

• Migration Expansion with approval and pricing;

• Migration Plan as a planning process;

• Complex Migration as separately scoped work;

• page mapping;

• redirect planning and setup where appropriate;

• domain/DNS transition coordination where technically available, authorized, platform-supported, and within scope;

• analytics/Search Console coordination; and

• site-move process steps within signed scope.

16.4 Claim-specific evidence. Each migration claim must be supported by claim-specific evidence, not by a generic launch or migration record alone. The record must identify the exact claim text, intended surface, matched plan allowance or signed scope, relevant page map, redirect map if applicable, customer approval, domain/DNS record if applicable, analytics/Search Console record if applicable, launch record if applicable, Move-in Complete record if applicable, known limits, and supporting record.

16.5 Uncontrolled search behavior. Migration claim wording must assume Sites does not control crawl timing, indexing, ranking, canonicalization, redirect interpretation, Search Console processing, Google action, other search-engine action, third-party search tools, business-listing behavior, or customer traffic patterns.

17. Exclusions

Migration does not include the following unless the signed Order Form, signed migration scope, or written approval by both parties expressly includes them:

• migration of every page, post, archive item, file, image, document, media asset, plugin, script, style, CMS field, or database entry;

• pixel-perfect reproduction of the old website;

• custom application migration;

• ecommerce, marketplace, login, membership, user-account, or database migration;

• HIPAA-sensitive workflow migration;

• legal, medical, financial, health, wellness, medspa, accounting, or regulated claim approval;

• customer content legal review;

• third-party platform remediation;

• source-code cleanup;

• malware cleanup;

• current hosting repair;

• email hosting migration;

• paid advertising account migration;

• business listing management;

• review platform migration;

• third-party vendor support beyond signed scope;

• search-engine outcome responsibility;

• historical analytics continuity;

• unsupported platform exports or transfers;

• transfer of domains, platform accounts, analytics accounts, Search Console properties, reusable assets, source files, design files, or third-party accounts unless required by the signed Ownership Transfer Terms and supported by the applicable platform; or

• support timing or service expectations beyond the approved support terms.

17.1 Platform export caution. Export, transfer, self-hosting, project handoff, source-file handoff, static export, code export, DNS transfer, or platform ownership promises must not be made unless the platform-specific capability and signed Ownership Transfer Terms support the exact commitment.

17.2 Account ownership. Migration records should classify each relevant account or platform as customer-owned, Sites-owned, prior-agency-owned, mixed ownership, unknown ownership, or newly created where applicable. The classification should identify transfer or offboarding handling, access revocation path, remaining Sites access if any, and unresolved customer decisions.

17.3 Platform handoff. If Framer or another destination platform is used, records should identify the workspace, project, site, site-plan or billing owner, role map, custom-domain connection status, customer-specific deliverable treatment, reusable Sites asset treatment, third-party asset/license inventory, selected handoff or non-handoff path, export or transfer feasibility, post-transfer fee responsibility, backup/export limits, customer acknowledgment, and Ownership Transfer Terms alignment where applicable.

18. Customer Responsibilities

Customer must:

• provide accurate current-site information;

• provide access by requested deadlines;

• provide domain/DNS readiness;

• approve migration decisions;

• approve page map and redirect decisions where applicable;

• provide or approve content to carry over;

• confirm rights to content, media, files, and assets;

• identify regulated or sensitive content;

• review migrated pages and launch previews promptly;

• identify errors or omissions during review windows;

• approve Launch or identify specific blockers;

• preserve current-site backups or exports if Customer wants independent retention outside Sites' scope;

• identify whether current-site accounts, domain/DNS accounts, Google accounts, platform accounts, form/CRM/booking accounts, and integrations are customer-owned, Sites-owned, prior-agency-owned, mixed ownership, unknown ownership, or newly created;

• cooperate with privacy/security review for forms, tracking, analytics, pixels, tags, CRM, booking, email/SMS, sensitive data, vendor contracts, retention, deletion, and consent/opt-out requirements;

• provide accurate payment, billing, business-use, and service-location information required by the Order Form and payment records; and

• avoid requesting Sites to publish or represent unsupported search, ranking, traffic, indexing, legal, accessibility, privacy, security, performance, or scope-expansion promises, while preserving Customer's ability to raise legal, privacy, accessibility, security, defect, billing, support, or other concerns for review.

19. Migration Records

Sites must maintain migration records appropriate to the selected migration category, including:

• selected migration category;

• included/bundled versus separately priced status;

• current-site inventory;

• current-page inventory;

• current-content notes;

• current platform/CMS notes;

• access records;

• legacy CMS/hosting owner, admin, permission, backup/export, vendor, security, decommission, and retention notes where applicable;

• credential, access, and offboarding notes where applicable;

• page map;

• redirect map if applicable;

• customer migration decisions;

• deferred/excluded item list;

• domain/DNS readiness notes;

• domain/DNS authorization, requested-change, rollback, and post-change verification notes where applicable;

• analytics/Search Console access notes;

• form, CRM, booking, tracking, tag, pixel, or data-flow notes where applicable;

• privacy/cookie/tracking decision for carried-over or newly configured tools where applicable;

• launch approval record;

• launch closeout notes;

• Move-in Complete record;

• customer delay records;

• Sites-side delay or inability-to-proceed notes;

• platform or vendor limitation records;

• good-faith dispute flags where applicable;

• refund or credit issue notes where applicable;

• default or nonpayment routing notes if delay or migration status may affect account standing;

• ownership-transfer impact notes if migration status may affect transfer review;

• scope reclassification records;

• add-on or Exception Path approval records;

• claim substantiation records for migration-related claims;

• customer payment or tax location information where relevant to billed migration work;

• invoice or payment reference where migration work is separately billed;

• service period or milestone where relevant;

• tax/accounting record where applicable;

• customer-site versus Sites-owned surface status for tracking/forms/data tools where applicable;

• regulated or sensitive content routing decision;

• record-retention, deletion, archive, or hold status where applicable;

• platform export or handoff limitation notes where applicable; and

• account-ownership and platform-handoff notes where applicable.