Moving a Web site

We’re getting ready to move our Web sites to a new server. We haven’t done this before, so we’re trying to make sure we have all the information we need before we start the process. We’re using IIS on Windows 2000 as our Web platform. Is it just a matter of copying the directories between servers?Microsoft BaseLine Security Analyzer against the Web server before starting to port over the Web sites. I would caution using the IISLOCKD tool. Although created with good intentions, in calls with Microsoft Support I learned that it generally causes more problems than it prevents. Part of the IISLOCK installation also installs a tool called URLSCAN. This can be a little easier to deal with on fixing problems, most of which can be dealt with by modifying the urlscan.ini file.

– Via the Internet

Unfortunately it will involve a little more work than that. Before getting started, make sure the new server has all the latest patches installed and you’ve run the 

Depending on how you created the sites, using FrontPage or another Web creation tool, you may find it easier to re-publish the site to the new server. If you edit your site live on the server, it may be better to open the site in whatever tool you’re using and then use the publish function to bring the site over to the new server. If you haven’t already done so, now would be a good time to document the directory setup and any permissions relative to those directories; you’ll need to recreate those permissions on the new server. One thing you can do during the migration process is periodically do a metabase backup in Internet Service Manager. This will give you a easier way to fallback to a known working configuration if you make a change and can’t resolve a problem by reversing the change you made.

Depending on what type of database access you have in on your Web sites, you may need to install those database engines or the appropriate software on the Web server, as well. This is one of the areas that should show up when you document the current server before you begin the migration process. If you do have to deal with database access, make sure the new engine is patched to the same level as the current implementation before trying to do any testing or migration. The best advice I can give is to proceed slowly. It may take a little longer now to do some testing but the payoff will fewer problems after the migration is done.