Introduction

A file services migration can move home folders and redirected data to the new platform while users still save Desktop, Documents, or other redirected folders to the old share. Files appear on the wrong server, one OU writes to the new location while another still targets the previous path, or user data stops syncing after the old share is shut down because Group Policy, offline files, and namespace redirection often linger after the cutover.

Treat this as a user-data path problem instead of a generic file sync issue. Start by checking where an affected workstation actually resolves and writes its redirected folders, because migrations often validate the new file server and copied data while endpoints continue following older folder-redirection policy or cached paths.

Symptoms

  • Redirected folders still write to the old share after migration
  • Users see missing or stale Desktop or Documents content depending on machine or site
  • One OU or office uses the new path while another still uses the previous share
  • Redirection fails only after the old file server is retired
  • Data exists on the new platform, but user sessions keep writing to the retired location
  • The issue started after moving file shares, home drives, or desktop profile infrastructure

Common Causes

  • Folder Redirection GPO still references the old UNC path or DFS target
  • Offline Files cache keeps using the previous location
  • DFS namespaces or share aliases still resolve to the old backend
  • User profile policy was updated in one OU but not another
  • Logon scripts or environment variables still publish the old home path
  • Validation confirmed the new share was available but did not verify where real user sessions actually wrote data

Step-by-Step Fix

  1. Capture one affected user session and record the resolved redirected-folder path and actual file server it writes to, because the runtime storage path determines where user data really lands.
  2. Compare that active redirection path with the intended post-migration design, because one stale GPO or cached path can keep many users tied to the retired share.
  3. Review Folder Redirection policy, home-directory settings, logon scripts, DFS mappings, and Offline Files state for references to the old location, because redirected data often depends on both policy and local cache.
  4. Check OUs, branch offices, and workstation build versions separately if behavior differs, because migrations often fix one user scope while another still applies the previous redirection path.
  5. Update the authoritative redirection policy so affected sessions write to the intended share, because copying user folders alone does not retarget live endpoint behavior.
  6. Run a controlled file-write test and confirm new user data lands on the intended share from an affected workstation, because seeing migrated files on the new server does not prove current sessions use it.
  7. Verify the old share no longer receives redirected-folder writes from migrated users, because split user-data paths can remain hidden while both shares stay online.
  8. Review file permissions, Offline Files sync state, and profile cleanup timing if behavior still looks inconsistent, because the destination can be correct while client cache or ACLs still interfere.
  9. Document which team owns user GPOs, namespace paths, and migration validation so future file-share moves verify the real write target used by user sessions before retiring the previous server.