Yikes! The time has finally come to migrate our stuff from SharePoint 2007 into the new SharePoint 2010.
Be afraid. Be very afraid.
I’ve talked about how the existing environment was a mess. Rather than upgrade the mess, our strategic decision was to use a third-party migration product to copy the relevant portions of existing environment into the new, better-organized one, putting things where they out to belong.
While our content database isn’t particularly large, this isn’t going to happen overnight, or even over a weekend. There is an awful lot of mess to clean up.
So we are going to do it a baby step at a time. But that means there are tactical decisions that need to be made to allow the users to get their work done in the meantime…
We determined that we wanted users to start on the new site, and then, if the content they needed was still on the old site, they would go there to find it. They are going to have to use the new site eventually, better to get them used to navigating to the content via the new site now so when it moves they won’t be looking in the wrong place. So the first problem to resolve was getting user buy-in for the new site, even though most of the content is still on the old site.
In our case, the carrot to motivate use is the much-desired new search functionality. Everyone hated SharePoint 2007’s search – there was no wildcard search, and with poor governance, relevant information was buried in the results. By crawling the content still stored on the old SharePoint site with the new SharePoint search, a “search first” approach to migration, the users will migrate even before the content does because users can get better search results even before the content is migrated.
The next issue was navigation. If some stuff is here, and some stuff is there, how are we going to direct our users where they need to go? We were lucky with this issue, though, as it simultaneously addressed one of the issues we had with the old site’s main page and navigation.
In addition to a load of links to the top two tiers of sites on the left side of the page and a long list of links in a web part on the right, our old home page had flyout menus with sub-levels and sub-sub levels and… well, you get the picture. There were nearly 200 links on the front page.
We tackled this in several ways. First, we had individual meetings with a number of representative users to determine which links were most commonly used by everyone. Then we had them sort the important links into related groups, or “buckets”, and then asked them to name those buckets. When all was said and done, we had 40 links divided into five categories. The top five overall most important links were added on the left side.
We also created three other links for that section – a link back to the old site (which will be removed when the migration is complete), a feedback form for users to tell us what isn’t working (and what is working) for them on the new site, and a Site Directory.
The site directory is a web part page with two views of a list – grouped “By Department” (with the groups collapsed), and an “Alphabetical” listing of all of the sites. The list contains a friendly name and a URL for each site, as well as the name of the department that the site falls under.
If you remember from my governance post, one of our struggles was with the number of sites that had been created – there were more sites than employees! So how to easily create a list with all of the sites?
http://site/_vti_bin/Enum.aspx displays a list of all of the sites formatted as XML. I saved the XML file, then opened it in Excel. The Excel file has seven columns, but there are only two columns I was interested in – URL2 and the title, columns C and D. To create the hyperlink field with a friendly name, I created the following formula:
I added a column with the Department Name information, and quickly copied-and-pasted my way through the list with the eight departments (pretty easy, since the old site was set up hierarchically by department).
There were two ways to import the information. One was to import the spreadsheet (after deleting the extraneous columns). The other was to manually create the list, with columns Title, Site and Department. Title and Department are Single line of text columns, Site is a Hyperlink column. Once the list is created, open the list in Datasheet view, copy the three columns from Excel and paste into the datasheet. I chose Door #2 because I am a bit of a control freak and wanted to make sure the columns had been set up correctly the first time.
The list will be manually updated to point to the new site location on the new SharePoint once the site has been migrated.
So now we have an easy way to get to the most important stuff, and a way to get to a list of everything else with one click.
Gee, that should cover just about everything, right? If you think that, you are forgetting the bane of every IT plan… users.
Don’t get me wrong. Users are why the system exists, if you don’t mind me quoting TRON. But users do things for their own convenience that will cause them endless trouble if you don’t take them into account. And when users have trouble, they complain, and fail to appreciate the hard work you have put in to make their lives easier.
Take, for instance, bookmarks (or favorites, or shortcuts, or saved links, etc). Users want to get to the stuff they use the fastest and easiest way possible, so often (especially when your navigation is a mess) they save a link to their stuff as a bookmark, or a favorite, or a shortcut, or whatever. What do you think will happen when you have moved their stuff? Instead of getting their stuff, they will get an error message. “Where is my stuff?!?! I hate I.T.! I hate SharePoint!”
Now, we can’t realistically build a custom redirect for every item and page in the old site, especially when so much of it is no longer relevant. Plus, if we do that, they won’t update their bookmark, and will really scream when the old system is finally taken down for good. Somewhere between a 404 File Not Found and a custom redirect is a simple way to ease users to their content and to motivate them to update their saved links.
Enter the Custom 404 message.
Pretty simple in IIS, but SharePoint throws in a wrinkle or two. Fortunately, others have been down this path before me, so all I had to do was create the page (which looks a lot like our new SharePoint site, and includes links to the new site and a message to update their bookmarks!) and follow these instructions.
And, no, we’re still not done. So many details to attend to! There is still displaying the news from the new site on the front page of the old site, training users, oh and actually migrating all of the stuff! With over 1200 words already, it sounds like an article for next week! Stay tuned!