Monday, June 7, 2010  by Marc Charmois - About Me / Previous Posts / Archives - Home

Migrating to SharePoint 2010

Introduction

This post will show 2 possible scenarios to migrate from MOSS 2007 to SharePoint 2010. In order to demonstrate one of the worse case, we will start from a farm running MOSS 2007 SP1 on 32-bit Windows 2003 server OS. I have chosen two hybrid scenarios among those exposed in the Microsof documentation Determine upgrade approach (SharePoint Server 2010)  because their are safer since for each scenario we will upgrade on a copy of the farm:

1: Database attach with read-only databases
Lets you continue to provide read-only access to content in your MOSS 2007 web sites during the upgrade process. For this approach, you set the MOSS 2007 databases to read-only while the upgrade is in progress on another farm where SharePoint 2010 is deployed. This method reduces perceived downtime for your users.

2: In-place upgrade with detached databases on a separate Farm
Lets you take advantage of an in-place upgrade's ability to upgrade content and settings, while adding the speed of a database attach upgrade. For this approach, you use an in-place upgrade to upgrade the farm and settings on a separate farm that is a copy of the farm, and to detach and upgrade multiple databases in parallel on this separate farm.

Before detailing the steps required for these scenarios I would like to draw up the list of the benefits and drawbacks of these hybrid scenarios comparatively to the two basic approaches (in-place and database attach):

Pros:

  • Safer : you upgrade the content for the environment on a separate farm so you keep your old MOSS 2007 Farm intact.
  • More service availibility:   Although the sites of your old MOSS 2007 Farm that are involved in the migration process are in read only mode, they still can display content to the users during the migration process. The sites that are not involved can be used as usual. This method reduces perceived downtime for your users.
  • Faster upgrade time: You can upgrade multiple content databases at the same time, which results in faster upgrade times overall than an in-place upgrade.
  • More flexibility: You can use a database attach upgrade to combine multiple farms into one farm that allows you to take advantage of the migration to reorganize your architectures.
  • Cleaner: as you have to replicate all the environment configurations and customizations on the new farm, you will take advantage of this work to move only the nece ssary files and perform only the necessary configuration operations.

 

Cons:

  • More expensive : Except if you are using virtualization, you will have to plan until twice more machines than for In Place upgrade.
  • More work : You will have to replicate all your old Farm cutomizations on the new SharePoint 2010 Farm

 

And here are the pros and cons of these two hybrid scenarii:

1 - Database attach with read-only databases
Pros
If you’re running MOSS, each Shared Service Provider (SSP) and its settings will be upgraded and converted into new service applications. Source: Migrating to SharePoint 2010
Cons
You will have to mount a MOSS 2007 farm on 64-bit, then use an In Place uprade on the new farm for the settings, finally use an attach database upgrade for the content.

2 - In-place upgrade with detached databases on a separate Farm
Pros
You have not to upgrade your MOSS 2007 farm to 64-bit, then to upgrade it to SharePoint 2010, you save one step
Cons
For those running MOSS 2007, you should know that a database-attach upgrade won't fully upgrade your SSP into new service applications. When you attach an SSP database, only your user profile store is upgraded. Search settings, Excel Service settings, Business Data Catalog (BDC) application definitions, and other settings must be recreated from scratch. Source: Migrating to SharePoint 2010

Conclusion : if you have a lot of SSP settings like advanced search settings, wide use of Excel Services,etc. consider to use the scenario 2 otherwise, scenario 1 is quicker.

Steps of the migration

1 - ugrading the SharePoint Farm with MOSS 2007 SP2
2 - upgrading the SharePoint Farm with MOSS 2007 October 2009 Cummulative Updates
3 - running the pre-upgrade tool: pre-upgrade checker
4 - Scenario 1: performing database attach upgrade with read-only databases
4.1 - Building a SharePoint 2010 Farm
4.2 - Determining how to handle customizations
4.3 - Moving the customization to the SharePoint 2010 Farm
4.4 - Moving and Upgrading the Content to the SharePoint 2010 Farm
4.5 - Restoring and Upgrading the Content on the SharePoint 2010 Farm

