How to Migrate from IIS 6 to IIS 7

With so many cool new capabilities in IIS7, and even more new features coming out all the time, it's no wonder you want to move to IIS7.  But you work for The Man, and everyone knows The Man wants ROI.  He can't just let you go willy-nilly and adopt every cool new technology that hits the street.  After all, He has a business to run.  And that business currently runs on IIS 6.  And he's paid you a lot of money (ok, not that much) to write the code, test the apps, deploy the servers, and keep those HTML pumping machines up and running 24x7x365.  And things are running well, right?  When was the last time you had to worry about metabase corruption?  Or been forced to run IISRESET?  Or been paged in the middle of the night with some glorious server 500 error and (of course) the developer who wrote the code is no where to be found?  

Dear reader, I know your plight.  I've been there before.  I work for The Man too.  And while he is a kinder, gentler boss as he moves into his old age (>30s!), he expects results. 

This post is broken into three parts.  1) Sell the Boss 2) Get the Goods 3) Be the Hero (and migrate those servers!).  If you're already sold on IIS7, jump to section 2 and 3 for instructions on how to actually migrate those IIS6 servers to IIS7 in a quick and painless way. 

Sell the Boss

So how do you sell The Man on moving to IIS7?  Here is my quick top 10 list, email me if you need more help:

  1. IIS7 is faster and more efficient than any other version of IIS.
  2. With IIS7 you can manage whole Web farms from one place
  3. IIS7 allows you to delegate management workload with site owners. Site owners can also remotely manage their sites and applications over HTTPS from Windows Vista, Windows XP, Windows Server 2003, and Windows Server 2008.  IIS7's XCopy deployment model even allows you to deploy applications preconfigured!
  4. IIS7 is much more flexible and customizable than before, allowing you to fine tune the server (including server core!) to minimize security footprint and downtime due to patching. 
  5. You can save loads of time by automating more tasks with the interface that is right for you.  
  6. If you do run into issues, IIS7 makes it easy to resolve site issues faster, minimizing down time due to that bone headed developer on your staff. 
  7. IIS7 includes built-in support for PHP, making it the best Web server for both Open Source languages and .NET.  Why would you want to deploy, manage, patch and troubleshoot that Linux+Apache server to support those PHP apps, when you can just use Windows!?
  8. IIS7 makes it easy to publish content securely over FTP/SSL or WebDAV!
  9. Windows and IIS7 are cheaper than ever with the new Windows Web 2008 product.  This version of Windows is super inexpensive and supports all the great features of IIS, Sharepoint, SQL, Windows Media server and more for Internet facing sites!
  10. And as if that isn't enough, IIS7 is getting better every day with new IIS7 Extensions like built-in progressive streaming and playlist support for media content, URL Rewrite capabilities, integrated database management, powershell support, and much much more. 

Get the Goods

If your company already has access to Windows Server 2008, you've paid all the money you'll ever need to pay in order to get IIS7 up and running.  Have a cheap boss who wants to see the results first?  Get the Windows Server 2008 trial edition which lets you try before you buy.  I recommend the Windows Web Server 2008 for Internet facing sites, or Standard server for intranet ones. Note:  IIS7 also ships with Windows Vista, which you can use for development and testing of your applications.

Now that you've got IIS7, it's time to get the migration tool (x86) and (x64).  Ok, it is a WHOLE LOT MORE than just a migration tool, but this article is about migrating, and the Microsoft Web Deployment tool was built specifically with migration from IIS6 to IIS7 in mind.  Download it now, use it to not only migrate from IIS6 to IIS7, but to archive (snapshot) your entire site/server (including configuration, content, certificates, etc.).  You can also use it to do live synchronization of your IIS6 or IIS7 sites or servers in a web farm.  MS Deploy is going to be your new best friend, be nice to it.

Be the Hero (and migrate those servers!)

This step is documented very nicely in the portal under deployment, but I'll shamelessly steal from there to make your life easier.  If things don't work (any longer), you might want to check the official documentation for the latest updates, or see Troubleshooting MS Deploy.  This section assumes you've already downloaded MS Deploy and have installed it successfully.  (see "Get the Goods")


Part 1 - View dependencies of the source

1. Get the dependencies of the web site by running the following command:

msdeploy -verb:getDependencies -source:metakey=lm/w3svc/1

2. Review the output of the dependencies and look for any script maps or installed components in use by the site. For example, if Windows Authentication is in use by the web site, you will see <dependency name="WindowsAuthentication" />.

3. If your site is inheriting any script maps, these will not be listed in the dependencies and you should also review the script maps for your site manually.

4. Compile a list of the components needed on the destination.

For detailed steps on analyzing the output of getDependencies, see Viewing Dependencies of a Web site.

Part 2 - Configure the target or destination machine

1. Review the list of dependencies and install them on the destination server.

For example, let’s assume you had the following in use for your web site:


• Windows Authentication

• Anonymous Authentication

Based on analyzing your dependencies, you would install those components and modules.


Part 3 – To migrate the site to the source server

1. Always make a backup of the destination server. Even if you are just testing, it allows you to easily restore the state of your server. Run the following command to backup an IIS 7.0 server:

%windir%\system32\inetsrv\appcmd add backup “PreMsDeploy”

2. Run the following command on the destination server to take an archive of the server for migration:

msdeploy -verb:sync -source:metakey=lm/w3svc/1 -dest:archivedir=c:\site1archive

3. Run the following command on the destination server to validate what would happen if a migrate was run:

msdeploy -verb:migrate -source:archivedir=c:\site1archive -dest:metakey=lm/w3svc/1 -whatif > msdeploymigrate.log

Note: If you don't wish to sync from an archive, you can sync using the remote service. Specify computerName with the name of your server, such as Server1. If you are not running on the default port and URL, you need to specify the full URL, such as http://Server1:8080/msdeploy. For example, change the source to

3. After verifying the output, run the same command again without the whatif flag:

msdeploy -verb:migrate -source:archivedir=c:\site1archive -dest:metakey=lm/w3svc/1 -whatif > msdeploymigrate.log

Note: If you don't wish to sync from an archive, you can sync using the remote service. Specify computerName with the name of your server, such as Server1. If you are not running on the default port and URL, you need to specify the full URL, such as http://Server1:8080/msdeploy. For example, change the dest to

You are now done migrating your site. To verify, test browsing to the web site on the destination server. For troubleshooting help, see Troubleshooting MS Deploy.

No Comments