since SharePoint 2010 is Beta and RTM i did some test regarding upgrade SharePoint 2007 to SharePoint 2010. Based on the last upgrade experience from SharePoint 2003 to SharePoint 2007 i will create a series up upgrade post in the next time.
With this post i will start with an Overview of SharePoint Upgrade. In general we have two upgrade options:
- Inplace upgrade
- ContentDB-Attach Upgrade
Both upgrade options have pro & cons and in a whole migration strategy for enterprise environments it’s possible to mix them to get the fast possible solution to bring your farm up and running in SharePoint 2010.
In SharePoint 2010 Upgrade you can mix both upgrade method and this is call Hybrid Upgrade. This upgrade method combines Inplace & ContentDb-Attach Upgrade and combine both advantages and disadvantages. So it can be dangerous to choose Hybrid upgrade.
All Information i present in this post I’ve from my own tests, my experience from last Upgrade time (2003 –> 2007) in SharePoint support and from TechNet SharePoint 2010 Upgrade and Migration Center.
pro con – upgrade process runs in one single action, it’s easy
- All data will be migrated like: FarmConfiguration, Search Config, Search Index, Usage Analysis Data, User Profiles and User Content.
– customization can be a problem,
– if it’s fails you need a complete farm restore plan including: Windows Server Backup, SQL Backup,
– during the whole upgrade the farm is offline (including POST Upgrade steps)
– MOSS2007 must be on 64 Bit before Inplace is possible
– MOSS2007 search index is migrate in a quality of 2007, to get all search quality of 2010, we need a FULL Crawl over all content
pro con – the content is still online and accessible during the upgrade (read-only)
– you have much more options to handle your customization
– more control for long time migrations
– granular testing
– granular upgrade of content possible
– create a new Farm
– more complex (manually steps required), e.g. AAM,
– not all data will be migrated (like: SharePoint Farm Configuration, Search Configuration, Search Index)
– additional hardware required
– search index is not migrated and the new 2010 farm need to crawl the content
One of the main questions you need to answer by your self is:
1. Is this Upgrade also a good chance for you to remove old relics from your FARM?
2. Do you may want to change your Topology, Hardware, AD, Information Design,…
If YES (you want to change e,g. hardware), then it could make sense we build a new FARM and migrate only content and UserProfiles. The SharePoint Farm Configuration will be done manually, based to your new needs.
If you do not want to change something than an Inplace upgrade is still possible for you. But please remember the installation requirement of SharePoint 2010 and the support boundaries like Browser Support (no IE6).
Topic 1 – Hardware:
SharePoint 2010 requires completely x64 Bit hardware on SQL Server AND on SharePoint Server.
If your 2007 farm run on a complete 32 bit SharePoint 2007 environment an Inplace Upgrade requires first:
1. Move all Databases from SQL x32 bit to SQL x64 bit – Technet (Migration Step 1)
2. Move SharePoint Servers on x64 Bit – (Migration Step 2)
(by adding x64 Bit server into the Farm, move all roles to these new server, remove x32 bit Servers from Farm)
3. Start the real Inplace upgrade (Migration Step 3)
In this case you have 3 Sub-Migrations to do in the decision of doing an Inplace upgrade. Each Step include a farm downtime and for the move to x64 bit we need to check our customization as well. That’s the reason why i would suggest at this position a Contentdb Attach upgrade to migrate all Contentdbs and UserProfies only.
The advantage would be:
1. The farm is still online during the upgrade
2. we will over jump moss2007 x64 bit a have no need to implement & test our customization, reduced effort
3. in case of problems we can continue with our migration and one addition task force team can work in parallel on the problem (like contentdb structure include orphans)
Topic 2 – Important rules: How to process a upgrade!
My experience says, 70 – 80 % of the time you need is for test and validate data before touching the production environment. So we can define some upgrade rules:
Rule 1: check the total disaster recovery plan and build a new upgrade test farm based on production environment backups
Rule 2: check stsadm –o preupgradechecker and solve any warning and errors/orphans missing customizations before an upgrade. (check the preupgradechecker logfile too, to check the quality of the report)
Rule 3: check all SPWeb-Objects on languages (LCID) and Templates with ststadm –o enumallwebs. This will also check allot of content rules. The output is also interesting for you, that an content validator tool is required: e.g. check for customSiteDefinition, check all content on used languages, collect all .stp files on Site Template gallery.
Rule 4: (is only my personal suggestion): check all content on corruptions/orphans in deep. E.g. with using stsadm –o export. This operation should run successful. Why is this important? The Export focus not only on SPWeb Level it get in touch with all single items like: SPList, SPListItem, SPContentType, SPListView, …
Because the export action is really hard for large site collection or SPWeb Objects it required and additional tool to export the content as validation. On the blog of my colleague Stefan Goßner we have enough content available to write such a tool.
Rule 5: check all customization if this is running in SharePoint 2010 as expected in Old UI & new UI mode, read this from Joel, Sean and Alex about upgrading CustomSiteDefinitions and the visual upgade function – Link
Now we can TRY the first upgrade via a upgrade test farm: e.g by using contentdb attach
run: SP2010 ManagementShell: TEST-SPContentdatabase
or with: stsadm –o addcontentdb
Rule 6: Start upgrade Post-Data-Validation:
6.1: check the upgrade log file for error & exception:
..\Program Files\Common Files\Microsoft Shared\web server extensions\12\logs\upgrade_<date>.log
..\Program Files\Common Files\Microsoft Shared\web server extensions\12\logs\upgrade_error_<date>.log
6.2: validate all content by export the data again
6.3: browse all files which include UI customization and validate the custom look & feel
Rule 7: make your upgraded farm/content available for users after POST-Data-Validation is completed, (maybe modify AAM settings)
And now here is a Screenshot guide for upgrading via Inplace upgrade?
For this test i use MOSS2007 SP2 and SP2010 public beta. (NOTE: upgrade from SP2010 Beta to SP2010 RTM is not supported!!!)
Insert disk of SharePoint 2010 and install prerequisites, (Note: Install SP2010 without Internet Access)
run setup.exe, or Click on Install SharePoint 2010
Upgrade mode starts: the installation of MOSS2007 is detected.
SharePoint 2010 binaries will be installed
At the end of installing SharePoint 2010, Psconfig will be started to proceed the upgrade.
Configuration Wizard starts (psconfig)
Add the new FARM PASSPHRASE
Set Visual Upgrade configuration
Press NEXT and the UPGRADE will start – This is your "Point of no return" and your Farm ConfigDb and central admin will be upgraded to 2010 schema.
Beprepared that the Upgrade is consuming high CPU & memory on SQL Server and SharePoint Server
OKAY now PSconfig is finished but the upgrade is still running, because our Farm ConfigDb & central admin is now on 2010 level but not our content. The next upgrade step is done by OWSTIMER.EXE. A SharePoint TimerJob will upgrade your content.
Notice: in an inplace upgrade the upgrade timerjob will upgrade each database one by one. That means the upgrading of multiple content databases is only possible with contentdb attach upgrade. In case you have many contentdbs and a large content size it’s a good idea to choose contentdb attach upgrade.
- OKAY timer job for the upgrade was created and content will be upgraded now
- Upgrade end and i hope successful
- Now Validate the Upgrade Operations:
Analyze the result: 14-Hive / LOGS/ upgrade logfiles
First Check the upgrade-error.log.
After the upgrade lets Check the whole site structure:
All available webapplication
The SSP-db is still there: but can be deleted as POST upgrade action.
Check all databases in the farm:
What is migrated from content?
Publishing site collection:
After completing the whole upgrade validation check you can start the VISUAL Upgrade:
It’s set on SPWeb Level, which include all pages in a publishing site.
Open site settings – check under site collection administration – visual upgrade function
Here you can define two thing: Hide the Visual Upgrade Menu for Users on the whole site collection and Force the Visual Upgrade for all SPWeb-Object on the whole site collection. Please use the Force Button only after testing each SPWeb in a Preview Visual Upgrade Mode. (otherwise your custom can create a crazy page rendering)
I hope this helps.