Synchronizing Content Between Farms on SharePoint 2010

Excellent Article by Mor Shemesh

 In this post I'm going to give a concise review of all the solutions I've came across that enable Copying and Synchronizing content between SharePoint Farms (also Deploying Content Between SharePoint Farms) mainly for the purpose of migrating developments and implementations between environment once they have changed.

These solutions are relevant for SharePoint 2010 and provide a collection of articles and links to make the decision more comfortable.

Why?
First off, I wanted to do this post because I've heard many clients that ask me about the right way, wrong way and best way. The truth is like always, it depends.

First Migration
When developers first intend to migrate a solution between environment they would usually choose to perform a backup\restore of the Site Collection using Backup-SPSite and Restore or using Export-SPWeb and Import-SPWeb.
I personally like to use the backup\restore approach.
If the given site is particularly large and contains many developments\implementations I always try to plan and build the site in a separated Content Database and add that content database to the target environment.

Backup\Restore
Here are a few helpful links on the matter (best examples I found were on MSDN):
Backup: http://technet.microsoft.com/en-us/library/ff607901.aspx
Restore: http://technet.microsoft.com/en-us/library/ff607788.aspx

Export\Import
http://secretsofsharepoint.com/cs/blogs/tips/archive/2010/09/17/importing-amp-exporting-sites-in-sharepoint-2010-using-powershell.aspx

The big differences:
Backup\Restore will move all your data and rights, plus, it will create the corresponding records in the content database. Export\Import is quite a different approach. It will export all the file, data and metadata into a cab file from which it will import and create the new content. You can use it only for web sites (not site collections). It can also move the site security as well if you set the corresponding flags. Check the other options to see the different options

Add a new Content Database:
technet.microsoft.com/en-us/library/cc825314.aspx

Move SharePoint Site between Content Databases:
http://technet.microsoft.com/en-us/library/cc825328.aspx

Detach Attach Content Database:
http://drekendrop.blogspot.co.il/2011/03/sharepoint-2010-detach-sharepoint.html

Site Templates
Another approach I see sometimes taken is saving the site as template and creating a site from that template in the destination environment (Thanks to Ohad Ben-Shalom for pointing that one out).
You can also achieve that on a site collection by creating a new site collection and later choosing the template:
http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=218

Keeping it all Synchronized:
Mainly, there are 3 main approaches:

1. Content Deployment Job (Manual)
2. Open Source Solution (Manual)
   
3. Third Party Solutions (Manual\Automatic)

All of the solutions I will present here are based on the Export\Import Object Model provided by SharePoint. This is also the same method stsadm -o export\import and Export\Import-SPWeb (PowerShell) use when run from the console.
For more information click here: SPExport and SPImport.

The big difference between each approach is how flexible it is against how much effort you would need to suite it to your needs.

Approach	Cost	Flexibility	Pro	Con
Content Deployment	OOTB	None	OOTB and little configuration	No Flexibility\granularity. Content will have to stay identical to source environment
Open Source	None	Very	Very flexible and can be changed according to client needs	Required Programmers for development
Third Party Solutions	Varies	Highly flexible (you can probably find any need you might have answered by one or another product)	No code, flexible, comfortable	Can reach very high cost. You might depend on company's customer care.

Solutions

SharePoint Content Deployment Job
When to use and how to prepare to use Content Deployment (MSDN):

http://technet.microsoft.com/en-us/library/cc263428.aspx#use

How to define Content Deployment:

According to Technet you can perform the following actions between farms so long as they have trust relationship between both domain and farms.

http://blog.beckybertram.com/Lists/Posts/Post.aspx?ID=83

http://www.benjaminathawes.com/blog/Lists/Posts/Post.aspx?ID=7

http://www.sharepointboost.com/blog/using-content-deployment-to-copy-one-site-collection-to-another-in-sharepoint-2010/

Pros:

• Easy to use
• Out of the box

Cons:

• The content in the target environment will always have to remain identical to the content in the source environment
• No Flexibility

Usage of Open Source Code and Code in General

SPDeploymentWizard from CodePlex (includes a user interface): 

1) http://spdeploymentwizard.codeplex.com/

2) http://sharepointpsscripts.codeplex.com/

Including a set of PowerShell Functions for performing Export\Import between sites.

Examples of how to use SPExport and SPImport from MSDN:

http://msdn.microsoft.com/library/aa981161(office.14).aspx

Third Party Solutions

I've came across mainly 4 third party solutions:

AvePoint DocAve Replicator:

http://www.avepoint.com/sharepoint-replication-docave-V6/

http://www.avepoint.com/assets/movie/SharePointMigration/Making_the_Leap_Moving_to_SP2010.html

Tsunami Deployer:

http://www.tzunami.com/products/Pages/TDSharePoint2010Migration.aspx

Repliweb ROSS:

http://www.attunity.com/products/attunity-repliweb-for-sharepoint-ross

Metalogix:

http://www.metalogix.com/Products/Migration-Manager-for-SharePoint/SharePoint-Upgrade.aspx

All Products offer basically the same functionality (plus, minus different perks here and there), but what differentiates them one from another is the quality of the product and the support they offer.

Personally I haven't used any of them, but from what I can gather in the market and from all the people I come in contact with, AvePoint company's (DocAve) products do the work and they provide a very high level of customer service and support.

Summary
For conclusion I will give you the way I perform the deployments between environments:

1. Each project should be checked and planned for individually before development\implementation begins.
2. It is always preferable to create the site as a new Site Collection (and if there is sufficient need you can create the Site Collection on a new Content Database)
3. First Deployment\Migration with Backup-SPSite\Restore-SPSite (If this is a Content Database you can migrate with DB Backup\Restore or Detach\Attach)
4. Incremental deployment of content with SPDeploymentWizard.

Please feel free to comment on this post with experiences you've had with products and how you work when synchronizing between environments or you disagree with what I wrote.

Reference:

http://morshemesh.blogspot.in/2012/08/synchronizing-content-between-farms-on.html