SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Ive finally got my hands on enough disk space and servers to create a mirror of our live sharepoint farm for CU testing and application testing and was wondering whats the best way to create the mirror. Is there a step by step guide that i can follow. We currently have 5 servers (2 wfe's / 2 application servers and 1 sql server), all virtulised. Any help is greatly appreciated.

share|improve this question

I'd use the Sharepoint Farm backup option. This backs up everything including web applications, solutions, service applications etc.

Read more here:

share|improve this answer

The starting point would be decide between a physical mirror or a virtual mirror. Typically, a mirror farm also known as "staging farm" is a physically separate environment with the same hardware and software configuration to that of your production farm.

There are pros and cons to both creating a physical mirror and a virtual mirror , but the bottomline is if you want sanity in your patching , operations and release management keep the topology same in your staging farm as compared to the production. Additional replication consideration for staging should be given to :-

Site structure as your production environment.
Network applicances as your production environment (i.e. Load Balancers, etc)
Farm, Site Collection, and Site features enabled.
customizations and third party tools.

Your staging SharePoint implementation does not need to have the same horse power as your production environment, as long as you are not completing performance testing on your staging environment.


Detailed steps for creating a staging farm is out of scope here however I can outline a few key considerations involved :-

  1. Replicate your OS (prefer fresh creation to OS imaging of production servers) if you are planning to create the staging server on the same network . The reason behind replicating OS images is getting trouble with AD hostname conflicts and other issues since staging would be joined to the same AD as the production.

  2. Prefer an isolated AD + SharePoint environment for staging. Mirror your AD as well to have better staging isolation.

  3. Dont skip or lower any load balancing or clustering aspects in the staging from your production farm. Most often, these architectural similarity are day saviours when hotfixes or CU decides to go rogue.

  4. Incase you have other Line of Business data connected from SharePoint Production coming up as consumable information as reports, bdc , pps ,etc. Do plan to have their corresponding staging environments connected with your SharePoint staging environment.

  5. Prefer a Content DB attached migration over a complete farm restore as it will require you to rename your staging servers post restoration and also help you gain insights on a consolidated checklist of items of your production in case of future farm movements. In my personal experience it has been always more helpful than expected.

  6. Additionally, try to create powershell driven scripts for your migration from production to staging. This has long term benfits and prevents manual intervention for all subsequent farm movements.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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