I have two IIS6 Servers.

Server A has a few websites running on it

Server B has more website running on it.

Server B is being taken off-line and wish to run all the sites on it as it a higher spec machine and we are trying to save costs.

I need to migrate:

  • IIS 6 meta data
  • SQL Databases
  • DLLs of custom web apps
  • User accounts
  • Website files

What would you suggest being the best way to do this. I began moving each site by hand manually but this could take some time.

After the sites are moved and I have tested they are working I know I need to update the dns to point to new server.

  • The question is about you wanting help to script all of this? – Gabriel Guimarães Oct 6 '10 at 16:34
  • @Gabriel: I kinda got "Gee-- this is gonna be hard. Can anybody make it easier for me?" out of the question. – Evan Anderson Oct 6 '10 at 16:39
  • @Evan Yep I got that too. It just seems awckward like the question says just a list of things she needs to do. I think it needs some editing. – Gabriel Guimarães Oct 6 '10 at 16:44

Some of your migration points are fairly easy, others are not. I fear that, depending on just how "custom" your "DLLs of custom web apps" are, you may be in for a lot of manual migration.

Metabase import/export is fairly straightforward. You could parse the Metabase (since it's just XML) and locate any referenced ISAPI DLLs and migrate them over, as well. Likewise, you should be able to parse the Metabase to locate any content files that need to be migrated and ROBOCOPY / XCOPY them over. (Migrating ACLs between non-domain members is a non-trivial operation, though.)

Copying user accounts and groups between non-domain member servers can be done via script.

Moving SQL Server databases is pretty easy. Detach / move / Attach... lather, rinse, repeat. If you have a lot of them you could write some TSQL to help automate the process.

When you get into custom software, though, all bets are off. If you even know where that software is storing its configuration data you're probably stuck writing one-off scripts to migrate and alter the configuration. Be wary of ugly things like hard-coded database locations, IP addresses, etc.

Moving forward, this kind of thing is a good reason to have fairly rigorous documentation / change control procedures. The next time you have to do this you'll be happy to have those kind of docs.

There's the other argument that says "You should just be running all this on virtual machines." You could always try to do a P2V of your "Server B" machine, however you need to be aware of the potential operating system and/or application licensing concerns that could arise.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy