Follow-up from "Fix GitLab Migration groups & projects visibility levels to be preserved"
<!--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=388395) </details> <!--IssueSummary end--> The following discussion from !109026 should be addressed: - [ ] @rodrigo.tomonari started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/109026#note_1242235421): (+4 comments) > I don't understand why a project entity type would allow a blank `destination_namespace` :thinking: > > Don't projects always need to be imported into group namespaces? > > Am I missing anything? This issue isn't problematic, as long as only the backend creates the project migrations, because the backend sets the `destination_namespace`. When we allow users to create project migration, not validating the existence of the destination namespace or allowing a blank value would cause the same issue as https://gitlab.com/gitlab-org/gitlab/-/issues/381902+, where the project would be created in the user's namespace.
issue