Using DFS for copying user profiles

@Arnold
but does the profile really need to be copied? What settings have the users made on the old server everything that can not be done manually on the new server?
When copying synonymous always old data are copied, which you never get rid of. A restart on a new server always ensures a certain data cleansing!

but does the profile really need to be copied?

Depends on size, but in general it's better to "seed" the DFS replicas prior to full implementation. This stop DFS from getting overloaded with file transfers, which happens a lot with large amounts of data. DFS isn't a block-level replication system. It compresses data, transfers it, and decompresses it on the other side. The processing and queuing required to do this causes buffer clogs with lots of data is transferred, causing replication failures.

That said, if your goal is to have user profiles stores in DFS replicated folders, please understand that this scenario may not be fully supported by Microsoft. https://support.microsoft.com/en-us/help/2533009/information-about-microsoft-support-policy-for-a-dfs-r-and-dfs-n-deplo has an explanation of the specific scenario that MS does not support. Essentially, lots of quick, short data changes can cause the transfer buffer to get backed up and queue data. If a file gets modified in one location and modified a second time before the replication of the first change finishes migration, it causes a problem that DFS isn't capable of handling effectively on its own and changes made in both files may be lost.

Just to Clarify Justin provided MS link, the scenario is not supported/caveate for a brankch/HQ setup.  The question here is the asker within the same location wants to replicate data from one system to another for purpose of transition from 2008 to 2016