What's the downside of using backup and restore site collection as deployment methods in #SharePoint2010?

Question

What's the downside of using backup and restore site collection as deployment methods in SharePoint2010?

The downsides are:

1. an not restore a previous version of SP site backup to a new version of SharePoint environment.

Answer 1

Depends on your development process, and the purpose of the site collection. For situations where the site is developed in a dev or staging environment, and then moved to a production environment, there isn't really anything wrong with the backup/restore method for the initial deployment.

The downside comes when you need to decide how to maintain the site, and this comes down to how the site is being used. For an information only site such as a publishing site, where end users or content editors are restricted from making changes to the production version, it might be ok to continue development in one environment and use backup/restore to deploy changes to production. However as soon as the production site can be modified by end users, you're in trouble because you don't want to risk losing data by overwriting the real site with a dev version.

Answer 2

Here are some of my thoughts off the top of my head:

1. 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.
2. 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)
3. 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.
4. You can't "redeploy" again unless you first take a backup of production, and make the changes before any further changes happen in production otherwise when you restore you will overwrite these. Your users will not be happy. Paul Lucas already answered this. As I think about it, this is probably the most significant issue with using site collection backup and restore as a deployment method.
5. 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.