5 - Scenario 2: In-place upgrade with detached databases on a separate Farm
5.1 - Copying the MOSS 2007 farm to upgrade to 64-bit
5.2 - Performing an in-place upgrade to upgrade the farm and settings
5.3 - Moving the Content to the SharePoint 2010 Farm
5.4 - Restoring and Upgrading the Content on the SharePoint 2010 Farm
5.5 - Fixing the customizations.

1 - Ugrading the SharePoint Farm with MOSS 2007 SP2

1.1 The different operations list

One of the prerequisites before migrating to SharePoint 2010 is to patch your SharePoint farm to at least MOSS 2007 SP2. This requires several operations:
Running the SP2 fo WSS
Running the WSS SP2 for each Langauge Pack
Running the SP2 for MOSS 2007
Running the MOSS 2007 SP2 for each Langauge Pack
Doing all that for each server of the Farm

1.2 A sequence sample

For each hotfix the sequence will be the same.

First you will have to run the installation of binaries.

After the hotfix binaries installation, the SharePoint Products and technologies wizard will be launched,

There will be a first warning informing the system administrator that IIS, SharePoint Administration Service, SharePoint Timer Service may have to be started or reset.
But, more important there will be another message that will inform that the same upgrade operation has to be done on every Server of the Farm.

Then the wizard will perform the configuration steps.

It will inform the system administrator that the configuration was successfull

With this windows for WSS 3.0

and this one for MOSS 2007

Finally, when closing the wizard, the SharePoint Central Administration web site will be lauched.

1.3 Validating the Upgrade

First of all let us check the version of our SharePoint Farm. You can check the version number on the settings page of any SharePoint site of the Farm, or in the Central Administration on the "Servers in Farm" Page.

You notice that SharePoint 2007 SP1 correspondig to this version number : 12.0.0.6219

What you have to check after having applied the WSS 3.0 SP2 upgrade, is obtaining this new version number : 12.0.0.6421

What you have to check after having applied the WSS 3.0 Language packs SP2 upgrade, is obtaining the updates information for the language packs  in the "Add and Remove Programs" pannel:

What you have to check after having applied the MOSS 2007 SP2 upgrade, is obtaining the update information for MOSS 2007 in the "Add and Remove Programs" pannel:

It seems that there is no way to check the complete installation for MOSS 2007 language pack SP2, in my case, the "Add and Remove Programs" pannel did not show the update information as you can notice on the above picture.

Now is the time to navigate through SharePoint Portals of the upgraded farm in order to check they still run perfectly well.

2 - Ugrading the SharePoint Farm with MOSS 2007 October 2009 Cummulative Updates

While it is enough to upgrade a MOSS 2007 Farm with SP2 to be allowed to migrate to SharePoint 2010, and that is the minimal step to get the SharePoint 2010 pre udate checker installed, it is worth to uprade the Farm with October 2009 Cummulative Updates in order to have the best version of the tool.

Download the MOSS 2007 October 2009 Cummulative Updates

You will have to register to obtain them. The link to them will be sent to you by e-mail with the password to unzip them.
Then you will run them and the sequence will be the same than for the SP2.

Here is the screen shots of the the "Add and Remove Programs" pannel  after the upgrade:

And you have to obtain this new version number after having run the update: 12.0.0.6520

3 - Running the pre-upgrade tool: pre-upgrade checker

Now that we have the best version of the SharePoint 2010 pre udate checker installed, because we performed an update with October 2009 Cummulative Updates, we can now run the tool.

Open an command prompt and if the STSADM.exe path is registered in the environment variable of the machine, type the following command:

stsadm -o preupgradecheck

The tool runs and traces the Potential Upgrade Blocking Issues for a migration to SharePoint 2010.

It is also generated a more complete report in html format:

If we refer to the found blocking issues, they are totally normal since, the machine OS is in 32-bit and is not a Windows 2008 version, and SQL Server 2008 is in 32-bit and was not updated. I have also several SharePoint artifacts references in the content databases but the referenced files are no more present in the file system of the server. I should have to clean them although they are no more used by any site.
So what all does this mean ? It means that we are not allowed to perform an upgrade on THIS machine (ie an In Place Upgrade), but there is good chances that a database attach upgrade works...

 

