TOC

• Lessons Learned
• What We Did
  
• Resources

Hey, look! Its 2013, and we just recently moved up to SharePoint 2010…..heh…

Earlier last year, our intranet was finally been upgrade to SharePoint 2010, but not without a mix of major and minor hiccups. We came upon a few limitations and roadblocks that caused us to re-route our plans or create new ones.

Our main focus was to get 80% of the website ready for launch and wrap up the 20% as we go. We decided to do this primarily because of the features that SP 2010 provided. The new workflows, External Content Types, Records Centers, Search, and Keywords were what we were pining to get into our organization.

The design and organizing of our enterprise took longer than expected. We wanted to upgrade, relocate, as well as migrate multiple site and pages before we turned on to 2010. Our content and structure was all over the place when it comes to how it was organized. We needed to rangle that mess in.

Lessons Learned

top

Oh man! There were tons of technical and practical lessons learned for our journey with this upgrade. Our planned route for the upgrade was to do a Database Attached upgrade to eliminate the amount of down time. When you get to the point to decide on how to get your 2007 data into a 2010 realm, you have three choices (http://technet.microsoft.com/library/cc263447(office.14).aspx):

1. In-place upgrade
2. Database attach upgrade to a new farm
3. Hybrid approach (Read –only databases or Detach databases)

Simple “Database Attached” upgrade routes generally mean you have a blank SharePoint 2010 server that you just move the data (files, user profiles, web page, etc) over from the 2007 version. You do this by detaching your SQL database from SP 2007 and reattached it to the SP 2010  site.

Warning!Warning! Issues WILL arise from this route because there will be ONE page that will not want to play nice, or you’ll have that one user profile that will corrupt everyone else, or that one document library that does not keep its custom security settings. If you wanted a perfect migration to 2010, you should have kept the vanilla website, no branding, no users, or content, no nuthin. Just a pretty shell of a SP 2010 site. But this is the real world, and you have mountains of settings, content, and users.

• One of the main things that you will find out is that the styling may be one of the longest process of the upgrade. Of course, if you don’t have any custom styling, then you’re free. You’d be surprised to find out how many places you have to change that ONE font or background image that you missed the first time around.
• Empower users to help make the transition smoother. Train a few every-day users or recruit power-users to help you validate and verify that settings and content made the move.
• Offer SP 2010 training PRIOR to your upgrade. Don’t surprise your users with a new interface, layout, and settings structure. Keep them happy from the start.
• Create a “self-serve” user base to encourage self-training and collaboration  This fosters idea sharing and helps eliminates the “oh, i didn’t know that”. Help create a local SharePoint User Group in your organization.
•  Make backups of everything before you proceed. This also includes doing the Pre-check for the upgrade. You can find more Best Practices here: http://technet.microsoft.com/en-us/library/cc261992(v=office.14).aspx
• Work in parallel to your existing 2007 site. Don’t tear down your existing work until your 2010 site is up and at least 90% satisfied. Create your 2010 site, migrate your data over, freeze your existing site for a day or so to ensure complete data migration, then DNS switch your existing URL to the new site.
• Don’t get rid of your old stuff just yet. Keep it around for almost 8 months to a year. Sometime down the road you’re gonna get a complaint that your new sites settings don’t match the old or content is missing. Keep a copy. Save yourself the headache.

What We Did

Content Cleanup:

The first step in our migration was to have a handle on what we currently had (or attempt to). We grabbed our Server Admin group and asked them to pull a PowerShell script report on every single Content Type, Column Name, and Site/Sub-Site. Each with a mapping to it’s currently used location. It took us about 2 weeks, but we widdled down the obsolete and common Content Types and Column Names by consolidating what we needed.

Column Changeup:

The main issues that we had with our Content Types or Column Names were duplicates or renamed columns. The problem with renamed is columns is that the column reference is what it was originally named when it was created. This causes big headaches for developers when trying to references a column programically. For example, if you name a column “Juicy Fruit”, then 4 months later decide to rename it “Bubble Gum Flavor”, SharePoint still calls it “Juicy Fruit” in the back-end but displays it as “Bubble Gum Flavor” in the front end. Even worse, is the fact that it looks like “Juicy%5F%20%5fFruit” or something similar (SP uses Unicode to represent characters in some places). Please, please, please…when naming columns, name them without spaces FIRST. Then go back into the column details and add the space later. It saves a lot of headaches.

Server Backup and Database Attach:

Once we agreed upon what columns we were going to change, we kicked off a full server backup. After the backup, we did a database attach to an already blank SP 2010 site. We tweaked anything that we needed to and ran the PowerShell script on the new site and compared our planned changes.

Here are some links to help you with this method: http://sharepointgeorge.com/2009/upgrading-content-database-sharepoint-2010-database-attach-method/ or http://technet.microsoft.com/en-us/library/cc303436(v=office.14).aspx

Changing the layout:

Semipro Tip: Make a copy of the V4.master file and rename it to whatever you want. ONLY change the newly created master page to suit your layout. Don’t anger the Master Page gods.

You can then go ahead and move sections around that you’ll need. Keep an eye out for where you put your s4-workspace as this section houses your actual site content. Some sections you cannot access or change unless you navigate to the server and change files there.

Finally some style:

Then came the styling. Oh, god…the styling. The CSS class s4-workspace was my best friend within the first week of styling. That bastard would throw tantrums or ignore my CSS files or just go rogue. If you do plan to style your site, be aware that there are a lot of nested tables and fonts that will take you a while to un-layer. Take it one step at a time and use the Developer Toolbar in internet Explorer (hit F12 on the keyboard to pop this up).

Almost everything within SharePoint can be changed within the StyleSheet. Try changing it there first before you go changing system files.

top

Overall, the upgrade went pretty well considering the amount of data that we moved over and the styling that was done. Keep your power users in the loop to have a smooth upgrade, clean up some of your columns pre-migration, and keep in mind that the 2010 HTML layout has a good bit of nested tables. You’ll make it through to the other side.

Now i’m waiting to get my hand on SharePoint 2013…..

Resources

top

• Upgrade Planning: http://technet.microsoft.com/en-us/sharepoint/ee517214.aspx
• Upgrade Approaches: http://www.microsoft.com/en-us/download/details.aspx?id=6260
• Upgrade Best Practices: http://technet.microsoft.com/en-us/library/cc261992(v=office.14).aspx
• How to Database Attach: http://sharepointgeorge.com/2009/upgrading-content-database-sharepoint-2010-database-attach-method/ or http://technet.microsoft.com/en-us/library/cc303436(v=office.14).aspx
• How to In Place Upgrade: http://technet.microsoft.com/en-us/library/cc303423(v=office.14).aspx