Skip to main content
1FooterGet started free

1Footer documentation

Automatic migration checks and repair

How 1Footer recognizes changes, chooses a supported connection, verifies repairs and handles failures.

Last reviewed

1Footer runs the workflow

1Footer coordinates detection, repair, verification and ongoing checks in the cloud. Connected services execute the site changes. The repair must stay within the account, website and project you connected.

Automatic repair currently depends on the released platform adapter. The platform guide shows where a delivery package is available and where broader native automation is still in development.

Detect the current website

Checks use fresh responses from the live site to identify its current hosting and framework. A leftover Lovable or Framer embed does not by itself decide where the site is hosted today.

For example, a verified move from Lovable to Vercel can update the saved platform and use a supported Vercel server adapter when the publishing account is connected.

Prepare and verify a supported repair

Supported staged repairs preserve the existing deployment for recovery. An uncertain provider response is reconciled before starting another operation.

  • Confirm the connected account and current site/project binding.
  • Prepare a supported delivery adapter and stage the change.
  • Compare the staged page HTML with the current published footer.
  • Publish only after the required checks pass.
  • Check the public website again and record the result.

When a repair cannot finish

A missing permission, changed project, conflicting edit or failed public check can need attention. 1Footer should keep the last healthy delivery where possible, respect pauses, and report the incomplete repair.

For supported deployment repairs, a failed public result can trigger restoration of the previous deployment. Manual or unrelated source changes must not be overwritten to force a footer check to pass.

Where AI fits

AI can help inspect supported connected projects. The application controls the available actions, provider permissions and deployment target. Known adapter paths can run without a model call.

Verification uses the actual page and publication. A model response is not a delivery receipt.