4 - Scenario 1: performing a database attach upgrade with read only databases

In our case, an attach database upgrade requires two conditions:

  1. Having a SharePoint 2010 ready to use Farm to receive our machine databases
  2. Determine how to handle customizations

4.1 - Building a SharePoint 2010 Farm

In order to train for building such an environement, you can use my previous post: Installing SharePoint 2010 on Windows 2008 Server R2 that is an example of how to mount this kind of environment using only free and trial versions of the involved products for a development machine. If you want to mount a real production environment I have also provided links to the corresponding documentation.

Do not forget to install the same language packs as in your SharePoint 2007 source farm.

4.2 - Determining how to handle customizations

First, this is the Microsoft recommendations: Determine how to handle customizations

- the case of the compiled code.

Although customizations for SharePoint come in many forms (Site templates , Site definition, Feature, Workflows and server controls, Event handler, Web Parts, Master pages and CSS files, etc.) I would like to focus now on the compiled code.
There were many questions I have read on Forums and Blogs about "Do we have to recompile or rewrite the code for a migration to SharePoint 2010 ?".
I have found several answers and the good news is that in many cases neither rewriting the code nor even recompile it won't be necessary.

but I would like to display two excerpts of the Microsoft documentation that illustrates what you have to deal with :

Excerpt 1
[...
Existing applications

You must recompile existing 32-bit applications and custom assemblies (for example, Web Parts and event receivers) to run on the 64-bit architecture because the 64-bit edition of SharePoint cannot load a 32-bit assembly. Before you recompile existing applications or custom assemblies, verify that they are compiled to run on both architectures. If this is the case, do not compile them for a single architecture. (In Microsoft Visual Studio this build option is Any CPU.)

If the existing applications are third-party applications, check with the third-party vendor regarding 64-bit versions and compatibility. In the case of custom contracted solutions for which you do not have the source, verify the solutions in a test 64-bit environment to ensure compatibility.
..]

In Migrate an existing server farm to a 64-bit environment (Office SharePoint Server 2007)

Excerpt 2
[...
Obsolete Classes and Namespaces

Because the changes to the API in the upgrades are backward compatible, you should not have to make any changes to your Windows SharePoint Services 3.0 or Office SharePoint Server 2007 custom solutions before you redeploy them in either SharePoint Foundation 2010 or SharePoint Server 2010. Some classes and namespaces are obsolete, but they will continue to work as expected. If you want to start upgrading your applications so that they use the most current classes and methods, recompile your code. The compiler warnings will tell you which elements of the object model are obsolete, and which newer alternatives you should use. Figure 3 shows an example compiler warning and the corresponding mouse-over warning in Visual Studio 2010.
..]

in Redeploying Customizations and Solutions in SharePoint Foundation 2010 and SharePoint Server 2010

So the philosophy is the following:
you can deploy a dll compiled for MOSS 2007 using the "Any CPU" or x64 build option on a SharePoint 2010 server and it will work using the 64-bit process, but if you want an optimized code you should recompile it with the new SharePoint 2010 object model. So in many case it won't be necessary to recompile but it is recommended to do it to optimize your code and to learn the new SharePoint 2010 object model.

I have published a first post on the topic: Migrating custom assemblies to SharePoint 2010 that explains some important concepts to take into account and gives an example for a Web Part , and am planning to detail some more operations for at least Event handler.

- other customization

I have not performed advanced searches on topic until now, but am planning to do it, and will certainly publish some posts on specific operations like I did for custom assemblies. Looking to the table listing the diffrent kinds of customizations and the migration impact on it, presents in the Microsoft documentation (Determine how to handle customizations ), I see 4 main important areas to review:

  1. Information architecture - sites provisionning
    Site definition and site templates
    Managed paths (inclusions/exclusions)
  2. Look and Feel - UI Experience
    Themes
    Toolbar actions
    Master pages and CSS files
  3. Custom code
    Workflows and server controls
    Event handler
    Web Parts
    Services
    Authentication providers
    Search provider or security trimmer
    JavaScript
  4. Features

 4.3 - Move Customizations to the SharePoint 2010 Farm

