When organizations decide to move services from an older Windows Server version to a newer one, there are a few options. Businesses can perform an in-place upgrade of the current server to a more recent Windows Server version. There are also options for migrating roles and services from an older server to a newer one. Windows Server Migration Tools (WSMT) serve this purpose.

WSMT has been around for quite a while. It is a Windows feature that provides access to specialized PowerShell cmdlets, allowing automated migration of certain roles between a legacy server and a newer Windows Server operating system.

The Windows Server Migration Tools can migrate specific settings, including the following:

  • Roles
  • Features
  • Shares
  • Operating system configurations

The process of using WSMT is generally as follows:

  1. Install WSMT on the destination server (the server that is the target of the roles, features, etc.).
  2. Copy the WSMT files to the source server.
  3. Export the roles, features, etc., from the source server to a destination folder.
  4. Import the roles, features, etc., to the destination server.

Limitations of WSMT

While, in concept, the Windows Server Migration Tools provides great functionality, in practice, it is limited in the scope of roles, features, settings, and other data that can be migrated from a legacy server to a destination. Note the following compatible roles, features, settings, and data:

Roles

  • Active Directory Domain Services
  • DNS
  • DHCP server
  • File services
  • Print services

Features

  • BranchCache

Settings and data

  • Data and shares
  • IP configuration
  • Local users and groups

Additionally, if you look at the documentation for WSMT, it is quite dated. It details scenarios of migrating roles and services up to Windows Server 2012 R2, which is now end-of-life. However, if you look at Windows Server 2022, the WSMT feature is still available for installation.

The /OS switch, which allows copying over the migration tools to a specific OS, does have a switch that includes Windows Server 2016, so it is reasonable to assume that it supports operating systems up to Windows Server 2016 as a source.

Supported operating systems to deploy the source SMIG files

Supported operating systems to deploy the source SMIG files

Windows Server Migration Tools is still valid for specific roles, services, data, and configurations, and can be a path to migrate the specific roles and services listed above. Just be aware of the potential for unsupported scenarios and buggy behavior that can be seen between different OS versions.

In-place upgrade vs. Windows Server Migration Tools

As mentioned at the outset, running an in-place upgrade is another common way to bring legacy servers up to current Windows Server versions. However, there can also be challenges with in-place upgrades. These can include:

  • Hardware compatibility issues—The hardware may not be compatible with the latest Windows Server versions.
  • Driver issues—Tying in closely with hardware compatibility, drivers can create issues during in-place upgrades.
  • Unsupported software—Legacy software that cannot be migrated to newer operating systems can prevent an in-place upgrade.
  • Multiple steps to arrive at the target Windows Server version—The further back the source Windows Server OS is, the likelier it will be that you will have to take multiple steps to get to the latest version. For instance, you cannot go directly from Windows Server 2008 R2 to Windows Server 2022. You have to go from Windows Server 2008 R2 to Windows Server 2012 R2 and then from Windows Server 2012 R2 to Windows Server 2022.
  • Time and maintenance windows—The in-place upgrade could take a significant amount of time. Moving individual services and roles off a server can be more timely and, in many cases, work better.

Conclusion

This comparison certainly offers different answers for different businesses depending on many factors. These factors include the roles and services needing to be migrated, the difference in Windows Server versions between the source and destination servers (how many versions are between), and compatibility.

Subscribe to 4sysops newsletter!

Windows Server Migration ToolsWSMT may work out well for some who need to migrate the specific supported roles and features. However, using modern Windows Server tooling may be better, such as the new Storage Migration Service that can migrate an entire legacy file server from Windows Server 2003 and grab permissions, users, and shares, and assume identity.

avataravatar
1 Comment
  1. olivier 1 year ago

    HI Brandon
    Interesting post as always
    I would like to add other challenges not mentioned :
    – The source server doesn’t respect the Best-Practices. It would be a shame to reproduce this on the new one.
    – the source server has hidden “pans” (sorry if it’s not the correct word for a misconfiguration), it would be a shame to reproduce them on the new one.

    to summarize : in a lot of cases, it could be easier, faster, less effort to audit the source server first, then choose using WSMT or build a full new server using scripts or other methods.
    Regards

Leave a reply

Please enclose code in pre tags

Your email address will not be published.

*

© 4sysops 2006 - 2023

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account