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