Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

While migrating our existing sharepoint portal from MOSS 2007 to Sharepoint 2010 we need to find out all customazation has been done on site. customization like Custom Workflow , Content Types or Features etc.. How we can find out all customization done? Is there any way using which we can list out all customization?

share|improve this question
add comment

migrated from stackoverflow.com Oct 14 '11 at 12:07

This question came from our site for professional and enthusiast programmers.

5 Answers

If you didn't already - upgrade your MOSS 2007 Farm to SP2 + October 2009 Cumulative Update (or newer), then go to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Bin and type in the command:

stsadm -o preupgradecheck

This command won't change anything in your farm, but will generate a report about your farm health, customizations, features and all stuff you will need to migrate. Don't even try to migrate without using this command :) Good luck.

share|improve this answer
add comment

When prepping for an upgrade you will want to run the pre-upgrade check on 2007. It was originally introduced with SP2, but improved with the Oct 2009 CU (also included in SP3). This will analyze your farm and also provide a detailed list of all features installed or referenced. Any missing features will be identified by GUID and must be cleaned up prior to migrating or you risk a failed upgrade status.

"Customizations" that do not include features such as those manually created via the UI or SharePoint Designer are much more difficult to find. You can perhaps develop some powershell scripts that look for things, but in most cases you will go site by site and review the Content Type, Site Field Listing, and connect to SharePoint Designer to see if Workflows exist.

In my experience, the feature related customizations have been the only real issues. Missing features, or features that do not support the upgrade (some Fab 40 templates) come to mind. Custom Site Definitions can also be problematic.

share|improve this answer
add comment

In addition, after you get your report these may be helpful:

If you install PowerShell on your servers you can use the following to extract custom solutions to wsp using the following (I got this from someone else, but I don't recall, so if anyone knows, feel free to add the attribution):

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")

function Get-ScriptDirectory 
{ 
  $Invocation = (Get-Variable MyInvocation -Scope 1).Value 
  Split-Path $Invocation.MyCommand.Path 
} 

$farm = [Microsoft.SharePoint.Administration.SPFarm]::Local

foreach ($solution in $farm.Solutions)
{
  $solution.Name
  $location = Join-Path (Get-ScriptDirectory) "Solutions"
  $location = Join-Path $location $solution.Name
  $solution.SolutionFile.SaveAs($location);
}

Additionally if you have features that are missing but show installed you can remove them via STSADM or this tool prior to upgrade:

Feature Admin

share|improve this answer
add comment

The best way I've found to identify customizations is to do a directory comparison of your current environment against a clean install at the same patch level. Ideally, you'd compare the SharePoint Root Folders (or 12 Hive in SharePoint 2007), the web.config files and the GAC.

I outline one method of comparing SharePoint Roots with PowerShell on my blog at: http://tomresing.com/blog/Lists/Posts/Post.aspx?ID=5

share|improve this answer
add comment

As others have said, the preupgradecheck is critical and must be done in the 2007 environment. It's also wise to run the Test-SPContentDatabase PowerShell cmdlet on all servers in the 2010 environment before you attach/upgrade the databases.

preupgradecheck will identify those items in the 2007 environment, but Test-SPContentDatabase physically checks the references in the database against the physical bits on the box to ensure everything referenced is installed. If Test-SPContentDatabase doesn't come back clean, you'll likely have errors or warnings in your upgrade that could produce bigger issues down the road.

Edit: Updated to include this blog post out on Joel's site for the use of the upgrade PowerShell cmdlets (including Test-SPContentDatabase).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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