Recover safely during a website migration

The new website needs its own verified repair

1Footer owns the supported repair workflow in the cloud. It checks the current destination, uses the publishing account connected to that website and verifies the current published footer on the public domain. The repair must also respect page rules and intentional pauses.

Repairing the destination and retiring an old installation are separate operations. A successful restoration of the old site does not prove the new website is ready. The latest public result must describe the destination that visitors actually reach.

What happens to the old installation?

Old installations can remain in a previous project, theme or deployment after the public domain moves. Cleanup needs the original website identity and authorized access. A new account connection does not authorize edits to an unrelated previous account.

Automatic retirement of old native installations is still in development across the supported matrix. Supported recovery must preserve unrelated edits and newer publications. If the old clean version cannot be established, the safe outcome is an incomplete cleanup requiring attention, rather than restoring a guessed deployment.

When publishing takes time or loses its response

A provider can accept a publishing operation before its response is lost. Supported recovery checks the saved operation and provider state before issuing another write. Pending work does not establish either success or failure.

Do not submit repeated repairs to force progress. Review the latest website result and resolve a reported permission or source conflict. A saved connection, successful build and verified current footer describe different outcomes.

Your content, pauses and edits remain the intent

• Use the currently published footer; keep unpublished drafts private.
• Preserve included and excluded page rules at the destination.
• Leave an intentional pause in place during migration and recovery.
• Preserve newer website content and unrelated source changes.
• Reconnect the correct destination account if access changes; old credentials cannot authorize the replacement.

When a migration is finished

Confirm the current public domain serves one usable footer with the latest published links on included pages, with correct excluded-page and navigation behavior. Check the dated delivery result after redirects and publishing have finished.

Review any separately reported old-installation cleanup. Some native recovery paths are not released yet, so destination verification alone is not a claim of automatic end-to-end migration coverage for every platform.