Sharepoint 2007 maintenance and staging

Question

I am trying to draft up a comprehensive document to assist the maintenance group for a new Sharepoint 2007 Intranet.

What I have problems deciding is what the right tool is to migrate various different elements to the customer-approval and production environment. We expect in the future to have to deal with new lists, new custom types/list templates, modified pages, new pages, and so on.

In other words, while I think adding a whole subsite is relatively straightforward, incremental changes to existing areas don't seem very easy to me. Especially because the production site has various lists which are updated by customers (bullettin boards, and so on).

So far the best answer seems to be http://www.codeplex.com/SPDeploymentWizard but I have a few residual problems with it:

1) It's beta, and it is not an Official Microsoft Product. So our customer may not be very confident 2) It needs to be installed on all the servers where you want to deliver your changes, and works through a GUI component. This, again, would be something the customer won't be very happy with (their stuff is managed by a third party, just think of EDS or similar companies).

Has anyone used it with confidence in production related scenarios? Do you have different alternatives to suggest?

TIA,

Paolo.

Answer 1

The danger with the content deployment wizard is not actually that it may not work, but more that you may try to migrate objects that are better released as a sharepoint solution with a specific feature.

Specifically, New lists should be released with as a list template defined in a feature. New custom fields must be released with a solution.

A good rule of thumb is that content (i.e. text on pages and documents) can be migrated. Structure (new list types, fields) needs to be released as a solution.

Modified and new pages can be created manually on the site and published when ready. If they absolutely must be released in bulk then the wizard will help.

I have used STSDev also from codeplex in order to create the required solution packages. Remember that even though these tools are not "Official Microsoft Products" they are often heavily used by Microsoft Professionals themselves and would be official tools if the release criteria for "officialdom" were not such a long process.

Check the authors of any tool, most of them will have a blog and that will get you a good idea of the experience and relationship to Microsoft the author may have.

I have not used the SPDeploymentWizard, but from the codeplex site

Content is exported using the Content Migration API (PRIME) as a .cmp file (Content Migration Package) which can be copied to other servers for import. Unlike the out-of-the-box tools, the Wizard allows granular selection of content via a treeview.

That means the tool is a gui wrapper for an "Official Microsoft process", making it easier to select the content you wish to place into a migration package.

The subject of your question is not an easy task in practice and the tools and techniques for doing this are improving and changing, so keep tabs on the blogs and codeplex for advice.

UPDATE

The migration tool should be fine for only the documents and pages you need for each release.

For lists I have create temporary templates that contain all the items, but this is pretty much still a manual release process. So try it with the content migration tool, because you are not making structural changes to the site, it will be possible to delete the list if it does not do things correctly.

The real issue is just to make sure the the content type id and content field id guids are the same from server to server, but with any customisation release by solution/feature packages, there should be no difference.

UPDATE 2

For individual pages, we created a powershell script that would, given a url, a list of files and an action either download the pages from the server to a local drive or upload them. It is pretty easy using the object model to create the pages, custom attributes are a bit trickier, but checking in and publishing the pages was not much of a major.