Skip to content

PATTERN Cited by 1 source

Copy-not-regenerate migration

When migrating content between storage systems, copy the existing bytes as-is rather than regenerating them from source, if downstream consumers depend on byte-level determinism (e.g. SRI hashes, checksums, content-addressed storage).

Problem

Build tools (minifiers, compressors) are not fully deterministic across versions. Regenerated files are semantically correct but produce different hashes. For a CDN where users pin SRI hashes in their HTML, different bytes = broken references at scale.

Solution

Migrate the existing content from the old store to the new store byte-for-byte. Accept that the new pipeline will produce different output for future versions (which get new hashes), but preserve all historical content exactly as served.

Trade-offs

  • Pro: zero user-visible breakage; no coordination with downstream consumers
  • Con: must trust that the old store's content was correct (no re-validation opportunity); requires capacity to bulk-copy potentially terabytes of data

Canonical instance

cdnjs tried re-processing old packages and writing to R2, but regenerated files didn't byte-match what KV had been serving. They rolled back and migrated KV content to R2 as-is instead (Source: sources/2026-07-30-cloudflare-dogfooding-at-scale-migrating-cdnjs-to-cloudflares-developer-platform).

Seen in

Last updated · 604 distilled / 1,840 read