Depending on the decision you took about handling your customization, you can either move it on the SharePoint 2010 target platform and test it or rewrite it for SharePoint 2010 to take advantage of the new product benefits.
For the current tests, I have deployed SharePoint solutions (.wsp), installed features that was not packaged in .wsp, using the stsadm tool and typing exactly the same command lines than in SharePoint 2007 and during my content database upgrade, all the deployed files were retrieved by the upgrade process.

 4.4 - Move Content to the SharePoint 2010 Farm

Once your customizations are properly handled for SharePoint 2010, it is the time to move the content. Here are the operations for an attach database upgrade.

First this is the Home page of one of the Web Application of the MOSS 2007 farm I am going to migrate. As you may notice, I took a standard site definition : the Collaboration Portal, with a few custom Web  Parts and features as customizations.

Open SQL Server management studio and locate the Database you want to migrate and display its properties pane.

Set the Database Read Only to true

You will notice that the database icon will turn to gray

And that all the corresponding SharePoint site are now in read only mode.

Then perform a back up of the Database, and move this back up on your SharePoint 2010 Data Base Server.

 

 4.5 - Restoring and upgrading the Content on the SharePoint 2010 Farm

First copy the back up of your SharePoint 2007 content darabase in the right folder to prepare to restore this backup.

Then, create a new Web Application on your SharePoint 2010 farm to host the content dabase to be restored.

Then, open the SQL Server Management Studio of your SharePoint 2010 farm Database Server

Detach the content database...

to drop the existing connections

then, re attach the same database

You can now restore the database coming from the SharePoint 2007 farm

Do not forget to check the option: overwrite the existing database

Very important : grant the db_owner permissions to the Set-up account the wich you will be logged-in with when you will perform the upgrade for the new database, otherwise the upgrade will definitively fail!

and you will have this error in the log file

[STSADM] [SPUpgradeSession] [ERROR] [5/31/2010 11:56:27 PM]: Exception: Cannot open database "WSS_Content_WebApp81" requested by the login. The login failed.
Login failed for user 'VMDEV-012\Administrator'.

Finally, open a command prompt on a SharePoint 2010 server that hosts the SharePoint 2010 central Administration and type the following command:

stsadm -o addcontentdb -url yourWebApplicationUrl -databasename yourDatabasename -databaseserver yourdatabaseServerName

While the upgrade is being processed you will be informed of the percentage of data upgraded...  

But more interesting, a page especially dedicated to upgrade status is available in the Central Administration Web site in SharePoint 2010  and is refreshing automatically giving you the number of warnings and errors encountered during the upgrade process, and informing you about the site that is involved by the upgrade process.

Finally, the upgrade process has been completed and you can review the upgrade log.

While there are some errors the Status will be "Failed", but it does not mean that your SharePoint site will not be available. For example, assume you have provisionned some files or a list by using a feature and that someone has removed the files or the list from the SharePoint site and removed the feature from  the file system of the source farm without uninstalling it.
Your upgrade will be sucessful since the pages provisionned are no more required, but the reference of the feature is still in the SharePoint content database, and while the upgrade process does not find the feature in your SharePoint 2010 file system you will have an error and the upgrade will be set to "Failed", but you will be able to perfectly use all the functionnalities of your upgraded Sharepoint 2010 site.

and have a content database perfectly restored

In my case for a native Collaboration Portal of Moss 2007 I obtained several errors on missing features, because either they were missing in the MOSS 2007 farm file system anyway, or because I forgot to copy them in my new SharePoint 2010 server. But one was because it seems that the SharePoint 2010 release is missing a MOSS 2007 feature.

Warning : It seems that since the feature DocLibLanguageFiltering is missing on the Sharepoint 2010 release, while performing an upgrade of a site based on the document center site definition, you will always have this two errors:

