Geeks With Blogs
Michael Van Cleave Traveling the technical world, learning the language
Well, I would have to say that it went well overall.

We had prepared for doing the migration and we really worked out all of the risks that we should anticipate for the roll, but we ran in to a few complications that we didn't expect.  So, figuring that I had blogged earlier about the migration steps, I thought it would only be fitting that I also include these tips to help everyone else as well.

So early in the evening, we go the database backed up on the old server, over night transferred it to the new database server and restored it.  That next morning, we created the upgrade web application, and started exporting sites.

Now note, there are 2 people me and another user both remoting in to the application server of the farm and using STSADM export commands to export the upgraded site data to move it to a new web application with a new site structure.

TIP #1:
Only on person should do the export at a time.  Two main reasons we found were the server capability to handle 2 seperate intense processes exporting a large amount of data, and the second is we noticed on the import it seemed like the export may not have really exported all of the object (lists, calendars, sub-sites) from the upgraded sites.

TIP #2:
Use the -versions switch on the export command for STSADM.  We originally used the default and again it seemed like it really didn't export everything, we decided to set it to the max versions (4) and it did a much better job of exporting all of the objects we missed the first time.

TIP #3:
Allow for plenty of time for exporting and importing sites.  This didn't seem like it would take that long when I performed these actions in a development environment, but when we did it in production it took much longer than we had anticipated.

TIP #4:
Make sure to have a database admin engaged.  We started to get strange errors about a third of the way through close to 200 sites and found that the database ran out of physical disk space to expand to.  Be sure that you have plenty of space on your database server dedicated to the database.

TIP #5:
Make sure you have enough disk space on the drive of the server you are running the STSADM export command on.  If you have a site with a lot of sub sites and lots of content, the export will be very large.  While the export is running it is packing your files in .dat files in the <root>/Documents and Settings/<user>/Local Settings/Temp/<number>.  While it is buiding these files, you can eat up many GB of disk.  I recall one large site hierarchy took close to 11 GB of space just for that one export.  So make sure you have the space.

Hopefully this will save you some of the time we spent on working these out.

Michael

Posted on Thursday, June 21, 2007 12:27 AM | Back to top


Comments on this post: Team Site Migration to Production

# re: Team Site Migration to Production
Requesting Gravatar...
So, is it okay to delete these Manifest.xml and .dat files? I have hundreds of them clogging the drive, from over two weeks ago.
Left by Keith on Mar 07, 2012 12:39 PM

Your comment:
 (will show your gravatar)


Copyright © Michael Van Cleave | Powered by: GeeksWithBlogs.net