[Initiative] Migration Plan for Universal ScyllaDB Resource Table

[juliuskrah]

Summary

Define the migration plan for moving existing catalog resources onto the universal ScyllaDB resource table. This follow-up turns the schema design into an executable migration path for current product, category, and collection data.

In Scope

• Inventory existing catalog resource kinds and their current storage assumptions
• Define a phased migration plan from catalog-specific storage to the universal resources table
• Specify backfill steps for uid, resourceVersion, labels, spec, and status
• Define cutover and rollback strategy for the migration
• Add validation and integration-test requirements for the migration path
• Document operational sequencing for safe rollout

Out of Scope

• Redesigning the universal table schema itself (tracked in [Initiative] Universal ScyllaDB Resource Table for CRD-Style Resources #140)
• Resource identity semantics (tracked in [Initiative] Stable Catalog Resource Identity and Rename-Aware UID Lifecycle #135 and [Initiative] Object Lifecycle Versioning Contract for UID and resourceVersion #137)
• Hydration/export behavior (tracked in [Initiative] Hydrated Catalog View in ScyllaDB with Lossless YAML Export #136)
• Watch stream protocol changes

Acceptance Criteria

• A phased migration plan exists for moving catalog resources into the universal table
• Backfill behavior for existing resources is documented and testable
• Rollback/cutover strategy is defined for partial or failed migrations
• Migration sequencing accounts for stable identity and versioning contracts
• Integration tests or migration dry-run coverage validate the plan
• Documentation explains operational steps and dependencies for rollout

Implementation Notes

The schema design in #140 is only useful if the current catalog data can reach it without downtime or semantic drift. This migration issue defines how to preserve identity, versioning, and object history while transitioning existing resources. The plan should be explicit about which systems write old storage, which write the new table, and how to verify parity before cutover.

Dependencies

• Depends on: [Initiative] Universal ScyllaDB Resource Table for CRD-Style Resources #140 (Universal ScyllaDB Resource Table for CRD-Style Resources)
• Related: [Initiative] Stable Catalog Resource Identity and Rename-Aware UID Lifecycle #135 (resource identity), [Initiative] Hydrated Catalog View in ScyllaDB with Lossless YAML Export #136 (hydrated view), [Initiative] Object Lifecycle Versioning Contract for UID and resourceVersion #137 (versioning contract), [Initiative] Controller Watch API with resourceVersion Resume #131 (watch API)