[STSADM] [SPContentDatabaseSequence] [ERROR] [6/7/2010 1:01:32 AM]: Found a missing feature Id = [00bfea71-e717-4e80-aa17-d0c71b360102]
[STSADM] [SPContentDatabaseSequence] [ERROR] [6/7/2010 1:01:32 AM]: The feature with Id 00bfea71-e717-4e80-aa17-d0c71b360102 is referenced in the database [WSS_Content_WebApp-81], but is not installed on the current farm. The missing feature may cause upgrade to fail. Please install any solution which contains the feature and restart upgrade if necessary.

To fix this issue, take the feature on the MOSS 2007 farm, and install it on the SharePoint 2010 farm.

So, if you want a perfect upgrade without one single error, you will have to review the upgrade error log file, fix the error, then
remove the content db
Close its connection by detach re attach it in SQL Server
Restore again the source fram content db backup
Set up the Administrator permissions
Perform an upgrade

Untill you obtain that screen!

You have to change the permissions for the Site Collection administrator(s)

Then, check all the functionnalities of the upgraded portal are available.


 

 4.5 - Perform a Visual Upgrade

Now, if you really want to have a complete upgrade that allows you to take advantage of the new SharePoint 2010 user experiece, you have to perform a Visual Upgrade, so locate the menu

Choose a preview or a definitive visual  upgrade

Anyway, start enjoying the new UI of SharePoint 2010 by editing the home page and changing a label...

Well done !


 

  5 - Scenario 2: performing an "In-place upgrade"

5.1 - Building a SharePoint Farm running MOSS 2007 64-bit on Windows server 2008 R2 

will be published soon...

5.2 - Moving Customizations on SharePoint Farm running MOSS 2007 64-bit on Windows server 2008 R2 

will be published soon...

5.3 - Performing In Place Upgrade

will be published soon...

5.1 - Moving and Upgrading Content on SharePoint Farm running MOSS 2007 64-bit on Windows server 2008 R2 

will be published soon...

   6 - Aknowledgements and useful links

Thanks to Randy Williams for his post : Migrating to SharePoint 2010

First, the link on the topic in the SharePoint 2010 site ressource center:  Upgrade and Migration for SharePoint Server 2010

 A good article in Technet magazine:  Get Ready for SharePoint 2010

One of the post of Joel Oleson  What NOT to Migrate into SharePoint 2010 that has, by the way,  published a book on the topic.

Labels: , ,

10 Comments:

Anonymous SharePoint Tutorial said...

Your tutorial is awesome... it helped me a lot and after handling the orphaned site collection using stsadm.exe I was able to successfully attach the database to my web application. At the end I changed the site collection administrators and I had access to the migrated SharePoint site.

May 16, 2011 at 4:01 PM  
Blogger Greg Abbott said...

This comment has been removed by the author.

September 19, 2011 at 9:04 PM  
Blogger Greg Abbott said...

i am performing a Database Attach Upgrade. My current 2007 farm has a 32 bit database so an inplace upgrade is not possible. HOWEVER, i need to save my BDC configuration durring the upgrade. So im attempting to restore to a new 64bit 2007 farm, then do an inplace upgrade, then move the content databases to the new 2010 farm. I have not been able to restore my SSP to the new 2007 farm. Version differences according to the errors however the new Farm is more current (6535) than the SSP database (6524).

Do you think this is the best approach and do you have any advice regarding this issue?

Thanks!!
Greg

September 19, 2011 at 9:07 PM  
Blogger Marc Charmois said...

Hi Greg,

thank you for your comment.
I think your way of doing your migration is good. The most important is to have your content migrated properly and to have granted the best quality of service to your users.
Regarding that you have written, it seems to be the case so, cheers !

Regarding the BDC, I have unfortunately never had to migrate a BDC yet. So I have no solution right now regarding this issue.
On the other hand, I am not surprised about that issue, since the BDC has completely changed in the 2010 version, and is now called BCS. So I think it is normal it could not be migrated easily by the SharePoint tool.


However, just to be sure, have you passed SP2 and october 2009 CU before migrating ?
Did you use the preupgrade tool and did you have nessages in the report regarding the BDC ?

