1Footer documentation
How 1Footer recognizes a migration
Understand hosting and framework signals, destination ownership and what happens when the current platform is unclear.
Last reviewed
A different host behind the same domain
A website can keep its public address while moving from a builder to a different hosting provider. 1Footer checks fresh public responses and hosting signals rather than treating the saved platform as permanent.
For example, an old element named onefooter-lovable-root can survive a move to Vercel. That element describes an earlier installation; it does not establish the current hosting provider. A strong current hosting signal can update the saved platform and guide a supported repair.
A new framework on the same host
Hosting and application framework are different facts. A website on Vercel is not necessarily a Next.js application, and a JavaScript bundle alone does not prove server rendering.
The destination framework and delivery mode determine which integration can put the published footer into the document. Check automatic installer availability separately from SDK or export availability. A detected framework does not mean its automatic native adapter has been released.
A replacement project, account or domain
A host name can stay the same while a different project starts serving your domain. Supported repairs verify the destination binding and use the publishing access connected for that website. Access to an old project cannot authorize changes to a replacement project.
If the public domain changes too, confirm the new domain and website binding in the workspace. Domain and account reassignment is not automatic across every platform. Keep the original publication, page rules and intentional pauses while preparing the destination.
When the evidence is incomplete
Old embed markers, a temporary error page or a previous verification cannot prove where a website is hosted now. Conflicting signals, propagation delays or an unavailable public page can leave a check inconclusive. Detection alone does not authorize a publishing change.
Review the latest website result and destination access when a supported repair needs attention. Avoid submitting duplicate changes while an earlier publishing operation is uncertain. An incompatible proxy is not a replacement for a required native integration.
Detection starts the repair; public output confirms it
For a released connected destination, 1Footer owns the cloud workflow: choose the supported adapter, prepare the change, check the staged result, publish and verify the real public footer. Your computer does not need to stay running.
A successful platform update is progress. Completion requires the public output to match the current published footer and applicable page rules. The platform matrix distinguishes released automatic paths from native adapters still in development.