The short answer is yes.  Every version of every file and folder that is mapped for migration will be downloaded to the client then checked into the target server.

However, it may not be preserved in the way you expect. The server does not allow the TFS to TFS migration tool (or any migration tool) to specify the original checkin time or changeset ID.  These are instead applied as of the time of the migration checkin, as it would be for any other checkin.  Please keep in mind that reports generated from version control history will show that all the migrated changes happened at the time of the migration.  While changeset links for migrated Work Items will be updated with the linking session, external references to changeset numbers (such as in emails) will also be invalid. 

Integration history is also not preserved. Integration history is basically a record of how merge conflicts were resolved, for the purpose of determining which changes to flag as conflicts in future merges.  Unfortunately, there is no way to query the source server as to how the conflicts were originally resolved. The migration tool will still migrate the merge, but instead of resolving any conflicts in the way they were originally resolved, it uploads the file content from the source server and instructs TFS to resolve the conflict by accepting this version.  The result is that after migration, TFS cannot tell which branch the resolved, migrated content came from.  This could cause extra conflicts in future merges, so we recommend that your merges are up to date before attempting a migration.