Skip to content
SiteSwarm Platform Documentation

Cloudflare Account Migration

Cloudflare Business Account Migration Runbook, Resource Audit & Platform Provider Architecture

Source Issue: #417 (Epic #448 / Epic #790)
Status: distilled (Distilled into living runbook docs/runbooks/CLOUDFLARE_MIGRATION_RUNBOOK.md)

1. Context & Objective

SiteSwarm originally operated against the founder’s personal Cloudflare account (jacobmiller22.com). As SiteSwarm transitions into a multi-tenant commercial edge platform under JP Technology Solutions, all infrastructure, edge services, D1 databases, and domain routing must migrate to a dedicated corporate business account (Jpsoftwareassociates@gmail.com's Account / Account ID 7fba1ed07b005a3c31a890fe6c20cda2).

This write-up captures the technical discovery, empirical audit of legacy assets, security architecture for dual-tier API credentials, and the standardized platform provider documentation framework.

2. Technical Findings & Empirical Outputs

2.1 Legacy Account Discovery & Resource Audit

  • Legacy Account: jacobmiller22.com (personal account with ad-hoc Workers Free/Paid subscriptions).
  • Subdomain Collision: Workers currently bind to jacobmillerdev.workers.dev.
  • Database Assets: Production and staging inquiries and CMS databases reside on personal D1 instances (siteswarm-inquiries-db, clk-construction-cms-prod-d1).
  • Credential Risk: A single over-permissioned repository-level CLOUDFLARE_API_TOKEN was inherited across PR preview jobs, staging, and production, presenting an unnecessary blast radius.

2.2 Corporate Account Capabilities & Baseline Attestation

Empirical verification against target corporate account 7fba1ed07b005a3c31a890fe6c20cda2:

  1. Workers Paid Plan: Active rate plan workers_paid providing Unbound CPU duration, expanded script limits, and native email service capability.
  2. Corporate Subdomain: Provisioned and active at jpsoftwareassociates.workers.dev.
  3. Primary Corporate Domain: jpsoftwareassociates.com registered and active (Zone ID 4dfdcba71d71e6a0bbf0af0015c77233).
  4. Baseline Security Profile: Patched to Full (strict) TLS encryption, Always Use HTTPS (301), and DNSSEC enabled.
  5. Fallback Origin: Configured at fallback.jpsoftwareassociates.com pointing to RFC 6666 IPv6 discard prefix (100::) to anchor Cloudflare for Platforms Custom Hostnames.

2.3 Dual-Tier API Token Security Architecture

To eliminate omni-token security risks:

  • Developer Local Tier: Elevated interactive credentials (wrangler login / OAuth) for developer workstations to handle schema design, local testing, and initial resource creation.
  • CI/CD Pipeline Tier: Strictly scoped least-privilege token (Workers Scripts:Edit, Workers Routes:Edit, Workers KV:Edit, D1:Edit, R2:Edit, Browser Rendering:Edit, Account Settings:Read, Zone Settings:Read). All high-risk permissions (Billing, Members, DNS:Edit, Zone:Delete) are explicitly denied.

2.4 Standardized Platform Provider Documentation Paradigm

Established the 3-tier provider documentation structure under docs/runbooks/ and docs/architecture/ (<PROVIDER>_ACCOUNT_CAPABILITIES.md, <PROVIDER>_MIGRATION_RUNBOOK.md, <PROVIDER>_CREDENTIALS_AND_SECURITY.md), extensible to upcoming integrations (GitHub, Stripe, Resend, BetterStack).

3. Canonical Targets Distilled

The findings, security matrix, bootstrap procedures, and validation protocols have been distilled into:

4. Decisions Intentionally Deferred

  • Live Production DNS Cutover for Client Custom Domains: Modifying registrar CNAMEs for active commercial clients will be executed in follow-up client onboarding stories once edge apps are verified.
  • Terraform Enterprise State Orchestration: Account-level bootstrapping is codified using declarative Wrangler commands and dashboard checklists (MVA) before introducing Terraform state locking.
  • Advanced Certificate Manager Add-On: Utilizing single-level hyphenated subdomains under standard Universal SSL rather than purchasing paid multi-level ACM certificate packs.