On the source server you will need read permissions to all of the branches and folders that you want to bring over to the destination server. You will not need any write permissions on the source server.
Additionally for some cases, restricting permissions on the source server on folders that you want to omit from the migration can speed up the migration when compared to using folder mappings. One use case is when clients have checked in hundreds of thousands of files from 3rd party products into their source tree and want to omit them from the migration.
The StarTeam API doesn't have a consolidated history view like Git or TFVC and instead history needs to be examined on each individual item to see every folder that it has ever existed in to make sure that files are renamed properly as well as added or deleted across folder mappings that exclude items.
Using folder mappings still requires those items to be processed to find their historical revisions and process them in labels. Using permissions has the StarTeam server filter out those items before they are returned to Timely Migration so no processing will need to be done on the client.
Generally standard Git permissions should suffice. However depending on whether you are migrating into a new repository or an existing one, there may be some server side configuration that will need to be changed to enable some features.
Azure DevOps has a setting of "Commit Mention Linking" under "Version Control Administration" -> "Options" which needs to be enabled for the Timely Migration "UseCommitMentionLinking" option to function.
If permissions are set to enforce that branches are created in folders with specific naming conventions, folder mappings will need to be created that adhere to those naming conventions or an account with sufficient permissions to push a branch with any name will need to be used when pushing the Git repository to the destination server.
At a minimum you will need write permissions for the destination Team Project to be able to test out a migration. However part of the migration is associating changesets with the users that originally checked them into the source server and for that you will need elevated permissions.
For domain accounts that are active in Active Directory and have already used TFVC, you will need Check in other users' changes permissions which typically comes with Team Project Administrator rights.
However if you have users that are no longer active and you want to create read only audit users to associate to those checkins , you will need Edit collection-level information permissions which typically comes with Team Project Collection Administrator rights.