If your looking at the public beta of SharePoint 2010 and thinking, “We are going to need to upgrade, but where do I start?” then hopefully this basic guide should help you on how to plan and what action to take in preparation for an upgrade.
Upgrade vs. Migration
In my view there are two significantly different approaches to an upgrade. One would be a traditional upgrade where you are upgrading your existing infrastructure and then upgrading your binaries and content. The other would be creating a new infrastructure entirely and then migrating all your content from one to the other (upgrading it in the process.) The benefit to this approach being that you are not taking any excess baggage with you (see below.) Both approaches have significant advantages and disadvantages and will probably come down to issues of budget or politics or both any way. I am going to look at preparing your environment for a traditional upgrade.
Planning, planning, planning and more. you guessed it!
- Document your environment thoroughly. You cannot upgrade effectively if you don’t know what you have to begin with. If you already have documentation then make sure it is up to date.
- Initiate some thorough performance analysis on you hardware. If it’s not performing great then this is the time to be putting in budget requests for new kit and planning your infrastructure upgrades. Management like figures so get some raw stats in place to back up your requests.
- Customisations – ensure they are documented thoroughly (as above) check your infrastructure for rogue customisations that you might not be aware of. Look in the GAC, 12 Hive, Add/Remove Programs, Solutions store, and anywhere else for undocumented customisations. If you use 3rd party tools/add-ons then contact your ISV. What are their plans for 2010? What is their roadmap for these? Does it fit in with your plans?
- Put together an Upgrade Strategy. It will make more sense if you get it all down on paper and it will allow you to see any gaps or issues. Show it to other stakeholders and get some feedback you are guaranteed to have missed something.
- There are lots of stakeholders and interested parties who are going to need to know what is happening when. Create a communications plan. Who will be told what and when.
- An upgrade to 2010 is going to have an impact on end users (obviously), so create a training plan. Who will be trained when and to what level, and who will deliver that training. Costs should be built into budget plans for this year.
- Consider some of the other issues at this time:
- Are you going to install a sand box for the developers to play with?
- Are you going to run a pilot scheme?
- Are you going to run concurrent 2007/2010 environments?
Preparing your environment
- Are your MOSS 2007 (or WSS) environments up to at least SP2? I would say get them to at least the latest CU (December CU at the moment.)
- Run the upgrade check tool that has been provided in SP2 (that is why it is there). The command is stsadm -o preupgradecheck. This will generate a HTML report which will details any issues that should be fixed prior to an upgrade.
- Deal with the issues raised above. The tool has been written for a reason, if you don’t deal with all the issues raised by this tool in some way then you are setting yourself up for a fall.
- Offload all your excess baggage. And by this I mean go through your environments and remove any templates, features and site definitions which are not being used. You can always restore them to the new farm later if need be. Also check your server event logs and ULS logs. Ensure that all recurring issues are fixed before you upgrade. Additionally archive any unused sites (do not delete them though, just in case!)
Upgrading the infrastructure
- All your servers are going to need to be running on 64 bit OS, so the majority of older farms are going to need full OS installations on all the servers.
- Look back at the performance analysis you did in the planning phase, can you see any areas that require beefing up. Need more RAM in your indexing server? Might it be best to perform your indexing on a physical box where before it coped on a VM?
- How are you going to upgrade all this hardware? The easiest way is to add a new server in to your farm and then ‘swing’ each of the old servers out one at a time to be blown away and rebuilt as the specifications demand. The new server is there to handle some of the excess load from the different servers as your remove them.
- Test every step of your upgrade path in a non-production environment first.
- If you have the resources then build an evaluation farm as an exact replica of your live environment. You can then use this to test out your upgrade strategy to ensure all works as planned.
- Once you have performed an evaluation upgrade then review it and ensure that everything went to plan. Revise your plans of the back of this evaluation.
What about the dev team?
- Don’t forget to plan an upgrade of your dev and testing platforms.
- Does you dev team now need 64 bit desktops or are they going to develop on VM?
- Will you upgrade the dev team to Visual Studio 2010? The tooling is significantly improved, so I would say that should be a big ‘yes’.
Other issues to consider
- IE6 support has been dropped in SP2010, this will have a dramatic effect on your content authors /contributors if they are still running on IE6. Upgrade!
- This would be a great time to revisit your Information Architecture using some of the new support for managed meta data and importing taxonomies. Separate project, but seriously now is the time!
Essentially the upgrade path comes down to three things.
- Plan everything
- Prepare for anything
- Test everything
I hope that this little whistle-stop tour of the upgrade path has helped. If nothing else it means that I have got all this stuff down to refer to myself.