# Migrate Cloudflare CDN configuration: Cache policy by content

## Summary
Move CDN delivery from Cloudflare CDN configuration to Ample, one component at a time. Destination verified on Ample: an immutable versioned asset and a mutable latest pointer stored with different Cache-Control headers in a published bucket, each served from the CDN URL with the header exactly as stored. Source procedure: Record page rules, cache rules and the asset paths the app references. Not migrated automatically: Cloudflare cache rules, Workers, Transform Rules and tiered caching are not migrated; Ample verifies delivery of published bucket objects only. Cutover: Redeploy the app with the new asset base URL, verify delivery from the CDN URL, then retire the old cache rules. Rollback: keep the source untouched until you confirm; nothing at the source is changed or deleted by this guide.

## Workload
Cache policy by content

## Migration Source
Cloudflare CDN configuration

## Execution Status
Unbound

## Prerequisites
- Authorized access to the Cloudflare CDN configuration source and its export tooling
- An inventory of every component in scope and out of scope
- A validated backup or copy before any cutover
- An Ample account token with `servers:write`, `buckets:write`

## Workflow Steps
1. **Inventory the source**  
List what Cloudflare CDN configuration provides beyond the component you are moving. Out of scope here: Cloudflare cache rules, Workers, Transform Rules and tiered caching are not migrated; Ample verifies delivery of published bucket objects only.
2. **Source step 1**  
Record page rules, cache rules and the asset paths the app references.
3. **Source step 2**  
Copy the public assets into a published Ample bucket under versioned keys with immutable Cache-Control.
4. **Source step 3**  
Update the app to build asset URLs from the Ample public URL.
5. **Publish the destination bucket**  
Create and publish the asset bucket, upload versioned assets with immutable Cache-Control, and point the app at the public URL.
   - Command: `ample bucket publish`
6. **Validate before cutover**  
Run the app's own checks and, for data, compare counts and checksums; the example checks are the pattern self-tests (`/p/cache-policy-by-content`).
7. **Cut over**  
Redeploy the app with the new asset base URL, verify delivery from the CDN URL, then retire the old cache rules.
8. **Rollback**  
Point DNS or configuration back to the source. The source was never modified; deletion is a separate, user-executed step after validation.

## Success Checks
- Destination app responds on its public URL.
  - Kind: `http_get`
  - Path: `/`
  - Expect: ample canary next js patterns
- Cache-policy-by-content check from the destination example.
  - Kind: `http_get`
  - Path: `/p/cache-policy-by-content`
  - Expect: see the pattern fixture checks.
- Data or object counts and checksums match the source.
  - Kind: `manual`
  - Expect: operator comparison before cutover.

## Limitations
- Documentation only: nothing is executed automatically and no execution binding is offered.
- The source-side procedure is documented from Cloudflare CDN configuration's standard tooling and was not executed in this catalog's evidence; the destination side was verified with the pattern fixture.
- No full source-product parity is claimed: Cloudflare cache rules, Workers, Transform Rules and tiered caching are not migrated; Ample verifies delivery of published bucket objects only.
- Verified on the node-22 template at s-1vcpu-1gb; region, compliance and request-duration limits are unknown.
- PutObject and GetObject with path-style addressing are verified; bulk copy tooling and other S3 operations are not.