<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=463941) </details> <!--IssueSummary end--> Related to https://gitlab.com/gitlab-org/gitlab/-/issues/463768 When a group is moved from one org to the other, data sharded using `organization_id` cannot be moved along with it to the new organization. This would mean that we would need to re-create some data in the new org and delete un-used data, if any, from the old org after the transfer is complete. One such example is `topics` table From https://gitlab.com/gitlab-org/gitlab/-/issues/463768#note_1922951905 Imagine: * group 1 in org 1, has a project with topic: `golang`. `topics` are sharded with `organization_id` * Now, if we want to move group 1 from org 1 to org 2, `topics` are a bottleneck because: * org 2 may or may not already have `golang` as a topic. * So, after the move is complete, we'd have to run special services/jobs to: * create `golang` as a topic in org2, depending on whether it already exists or not. * delete `golang` as a topic from org1, but only if no other project in the org uses it. We'd have to repeat the same steps for all such data tables sharded with `organization_id`. This issue needs to track all such tables requiring data re-creation and deletion.