Transfer tool leaves files behind and shows success

Referencing a 1-year old thread ([Case 158681] Transfer tool leaves files behind and shows success), we stumble upon the same problem: Transfer Tool claiming success while infact not all files were transferred successfully (!). In our case (migrating from CENTOS 6.8 x86_64 xenpv WHM 58.0 (build 31) to CENTOS 7.2 x86_64 kvm WHM 58.0 (build 31)), we think this problem is due to ownership permissions as it occurs when files in account1's homedir are owned by account2:group3. rsync will botch big time, while cPanel will state there was no issue. Had to find out the hard way. Excerpt from the Homedir part of the log file:
Streaming Homedir from source server" receiving incremental file list rsync: failed to set times on "/home/account1/public_html/static": Operation not permitted (1) rsync: recv_generator: mkdir "/home/account1/public_html/static/magazine" failed: Permission denied (13) rsync: failed to set times on "/home/account1/public_html/uploads": Operation not permitted (1) rsync: failed to set times on "/home/account1/public_html/uploads/.ckfinder": Operation not permitted (1) (...) rsync: mkstemp "/home/account1/public_html/uploads/.ckfinder/cache/data/images/.logo.jpg.cache.SAXDq1" failed: Permission denied (13) rsync: mkstemp "/home/account1/public_html/uploads/.ckfinder/cache/data/images/.picture.jpg.cache.V6FUbx" failed: Permission denied (13) rsync: recv_generator: mkdir "/home/account1/public_html/uploads/.ckfinder/cache/thumbs/images/first.jpg" failed: Permission denied (13) Too many errors from "item-RESTORE_AccountRemoteRoot_account1". Future errors will be supressed. "100 % "
I cannot believe how a serious issue like this is leaving customers to think their transfers were successful. Note that we observed some files being created, yet left with no contents (empty). So, any script checking for a simple file_exists could detect no problem even though the contents were missing, as the file exists just fine. In the meantime, we tried to circumvent this issue by restoring a cpmove backup, yet the same "Account restoration" script is used, which gives the same errors. We finally managed to restore the accounts' files by doing a homedir backup on the source server, transfering them to the new one and using tar to extract the public_html dir from the backup:
cd /home/accountname rm -Rf /home/accountname/public_html tar -xvf /home/accountname.tar.gz --strip=2 accountname/homedir/public_html/
This may have botched up files' ownership, but at least they got migrated to the server in one piece. Oh, and another thing we noticed when using the Transfer Tool: our old server stems from a time in which (legacy) MySQL imposed a maximum length on database names, truncating the accountname. I.e. we had an account /home/accountname, which in turn had a database called "accountn_database". This was fine and dandy, but the Transfer Tool decided to instead transfer that to an "acountname_database" database on the new server (running MariaDB). Weird, as I would think a transfer should make a 1:1 copy of an account's data from the source server, rather than use 'intelligence' to re-create a filesystem that may or may not match the source?