Top line: a static site is only portable when the handoff includes the running files, the server configuration, the DNS assumptions, the source artifacts, and the verification commands that prove the domain can move cleanly.
What changed
KENSAI now treats static-site migration work as an evidence package, not just a copy of a web root. The practical handoff includes the live HTML/CSS assets, any imported data or source zips, Caddy host configuration, origin-IP checks, response-header snapshots, and a launch runbook for the receiving team.
That matters because a static deployment often looks simple until the next team has to reproduce its hidden context. A missing redirect, stale origin assumption, or undocumented catalog source can turn a domain move into guesswork.
What a good package contains
- Live tree: the exact served directory, including catalog pages, assets, and fallback files.
- Configuration: the relevant Caddy block, canonical redirects, TLS expectations, and hostnames.
- Source evidence: uploaded archives, source snapshots, imported content origins, and backup copies.
- Verification: curl checks, DNS notes, checksum proof, and reassembly steps for large bundles.
Operational takeaway
Portable static launches are won before DNS is switched. When the new server receives both the files and the operational proof, implementation can continue on the same domain without rediscovering how the old site worked.
For KENSAI, that is the standard: ship the artifact, ship the config, ship the proof, and leave the next team with a path they can verify.