I've inherited the maintenance and development of a client's MOSS 2007 website. The website has been maintained via SharePoint Designer since it's launch. We do actually have copies of some feature xml files that seem to have been built to originally deploy the site to the UAT environment. But then I think the site was deployed to production via database backup/restore. Since the launch all updates have been done in SPD (with copy/paste deployment).

Ideally I want to be using Features/Solutions and have all code checked in to TFS via Visual Studio. My question is is it possible to reverse engineer the site (using something like SPSource or VSEWSS) so that we can redeploy all master pages, page layouts, content types, site columns, css, images, xsl etc. and then adopt that method from then on.

I can (and will) do some testing of this myself but I wanted to throw it out there to get others' experience with this type of thing. My concerns are that IDs might differ and that pages may lose their association with either the page layout or content type etc. The site is fairly large with a few hundred subsites and approx 1 thousand pages so we won't want to be doing any manual "tidying-up" after.

Anybody done this sort of thing? Is it worth the hassle?

2 Answers 2


Ouch! I feel your pain, I have been there myself on several occasions. Its been a while, but one thing i did was reghosting the site, so that the features in 12 hive actually represented what was in the content database.

This makes the site "upgradable", so you can rebrand the site using master pages, page layouts, css etc.

I created a small tool to tell me what Page Layouts and Masters was used, and compared versions with FEATURES folder vs what was in the database (using SPD).

Then i decided what changes should be moved to the PL, CSS etc and reghosted the customizations using Gary Lapointes stsadm extensions. http://stsadm.blogspot.com/2007/09/re-ghosting-pages.html http://stsadm.blogspot.com/2007/09/re-ghosting-pages.html

hth Anders Rask


There is a tool called Solution Manager that comes with VSeWSS that allows you to reverse engineer certain Content Artefacts (things created using SPD/Web UI). You can then create Solution Packages and deploy them as Solution Artefacts. I helped write a tool called SPSource which does a similar thing, but can do content types, modules (master pages, page layouts), lists etc.

There various web casts on how this can be done on SharePointDevWiki.com web casts section linked from the http://SPSource.codeplex.com site.

In terms of customised (unghosted pages) you'll have to spin through, maybe with PowerShell and object model, to see what files in the content databases have changed that now don't use the files in the SharePoint Root folder. This could be an absolute mine field! I feel for you.

ID/InternalName wise, you have to be careful with ContentTypeId's, but when you reverse engineer it will maintain these references. I would recommend backing the entire content db up into a Dev environment, using the tool of choice and then having another environment where you can deploy your solution packages with the new Solution Artefacts in it.

The problem with this approach is that you'll find that certain Content Instances won't reflect the changes that you make to the Artefacts (from Content to Solution based). So you'd have to manually upgrade these instances programmatically using the API.

  • Unfortunately I don't think this is feasible (for me anyway). I was planning on using SPSource to get the files out of the database but it seems like too much of a headache to get them back into the site and used from the filesystem (Ghosted / Uncustomized). I may just look at using SPSource as a means to download the files into a VS project to then keep in source control. Not perfect but I'd at least be a bit more secure in the knowledge that I have proper version history and a copy of files that are not only stored within SharePoint within a VM. Feb 11, 2010 at 13:34
  • @j if you aren't backing up your content datbases, you will have more issues than code loss. Customizations are important, but most SharePoint sites hold the majority of their value in their content. If you are backing up your content databases, you do have version control and redundancy.
    – Tom Resing
    Jun 22, 2011 at 19:13

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.