Some guidelines on how to use site Backup and restore as deployment method in SharePoint2010

Recently, I have done a lot of site deployment using site Backup and restore as deployment method in SharePoint2010 instead of packaging everything as WSP. It is great way to deploy a configuration site from Dev to Uat and then to production. However, there are a few things you need to take into consideration when using this approach.You can download  a copy of the deployment script using this approach here.

1. This method is used for initial deployment, i.e. you cannot use this approach to deploy new features to existing site collection in production.
2. You have to make sure the dev ,staging and production have the same version of the SharePoint(i.e. the same Service pack , cumulative update and security update)Otherwise , you will have the following exception when restoring the site collection.

   “Restore-SPSite : Your backup is from a different version of Microsoft SharePoint Foundation and cannot be restored to a server running the current version. The backup file should be restored to a server with version ‘x.x.x.x’ or later.”
   

3. Once you restore the solution into another environment, you cannot delete that site and restore again. You should always overwrite the existing site collection. Otherwise , you will get the following errors:

   Restore-SPSite : The operation that you are attempting to perform cannot be completed successfully. No content databases in the web application were available to store your site collection. The existing content databases may have reached the maximum number of site collections, or be set to read-only, or be offline, or may already contain a copy of this site collection. Create another content database for the Web application and then try the operation again.
   

   The reason for that is :Microsoft uses the source site collection GUIDs during the installation. If you delete the site collection from the web application, it leaves the GUIDs behind, and if you try to restore same site collection (same GUID) into same web application and content database, it would throw an error. http://support.microsoft.com/kb/926321 – This is applicable to 2007 and 2010 also.Use the -Force option from Restore-SPSite

4. User accounts. If you create your content in a different farm that uses different users than your production farm, you have the potential of restoring a site that has different users. Once deployed you would have to update the site with the real users who need access.
5. Domains. If you create content in a different farm that exists in a different domain (common in companies who segregate their development/test/qa/production environments), not only could you have the wrong users as in my first point, but you may not be able to add the real users into the staging site collection before backup (if there is no domain trust)
6. Using names that indicate the environment. Say you have an intranet site. If you use the title “Intranet – Dev” when developing the site and do a backup and restore, this will transfer over to production.
7. The best approach to avoid feature dependency issues is to restore the backup and then deploy the WSP.
8. If the locations within the farm differ, you could have issues. For example, if in your staging environment the site collection is the root in the web application, but in production it’s under a managed path, you may experience broken links or images within sites after the restore because they will be referencing the wrong absolute path.

References:

http://sharepoint.stackexchange.com/questions/23809/whats-the-downside-of-using-backup-and-restore-site-collection-as-deployment-me

http://sharepoint.stackexchange.com/questions/10574/powershell-restore-spsite-error

http://sharepoint.stackexchange.com/questions/24075/restore-spsite-to-the-same-content-database