{}Value Statement{}

As a developer working on Global Hub cluster migration, I need to ensure ClusterInstance resources work normally after migration via the Global Hub so that migrated clusters maintain their configuration and operational state.

This story focuses on designing which resources will be migrated and reviewing the approach with the telco team to ensure completeness:

What Gets Migrated

The migration process automatically transfers the following resources from source hub to target hub:

Core Resources

• ManagedCluster: Cluster registration and management
• KlusterletAddonConfig: Add-on configurations for managed clusters

Deployment Resources

• ClusterDeployment: Hive deployment configuration (including status)
• ImageClusterInstall: Image-based installation configuration (including status)

Secrets and Configmaps

• Cluster admin password (<Cluster Name>-admin-password)
• Cluster kubeconfig (<Cluster Name>-admin-kubeconfig)
• Pull secrets and other ClusterInstance-annotated secrets
• Referenced Secrets (automatically collected via collectReferencedResources):
  • BMC Credentials: Secrets referenced in BareMetalHost.spec.bmc.credentialsName for baseboard management controller access
  • Pull Secrets: Secrets referenced in ClusterDeployment.spec.provisioning.pullSecretRef.name for image registry authentication
  • Extra Manifests ConfigMaps: ConfigMaps referenced in ImageClusterInstall.spec.extraManifestsRefs for additional cluster configuration

Bare Metal Resources (with status preserved)

• BareMetalHost: Physical server inventory and state
• HostFirmwareSettings: BIOS/firmware configurations
• FirmwareSchema: Firmware setting schemas
• HostFirmwareComponents: Individual firmware components
• DataImage: OS images for bare metal hosts

What is NOT Migrated

• ClusterInstance Resources: Managed by GitOps (Argo CD). You must manually apply GitOps applications to the target hub after cluster migration.
• Policy Resources: Must be redeployed via GitOps applications on target hub
• Application Resources: GitOps applications managing cluster configuration

{}Development Complete{}

• [ ] The code is complete.
• [ ] Functionality is working.
• [ ] Any required downstream Docker file changes are made.

{}Tests Automated{}

• [ ] Unit/function tests have been automated and incorporated into the build.
• [ ] 100% automated unit/function test coverage for new or changed APIs.

{}Secure Design{}

• [ ] Security has been assessed and incorporated into your threat model.

{}Multidisciplinary Teams Readiness{}

• [ ] Create an informative documentation issue using the Customer Portal Doc template that you can access from [The Playbook](https://docs.google.com/document/d/1YTqpZRH54Bnn4WJ2nZmjaCoiRtqmrc2w6DdQxe_yLZ8/edit#heading=h.9fvyr2rdriby), and ensure doc acceptance criteria is met.

Call out this sentence as it's own action:

• [ ] Link the development issue to the doc issue.

{}Support Readiness{}

• [ ] The must-gather script has been updated.

—
*Description updated to follow ACM Story template. Generated with Claude Code - https://claude.com/claude-code*