I just created a Virtual Machine on my laptop with Windows 2008 R2 Standard + SQLServer 2008 Standard + SharePoint 2010 Enterprise (everything on Single Box).

I want to start my development of my company's intranet site as per the organogram provided consist on almost 12 departments (Large Financial institution).

What should be my strategy for development as I don't have experience of deployment so I am kinda scared and clueless. What i want to ask is.

  1. If I do development on my VM and create sites and some workflows using Sharepoint designer and later when I decided its time to show my work to the relevant department than should I create a new VM with the fresh installation of SharePoint 2010 like the development box?

if yes than how to move my entire work from development to Staging??? or what do you suggest how should I do it. (Best practices which will be fruitful later on)

2 Answers 2


Focus on packaging up EVERYTHING as Features, Site Definitions, DLLs, etc in a WSP. You will use this portable installer package to deploy to other environments (staging, production, etc).

There will most likely be some extra work involved in "solutionising" any custom funcionality that was created with SharePoint Designer. You will need to get familiar with Visual Studio if you haven't already, as this is where you "design" you WSP.

  • 1
    Working on .NET (C#) using Visual Studio 2005, 2008 and now on 2010 professional since 4 years now :) but I am completely new to SharePoint 2010. So instead of using STSADM to migrate contents from one place to another I need to create a complete package which caters features, site definitions, dlls in one WSP file and run the installer....but what if I don't use customization and want to use out of the box stuff in that case how to create one package?
    – user239684
    Commented Apr 20, 2011 at 11:20
  • I'd concur with Jaap, we do everything with WSP's because we deploy to multiple environments from SVN. It took awhile to get the builds to happen right, so they would happen on a build machine NOT on the local development box. The work was mostly to get MSBuild to work correctly, but now it works fine...if only deployment was so easy on the farm. :(
    – MichaelF
    Commented Apr 20, 2011 at 12:20
  • if you have no custom code and only want to move content from one environment to another, have a look at the STSADM export/import commands or their PowerShell equivalents (technet.microsoft.com/en-us/library/ff621081.aspx) Commented Apr 20, 2011 at 12:30
  • Jaap thankssss lot...now my concepts are getting clear as I am getting replies from all of you. So it means once I will move the contents on production and later if i add new site into development so i can take backup of that newly added site using STSADM and restore on production...am I right?
    – user239684
    Commented Apr 20, 2011 at 12:36
  • yes, but you would either add the site as a new subsite to make sure you don't overwrite anything, or you import it on production to overwrite what was there (in which case you lose your production content). It get's tricky when you want to "merge" content. Commented Apr 20, 2011 at 12:49

It may be worth investing in some outside advice. As Jaap correctly states, for the packaging of the features which will be used to build the site structure you should use WSPs. Also investigate Feature Stapling to correctly attach the features.

However, in terms of ensuring you end up with a SharePoint deployment that not only scales well, but that is used effectively within your organisation, I advise that you invest in some information management and SharePoint consultancy to help you tap into the features of SharePoint that are most relevant and useful to your organisation.

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.