1Footer documentation
Common website migrations
See how the destination determines footer delivery when you change a builder, host, framework or project.
Last reviewed
Lovable or another builder → Vercel
Keep the website and its publication in your 1Footer workspace. Connect the Vercel account that controls the destination project, with matching GitHub access when source preparation needs it. Released native automatic repair covers Next.js App Router and TanStack Start.
After the domain serves the new project, 1Footer uses fresh hosting and framework evidence to select the destination adapter. An old Lovable footer mount can remain in the source without establishing that Lovable still hosts the site. The repair stages the supported integration, checks it and verifies the public footer after publication.
Change hosts while keeping compatible edge delivery
A website can change its underlying host or framework while its eligible Cloudflare zone remains connected. On compatible setups, edge delivery adds the published footer HTML to the page response without a framework-specific source installation.
Keep the destination origin, domain and zone binding correct. 1Footer checks current delivery and uses supported recovery when needed. The destination must permit this proxy arrangement. Shopify and Wix need native paths; this example does not apply to them.
Same host → a new project or repository
A domain can move to a replacement project even when the hosting company stays the same. Connect the account and source access that control the project now serving that domain. Credentials for the previous project cannot authorize edits to the replacement.
For a released destination adapter, 1Footer checks the binding before preparing a repair. If access is revoked, source edits conflict or the destination cannot be established, the repair needs attention. Your published links, page rules and intentional pauses remain the source of intent.
Move to a CMS or another framework
Check the destination row in the platform matrix before moving. WordPress has a server-rendering plugin; HubSpot and other HTML sites have native snapshots or HTML/CSS exports. The React SDK can be used in supported server/build workflows. These delivery options do not by themselves enable automatic native repair.
Broader Astro, SvelteKit, Remix, React Router, Netlify, WordPress, HubSpot, Shopify and Wix native automation is in development. Use a released compatible delivery path where one exists. Shopify and Wix native requirements cannot be replaced by an incompatible proxy.
Change the public domain as well
A host migration and a public-domain change require different ownership checks. Confirm the new domain and website binding in your workspace, including the correct subdomain. Automatic account and domain reassignment is not released across every platform.
Check the new public URL after redirects finish. Compare the actual links and styles with the current publication, test page rules and navigation, and confirm a single usable footer. A successful build or old verification does not prove delivery on the new domain.