Using the IIS Migration Tool

The IIS Migration Tool is designed to migrate Web sites from one machine to another. It can handle pretty much all source sites, including IIS 4.0, 5.0, and surprisingly 6.0, which can be useful if you want to move a Web site from one machine to another.


The migration tool comes with the IIS 6 Resource kit, which you can download from the Microsoft downloads center at

The IIS Migration Tool works by running on the destination server?running IIS 6.0?and the source server?running another version of IIS. It's therefore a combination of a migrating and copying tool. You can't use the IIS Migration Tool for migrating content between different versions of IIS on the same machine (which isn't technically possible anyway because the migration tool needs both machines to be working).

The migration tool cannot be used to migrate scripts and filter out all the bugs and problems for migrating from one scripting platform to another. It will migrate the scripts, but it won't fix incompatibilities between the two.

That doesn't make the tool completely useless?for the majority of sites, it's going to do the core work of migrating settings and files. The IIS Migration tool does all the following:

  • Backs up the metabase configuration on the target server.

  • Migrates the Web site content. You can also copy between different source and destination directories.

  • Copies file system access control lists.

    graphics/web_icon.gif WEB RESOURCE

    For more information on IIS and Access Control Lists, go to the Delta Guide series Web site at and enter article ID# A020702.

  • Copies the IIS metabase configuration and migrates the settings between the two servers.

  • Maps IIS 4.0 and IIS 5.0 application isolation settings to the new IIS 6.0 application pool settings. What it doesn't do is make your Web site applications IIS 6.0 compatible, nor does it automatically make them Worker Process Isolation mode compatible.

You can also optionally apply the following settings:

  • Change the Web root directory path in source files.

  • Apply FrontPage Extensions to sites that use FrontPage Server extended sites.

  • Change the IP address, port number, and host header (virtual server) to new settings. This is useful if you want to migrate the site to a new server for testing.


Before you start, you need to make sure that both your source machine (the one currently holding your site) and the target machine are up and running and configured for network operation.

You also need to ensure that

  • IIS is installed and running on both machines. Remember that IIS 6 is not running by default under Windows Server 2003?you must have configured the Application Server Role to install IIS 6.

  • The IIS Admin service is running on both machines. You can check this by checking the services. Services was a control panel in Windows NT 4.0 (see Figure 7.4), but is part of the MMC and the Administrative tools folder within Windows 2000 Server and Windows Server 2003. (Figure 7.5 shows the Windows 2000 Services snap-in.)

    Figure 7.4. Services in Windows NT 4.0.


    Figure 7.5. Services in Windows 2000.


  • Administrative file sharing is enabled on the source server. You must have remote access to the administrative file shares for each disk that holds IIS site information, including C$ for the metabase and any additional drives that hold site data. You might need to install/enable the File Sharing component on Windows 2000 to enable this setting.

  • You must have administrator privileges for both the source and the target machine.

Finally, remember to have enough space to copy over the source files for the Web site content. Considering the size of disk drives today, this shouldn't be a problem.

Migrated Items and Limitations

During the migration, the tool migrates all the source data, configuration, and security settings that it is capable of migrating, with a few caveats and exceptions:

  • The metabase file is migrated to the new XML format. The source metabase information is backed up by the tool using the location %systemroot%\System32\Inetsrv\Metaback\IIS Migration Tool Backup.MD##, where ## is an incremental number.

  • The following directories and virtual directories are not migrated from IIS 4 and IIS 5:

    • IISSamples

    • IISHelp

    • IISAdmin

    • _vti_bin

    • Printers

    • MSADC


  • Existing directories and files are not overwritten automatically unless you've told the tool to do so. Otherwise, it will prompt to confirm each file/directory to be overwritten during the migration process.

  • Data is migrated to the same directory as the source unless you tell it to do otherwise through a command-line option. You cannot migrate the site data to a UNC path unless the UNC path has been mapped to a drive letter?that is, you must write to z:\WWWroot rather than \\WWWFileserver\WWWroot.

  • Files from UNC shares on the source will be migrated providing that the current target server can still reach the original UNC share.

  • Files and directory security is preserved providing that the machine, domain, and other account identifies can be found within the current security scope.

  • Local users are not re-created, and access control lists are not configured for local users after migration. You will need to reset these settings once the migration has completed.

  • Server settings (IP address, port number, and host header) are preserved. (Source IPs configured to act on all IP addresses are similarly configured on the destination.) You can change these parameters using a command-line option.

  • Application pool settings are migrated according to the following rules:

    • In process applications are placed into an application pool named SourceServerName_InProcess.

    • Pooled applications are placed into an application pool named SourceServerName_Pooled.

    • Isolated applications are placed into a unique application pool called SourceServerName_ApplicationName.

Using the Tool

The migration works through the C$ drive mapping system reading the source configuration, Web site source, and security settings directly from the source file system, re-creating the various settings, migrating the metadata file from its binary format to XML, and then copying over the source files onto the target system.

To use, ideally you need to run it from the command line, although you could start it from the Start->Run system if you want.

The basic syntax for the command is

iismt.exe Server Website [options]

where Server is the name (or IP address) of the source server you are copying from, and Website is the name or metabase key (W3SVC/1) of the Web site you want to copy.


You must copy sites individually; you cannot migrate an entire server and all of its Web sites in one go.

This is mildly annoying if you have a lot of Web sites configured, but it also has advantages in that it means we can migrate individual sites to different servers. The site-by-site approach also means that we can migrate a site, test it, and move on to the next, rather than having one big migration and testing phase.

Table 7.2 lists the additional optional command-line parameters and their syntax that you can use.

Table 7.2. Migration Tool Command-Line Parameters



/user UserName

The username to use when communicating with the source server?it should either be a straight Username or a domain base Domain\Username. If you don't explicitly specify the credentials, the migration tool will attempt to use your current credentials. Note that unless your Active Directory domain is running in mixed compatibility mode, you will need to authenticate with the Windows NT domain.

/password Password

The password to go with Username.

/path Path

The destination directory for the migrated Web site source files. If not specified, it uses the same directory path as on the source server. If you have changed your partition and drive setup so that they do not match the source machine, you will need to use this parameter to set a new location.

This parameter is ignored if you are using the /configonly parameter, which doesn't copy site data.

/serverbindings ServerBindings String

Sets an alternative IP address, port number, and host header for the Web site during the migration process. The ServerBindings String should be in the format IP:Port:Hostheader. For example, to change the IP address to use IP address, port 8080, and the host header, you would use the string

Note that this doesn't actually configure this IP address for the target host.

If you don't specify this setting, the migrated Web site will use the default IP address of the target server if the source server also used the default IP address.

If the source server specifies an alternate IP address, the alternate IP address will be migrated.

Port and host header information is migrated verbatim by default?that is, a site migrated from the default IP address, but on port 8129 and with a host header of, will be migrated to the default IP of the target server with the same port and host header settings.

/siteid [SiteID] | Replace

The site ID of the Web site when it is written to the target server. Use this if you want to renumber the sites as they are migrated. If you want to replace an existing site ID number with the migrated site, append the Replace keyword. If you do not specify an alternative site ID during migration, the site ID will simply be the next available number on the target server.

If you specify a site ID that already exists on the target server and you have not included the Replace keyword, the migration will fail.


Forces the migration tool only to migrate the settings for the site, not the data.


Extends a FrontPage Server extended site on the target server if it was running FrontPage Server extensions on the source. Ignored if the /configoly parameter is in effect.


Includes additional details of the metabase path copy and file copy stages of the migration process as they occur.


Forces existing files to be overwritten without prompting you beforehand.

Without this setting, you will be prompted if a file or directory already exists on the target during the migration process.

Best used if a past migration attempt failed and you want to initiate the migration again in a non-interactive session, such as a batch file execution.


Suppresses messages that prompt the user for input. When this parameter is used, the migration tool exits when it encounters the first error condition.

Best used when you are running the migration tool as part of a batch file, but remember to log the output so that you can re-initiate a migration if it fails.

For example, to run the migration tool to migrate the site MCSLP from the server ntiis, you would run the following on the destination server:

Iismt.exe ntiis MCSLP

To add credentials to the source server and force it to overwrite any existing Web site source files, you would use

Iismt.exe ntiis MCSLP /user Administrator /password Pass /overwrite

Post Migration

Despite everything that the tool does during the migration process, there will be a few things you will need to do to ensure that your sites are up and running properly again.

In particular,

  • Copy additional components? Any DLLs, applications, or other components not located within the Web site source directory will not be copied over. Also, remember that additional software and applications, such as Perl and Python, will need to be manually installed on the target?these are not migrated automatically.

  • Register additional components? Specialist DLLs will need to be registered using the regsrvr32.exe tool, and then will need to be included within the Web services extensions if necessary. Also remember to update the COM+/MTS packages if they are used and set any registry values or other settings required by the DLLs.

  • Re-create ODBC settings? Use the ODBC Manager to re-create ODBC connections.

  • Code conversions? Not all code will run verbatim on the new platform. You will need to test and make appropriate changes before activating the site.

  • Local security accounts? These are not migrated, so you will have to re-create them by hand. Also remember to reapply the ACLs for these local users and groups on the target machine.

  • FrontPage? The FrontPage administrator account is not created on the target server automatically. You will also need to reset and re-apply FrontPage security settings.

  • Windows directory location? You must manually adjust the Windows directory location for components that need it, such as the ScriptMaps and HTTPErrors properties of the Metabase.

  • Virtual directory locations? Only the root directory of a Web site is updated; any virtual directory locations that are different will have to be updated.

  • Security Certificates? SSL certificates must be migrated and re-imported manually.

  • Log files? Log files for individual sites are not migrated; you must do these by hand.

  • MIME types? MIME types must be reset or updated by hand.

  • IP Address? If you are using multiple IP addresses on a single network interface and are using these additional IP addresses to serve Web sites, you will need to manually add the IP address to the card.