[Plan] Backfill referencing tables after the application code is updated to use new column

Objective

Backfill the plan_name_uid and hosted_plan_name_uid columns in all referencing tables after the application code has been updated to use the new columns everywhere.

Context

This issue is part of the effort to convert the plans table to be hard-coded in application code (Epic #19409 (closed)). The backfill process must happen after the application code is fully updated to use the new *_name_uid columns to prevent data gaps where records are created/updated without the new column values.

Prerequisites

  • Plans table enum column completed (#571419 (closed))
  • New columns added to referencing tables (#571420 (closed))
  • Application code updated to use new *_name_uid columns everywhere

Scope

Backfill the following tables with plan_name_uid / hosted_plan_name_uid values based on existing plan relationships:

  • plan_limits → backfill plan_name_uid based on existing plan_id
  • gitlab_subscriptions → backfill hosted_plan_name_uid based on existing hosted_plan_id
  • gitlab_subscription_histories → backfill hosted_plan_name_uid based on existing hosted_plan_id
  • ci_pending_builds → backfill plan_name_uid (if applicable)
  • instance_type_ci_runners → backfill plan_name_uid (if applicable)
  • project_type_ci_runners → backfill plan_name_uid (if applicable)

Tasks

  • Create backfill migrations to populate new columns based on existing plan relationships
  • Validate data integrity after backfill
  • Ensure no records are missed during the backfill process
  • Handle edge cases (null values, orphaned records, etc.)

Migration Strategy

For each table:

  1. Create a batched background migration to backfill *_name_uid columns
  2. Map existing plan_id/hosted_plan_id values to corresponding name_uid enum values
  3. Validate that all records are properly backfilled
  4. Handle any orphaned or invalid references

Acceptance Criteria

  • All referencing tables have their *_name_uid columns populated
  • Data integrity validated - no missing or incorrect mappings
  • Backfill migrations are efficient and don't cause performance issues
  • Edge cases handled appropriately (orphaned records, null values)
  • No data gaps created during the backfill process

Important Notes

⚠️ This backfill must only be executed after the application code is fully updated to use the new columns. Running the backfill before the code changes could create data inconsistencies where new records are created without the *_name_uid values.

References

Edited by Bishwa Hang Rai