I wanted to find out the best practice to migrate changes from a development site to staging or production site. I think there should be a better way than backing up the content database on development and restoring it to staging. This requires you to redo web parts. I just want any changed done on development to be moved to the staging environment. Can someone help me with the best practices or way to do this?


Regarding migrating the development changes Regarding the pushing development changes from Development to staging can be done using WSP packages. You develop everything on development server, package it (WSP) and deploy the same package to staging environment and test it there.

Regarding migrating the content As Dave said, it is not recommended to push up the content changes from Development to staging but it is possible peform this task using the Content deployment. It is a feature that can be used in SharePoint to deploy content from a source site collection to a destination site collection. The complete source site collection can be deployed, or a subset of sites can be deployed. Content deployment, which is incremental by default, deploys only Web pages, libraries, lists, and resources that are used by the deployed pages. It does not deploy programs, assemblies, features, or configuration information such as Web.config files. When a Web page is deployed, any items in the content database that the page depends on — such as images, style sheets, or layout pages — will also be deployed.


Automatically pushing up from dev to staging is not really recommended as the dev environment tends to be a pretty wild and uncontrolled place and you really don't want all those changes bubbling up without something in place to manage them. The Best Practice actually follows two paths based on what is being moved:

  1. Code (i.e. WSPs) is deployed as normal from Dev-QA-Staging-Production
  2. Content (i.e. pages) are deployed forward from Staging to Production or backward from Staging-QA-Dev

The reason for this is because the code is authored by developers and usually must exist before content can be created for new functionality. Content, however, is usually created by end-users or power users and they need a relatively stable environment to do this.

What we have done in the past is to let the developers create content and code in dev as they need that to do their jobs, but in QA or staging (depending on how your farm is built) the Content Authors handle creating the content once the code has been pushed into that farm. It is not uncommon to have to create content twice but, again, that depends on your farm.

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.