Storage Migration Services

Question

How do you leave files shares untouched on one file server while moving other file share to an alternate file server using Storage Migration Services without affecting the way users access those files shares? The main point is the user experience cannot be affected at all.

Answer 1

You can migrate only the file shares you select, while leaving other shares on the original file server completely untouched. The key is to treat each share as a separate migration item rather than migrating the entire server. In the SMS migration job, inventory the source server, select only the volumes, folders, and shares that you want to move, and exclude the shares that must remain on the existing server. SMS does not require you to move every share on a server.

For the shares you are moving, the important feature for maintaining the user experience is identity transfer. During the cutover phase, SMS can transfer the source server's name and IP address to the destination server. The destination server effectively takes over the identity of the old file server, including the SMB shares and their paths. So, if users currently access a share as \\FileServer01\Finance, they can continue using \\FileServer01\Finance after the migration. You do not need to change drive mappings, UNC paths, scripts, applications, or shortcuts that reference that server name.

However, there is an important limitation in your scenario. You cannot have the same server identity simultaneously serving some shares from the old server and other shares from the new server. If FileServer01 remains the identity of the original server, all requests for \\FileServer01\... continue going to that server. When SMS performs identity transfer, the new server becomes FileServer01, so the old server can no longer continue serving the shares that you deliberately left behind under that same name.

Effectively, if your requirement is to move Share A to Server B while Share B remains on Server A, without changing the paths users use, you need to plan the namespace carefully. The recommended approach is to have users access the shares through a DFS Namespace, for example \\domain.com\Shares\Finance and \\domain.com\Shares\HR. SMS can migrate the underlying target for Finance from Server A to Server B while the namespace path remains unchanged. HR can continue pointing to Server A. From the user's perspective, both paths remain exactly the same.

If you are currently using direct UNC paths such as \\ServerA\Finance and \\ServerA\HR, and you need Finance moved to Server B while HR stays on Server A, SMS identity transfer by itself is not the right mechanism to accomplish a completely transparent split. You would need either a DFS Namespace or another abstraction layer. Otherwise, moving the identity ServerA to Server B would also redirect \\ServerA\HR to Server B, which violates your requirement that HR remain on Server A.

For the zero-user-impact objective, I would also perform the migration in stages. Let SMS inventory and validate the source, perform the initial data transfer while users continue working normally, repeat synchronization so that only the remaining changes need to be transferred, validate NTFS permissions and share permissions, and then schedule the final cutover during a period of minimal activity. The final cutover should be very short, but it is not accurate to promise literally zero interruption. Existing SMB sessions may need to reconnect, and applications that have files open can require special handling.

So, the distinction is: SMS can transparently preserve the server name for a migrated set of shares, but it cannot split one server's identity between two physical servers. If some shares must stay on the old server and others must move while users continue using exactly the same paths, use DFS Namespace paths as the stable user-facing paths and migrate the individual share targets underneath them.

---

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin