<!--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> - [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=553826) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=553826) </details> <!--IssueSummary end--> To prevent misuse, both direct transfer and File-based Import via remote storage and AWS S3 set maximum download sizes of 5GB for Direct Transfer and 10GB for File-based Import. An ops flag, `import_admin_override_max_file_size`, was added in https://gitlab.com/gitlab-org/gitlab/-/issues/519759 to allow admins to bypass `bulk_import_max_download_file_size` and `max_decompressed_archive_size` in direct transfer, but not for file transfer. ### Problem There are valid situations where PS and Customer Support must import repositories larger than the allowed limit. In such cases, it would be beneficial for them to bypass these limits. ### Proposed solution Allow file size limits configured by application settings to be bypassed when an admin starts the migration, and `import_admin_override_max_file_size` is enabled for file transfer similar to its implementation in direct transfer. **Note that, as mentioned in https://gitlab.com/gitlab-org/gitlab/-/issues/519759#note_2371352760, this solution merely removes the file size validation; both Direct Transfer and File-based Import will still be constrained by the available Sidekiq disk size for processing the files.**