My department head is insistent on having a Development and Production Server for our SharePoint sites. After speaking with some other professionals and working with the technology for several months, I am beginning to question the necessity of having this.

It seems that SharePoint is a fairly stable platform, and solutions that we are developing could be hidden from users while we work on them.

I am experiencing incredible difficulty while building workflows and Info Path form Libraries and then trying to migrate them to a different web\site application.

Should you have a development server for your SharePoint, or is this just causing more work for your developers?

  • FYI: We are not preforming any custom branding, nor are we extending SharePoint through custom code, event recievers or workflows created in visual studio.
    – Patrick_J
    May 1, 2012 at 13:58

4 Answers 4


I would lean more for having at least two server environments - development & production. In many enterprises there is a third (or perhaps more) server environments - QA/Testing/Staging.

There is also a matter of the business industry where the IT development & deployment takes place. In certain industries like HealthCare and Financial Services, there are very strict protocols and processes that have IT very heavily regulated (including fines & legal actions). For HealthCare, it is the HIPAA regulations and for Financial Services, it is the Sarbanes-Oxley regulations. Both emphasize security, privacy & audits in the IT environments. For example, in many such businesses - the developers are not "permitted" in the production environment and direct development on the production servers are verboten.


My personal opinion in regards to InfoPath and (SPD) workflow development is to do it in production. These activities and functions are nondestructive to the platform. Users are blocked access to the site and granted when the solution is ready.


The term "Development" has a lot of meanings within SharePoint. If you mean that you are doing customizations via SharePoint Designer then you can make those directly in production, as Eric said. Content can be created directly in production as well. However, if your development involves compiled code in any way then you really want that moved to a separate farm as deploying solutions with code can restart your application pool which would result in an outage of your production farm. Developers also have a habit of attempting to debug code and that process will block all requests from your site.

In almost all companies I've worked at that deploy SharePoint, there was a true production farm, an optional Authoring farm (content management) a QA farm (restricted access), and Integrated Dev farm (for bringing dev solutions together) and numerous virtual machines (one per developer) each acting as stand-alone farms for the purposes of development. This may seem like a lot but if you have any of the Separation of Duties requirements that sbc111 points out then you likely need them all.

  • In my current client project with a major Financial Services company - SharePoint Designer is specifically NOT installed in the Production environment. Most of the environs management are PowerShell 'scripted' which has controls as well. Apr 30, 2012 at 19:23
  • In a more formal environment, there is usually an Authoring site and/or farm. Designer is installed on the machines of the people in charge of the changes and then they make the changes on Authoring where it goes through the approval process before being pushed to Production. This only applies to Designer 2010, though. Designer 2007 was WAY too destructive to put in the hands of the average content creator
    – Dave Wise
    Apr 30, 2012 at 19:46
  • Dave, in my situation I am building applications stirctly using "Out-of-the-box" solutions. I am creating forms using InfoPath and then building workflows in SharePoint Designer. I add no custom code behind the forms or on the workflow.
    – Patrick_J
    May 1, 2012 at 15:33
  • 1
    A dev farm in that scenario is overkill in my opinion, unless you need it due to regulation. OOTB InfoPath and SPD workflows really don't need a dedicated dev environment. May 1, 2012 at 16:26

Microsoft's pattern and practice group released guidance around SharePoint development http://spg.codeplex.com/. The guidance suggests the route of multiple environments (DEV -> QA -> Prod).

It sounds like you are creating content rather than traditional code artefacts.

You could always use content migration jobs to move your content between your different SharePoint environments.

In my opinion just because its SharePoint doesn't mean you that can't follow the traditional SDLC workflow and have all the advantages that brings.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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