We have convinced a number of customers that their SharePoint solution is a critical business system and should be handled as such.

This will in most cases include a staging environment, but migrating a clone of the production system to a test server takes forever, includes a lot of manual steps and seems to be errorprone.

I guess that somebody out there must have made a production grade migration tool, but which one actually works?


There are several SharePoint ISV's making great products out there for this type of scenario, depending upon your failover limits and the type of output storage needed.

The 2 best are Quest's and AvePoint's recovery tools for ease-of-use and cost, but there are also several others (e.g. Symantec, Microsoft, etc.) depending upon how much infrastructure you can throw at them or already have in place.

  • Thnaks, I'll check out Quest and AvePoint and revert with my findings, but if any of you out there have links to blog posts about the subject, I sure would like to hear from you :-) – Kasper Bo Larsen Nov 19 '09 at 22:16

What are you looking to stage? Content or functionality?

I'm absolutely for having multiple environments available for testing functionality, but I don't see value in duplicating complete content sets for an entire environment. In addition to the pain and time involved with setting it up or synchronizing it, you have the cost for storage. In the enterprise, 1Tb+ environments are not all that rare.

I typically look to configure the system in a consistent way in the staging environment, but then use subsets of the content specific to what you are testing.

For testing applications, if everything is provided as a feature/solution then it is easy to test the deployment in multiple environments.

With regards to the tools mentioned above, I have had a lot of very good experience with AvePoint for moving/migrating content. It has been very effective for me. I have not used it to migrate applications though.

  • I have a client-server background so I am looking for a way to mimic the relative ease of creating a verbatim pre-prod environment. I would prefer both functionality and content in order to be able to test both functionality and performance with real data loads. – Kasper Bo Larsen Nov 20 '09 at 23:06
  • I think there are different things to test. In some cases it might be a good idea to test it under load with matching content. Way back when, I had an issue with a large ECM solution that tested fine in one environment, but not in production due to the amount of content. I just haven't seen those issues with SharePoint yet. When the platform is properly deployed it scales fairly well in most cases and is made to be distributed. – Mike Oryszak Nov 21 '09 at 0:59

We use the SharePoint Deployment Content Wizard to migrate content from prod to staging. It is good for the QA testers to work with actual data and it is good to test staging with as close an environment as production (amount of data, load, etc.).

For key sites that require a more frequent refresh we will script the content refresh and schedule it. To offset load, different sites or site collections could be refreshed on alternate days.

Typically a farm will have some sites that are more static than others. Refreshing those less frequently will also reduce load.

Certain team sites and my sites do not get refreshed on staging as there is no real value.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.