HLM Cloudflare Pages Migration

HLM Cloudflare Pages Migration

What

Use this SOP when a client website is moving from its current host into Heavy Lifting Marketing’s Cloudflare Pages setup. The job is to preserve the approved source, validate the HLM deployment, set up the correct GitHub Actions workflow, and hand back a production-ready Pages project.

This SOP ends at HLM deployment readiness. Jakob handles the separate domain cutover.

Who owns it

The Website Specialist owns source preservation, HLM Pages setup, parity checks, and the deployment workflow. The SEO Specialist reviews site behavior, metadata, robots, sitemap, canonicals, and important routes. Operations supports access and handoff tracking.

No one should change live production behavior, indexing, canonicals, or launch state without explicit approval. Do not send test emails, submit forms, or create test leads unless the exact test is approved.

Steps

1. Record the repository, branch, exact production commit, current host, target HLM account, build command, output directory, runtime version, environment-variable names, binding names, and latest deployment details. Confirm the working tree is clean.

2. Preserve rollback material before changing anything. Run the existing build and QA suite, archive the generated output, create a Git bundle, calculate checksums, and capture representative desktop and mobile screenshots. Record key routes, redirects, forms, tracking, metadata, robots, sitemap, canonicals, and one intentional 404.

3. Build the exact approved source commit once. Deploy that artifact to a temporary HLM Pages validation project with a distinct name. Do not change source code to force parity.

4. Compare the source site and HLM validation deployment. Check routes, assets, desktop and mobile appearance, navigation, redirects, forms, embeds, phone and email links, tracking, metadata, schema, robots, sitemap, canonicals, 404 behavior, browser console errors, and important network failures. Equivalent markup and scripts do not prove real lead or email delivery.

5. After parity passes, create the final HLM Pages project. Configure GitHub Actions to deploy the approved branch to that exact HLM project. Keep credentials in GitHub Actions secrets. The workflow must report the deployed commit SHA and final Pages URL, and fail if it targets the wrong project.

6. Stop at deployment readiness. Give Jakob the repository and branch, final HLM project name, Pages hostname, deployment URL, exact commit SHA, workflow result, build and QA results, parity status, remaining risks, missing access, and rollback instructions.

Definition of done

The HLM Pages project serves the approved exact commit. GitHub Actions deploys the intended branch to the intended HLM project and reports the final deployment URL. Build, QA, desktop, mobile, route, asset, metadata, and console checks pass or have an approved exception. Rollback evidence exists. Jakob has a concise handoff packet for the separate production cutover.