If my assumption is true, we have now to check if Microsoft has planned a specific tool for the BDC migration.
If not, I think it should not be so complicated for a developer to write a batch that will take the old content in the SharePoint 2007 BDC and transfer it in the new SharePoint 2010 BCS.

I will check about this and let you know...

Marc

September 19, 2011 at 10:35 PM  
Blogger Marc Charmois said...

Hi again Greg,

my assumption was right :

as you will read in one of the post I give you the link to , using New-SPProfileServiceApplication cmdlet only user profiles can be migrated and rest of the settings for Excel services, My Sites, Search and BDC should be manually applied to new environment.

I give you some references to deal with that.

http://blogs.msdn.com/b/alimaz/archive/2010/01/22/importing-moss-2007-bdc-application-definition-files-to-sharepoint-server-2010-post-db-attach-upgrade.aspx

http://blogs.architectingconnectedsystems.com/blogs/cjg/archive/2009/10/28/SharePoint-2010-BCS_2F00_BDC-Schema-changes.aspx

However, I din't read anything about migration problems for the content DB of a BDC ...
Maybe it is two separated problems. Anyway, you can now focus on the BDC migration tasks and start with the links I have provided or even contact the authors.

It is all I can do for the moment, hope that helps.

Marc

September 19, 2011 at 11:27 PM  
Blogger Unknown said...

Hi Marc,

Your tutorial is awesome. I am also working on WSS4.0 upgrade for my employer. The description from MS TECHNET about "Hybrid approach 2: In-place upgrade with detached databases" seems based on same hardware. Your version of Hybrid2 is the version I am looking for.

SPEC:
My environment has WSS3.0 sp2 x86 with backend SQL2005 x86. By preserve all my customization and setting from original farm, I would like to build a W2K8r2 with WSS3.0 x64 and apply an In-Place upgrade to WSS4 after.

Question:
For this step, should I using the WEBUI Backup tools to backup the entire farm and moved to the WSS3.0 x64 farm?

May I have a more detail description about this approach?

Much Appreciated.

Moses

October 6, 2011 at 12:09 AM  
Blogger Marc Charmois said...

Hi Moses,

sorry for the late answer.

Yes your approach seems to be a good one.
First migrating all the Farm in a 64 bit environment and then applying the in place upgrade method.

It will allow you to be sure to have saved all your old content preciously and will be the quicker way to upgrade.

However it might have drawbacks for this method :

If Backing up and restoring a site collection works very well, doing the same for an entire Farm does not work every time...

The other approach as the one I did in my post :
1 - Configuring first the Farm in the 2010 environment
2 - Backing up the databases in the 2007 environment and performing an upgrade after having restored them in the new one

is longer, required more operations but will grant you a perfect control on all the steps and most of all a perfect peace of mind...

But you could have a good peace of mind also with the approach you plan to use if everything is going well and if there is no error or warning in the upgrade logs...
And most of all no warnings from the SharePoint Health Analyzer.

And I wish it will be the case !

(Because as you know the Health Analyzer does not exists in 2007, so if you get warnings from it, it will be after having migrated and it will be harder to re-configure the Farm after that than before migration when mounting the Farm manually in the new environemnt...)

Hope that helps...

Marc

October 30, 2011 at 3:30 AM  
Blogger Basel said...

Is there any Advice om how to complete Search Migration in environment from MOSS 2007 To SP 2010 (database attached),
since after completing the portal migration, still search is not active , so is it possible to migrate search database from MOSS 2007 environment to SP 2010!!!

March 5, 2012 at 11:56 AM  
Blogger Basel said...

This comment has been removed by the author.

March 5, 2012 at 11:57 AM  
Blogger Timothy Groleau said...

I get this error whenever I try and run addcontentdb "A SharePoint database named XXXXXX already exists. You must supply another name for the new database."

Has anyone else had this issue?

December 13, 2012 at 7:57 PM  

Post a Comment

Subscribe to Post Comments [Atom]

Links to this post:

Create a Link

<< Home