Hi, We have a MOSS 2007 installation, SP1, v 12.0.6219.1000 From there we want to do a Backup via SharePoint's Backup/Restore under Operations The new server is MOSS 2007, SP 3, v 12.0.0.6608 It's a straight forward MOSS installation, no third party customizations or anything. The Application Servers will change during the process too. Here is the plan we are going to use: http://technet.microsoft.com/en-us/library/cc896556.aspx Does anyone have any advice, any known issues or things to watch out for? Does the minor descrepancy in the MOSS 2007 versions matter? Does Backup/Restore preserve the GUIDs? If no, does it matter if they are not being used outisde of the new MOSS config? How long do you estimate a backup/restore operation with a 500 GB Content Database to take?

Do you mean that the new server is MOSS 2007, SP 3 (that's the version that corresponds to the build number you've listed)? I would not recommend using SharePoint's backup/restore tools if your farm has that much content in it (500 GB or more if you have multiple content databases). Microsoft does not recommend the use of SharePoint 2007's build in backup/restore tools with content databases over 100 GB in size or site collections larger than 15 GB (see http://technet.microsoft.com/en-us/library/cc263427(v=office.12).aspx for more info). I would recommend the following: Build out the new farm and configure it to be as close to a replica of the current farm as possibleMake sure to identify any customizations that have been deployed to the original farm and then deploy them to the new farmTake SQL Server backups of the current farm's content databases Restore those backups to the new farm's SQL Server instanceCreate replica web applications to match the existing web applications on the current farmAttach those restored content databases to the new web applications in the new farm I would also make the following suggestions: I would recommend, if possible, to either fully test and confirm that your SP1 content databases can be attached to a SP3 farm and will function properly before attempting it in production or to wait to upgrade the new farm to SP3 until you've got the restored content databases attached and verified as functional. Attaching a SP1 content db to a SP3 farm may work fine, but SharePoint service packs often come with a lot of changes and I don't know if those databases will be compatible enough to be upgraded across two full service pack upgrades like that (the build numbers may seem close but that's definitely not a minor discrepancy in version numbers). I haven't tested it myself, so I would at a minimum advise caution and strongly encourage you to test the heck out of it.I would recommend really taking a look at whether or not you want to try to move the SSP or just rebuild a new one in the new farm. I'm not saying its impossible to back up an SSP and migrate it like the article indicates, but is it worth the effort to attempt or will it be quicker to just create a new one in the new farm? Again, if you decide you want to do it, I would really recommend testing it thoroughly to make sure it brings over everything you need. If you absolutely want to create replica of your current farm, don't do it with SharePoint's backup and restore tools. Also, don't think about taking a SQL backup of your current farm's configuration database: restoring it to a new farm is not supported. If you need it, you're going to have to use an external backup tool such as Microsoft's Data Protection Manager 2007 or one from a third party vendor such as AvePoint, Idera, Quest, or a host of other options.Also, I'm not sure which GUIDs you're referring to in your question... SharePoint uses a lot of them :) Are there ones in particular you're wondering about?Its very difficult for me to guess at how long a SharePoint backup of over 500 GB of content is going to take, for a few reasons. First of all, I've never tried it because of Microsoft's recommendations. Secondly, there are a lot of hardware and network variables that are going to play into an estimate like that (if you have slow disk its going to take longer, things like that). Third, I really wouldn't recommend trying it, because of the size you could be impacted by timeouts or locking, or even face an issue such as the back up completing but not being usable because it is corrupted. John JohnMCITP and MCTS: SharePoint, Virtualization, Project Server 2007 My books on Amazon: The SharePoint 2010 Disaster Recovery Guide and The SharePoint 2007 Disaster Recovery Guide. My blog: My Central Admin.

Thank you! If we go with DPM 2007, how long do you think it will take, 8 hours, 24 hours, 48? Rough estimates appreciated in scheduling this process.