Whilst making the march into SharePoint 2010, lets’ not forget those clients still using SharePoint 2003 and wanting to migrate into 2010. This article attempts to list some key things you need to be aware of in migrating from 2003 to 2010, and lists web parts in 2003 that you need to be aware of as part of the migration exercise.

I wrote this article based on real life procedures, trial and error, exasperation, tearing my hair out (of which I have little) and finally jumping up and down with joy when things fell into place.

Of course, I studied like crazy, and trawled the internt for tons of information. The following two links are the best I could find. Now, as you are probably aware if you’ve been using SharePoint  for some time, that SharePoint 2003 is no longer being directly supported by Microsoft. That said, they are providing information concerning migration from 2003 to 2010 at this link:

http://technet.microsoft.com/en-gb/library/ee947141.aspx

In addition to the above, there is a fantastic resource from Joel O sitting here:

http://blogs.msdn.com/b/joelo/archive/2010/01/31/sharepoint-2010-upgrade-key-resources.aspx

In summary, to make the move from 2003 direct to 2010 is pretty much not a great idea, the technical differences are vast, not just at the platform end, but also at the SQL end, so forget inplace upgrade. Options are:

Migrate 2003 to 2007, then from 2007 to 2010 (i.e. follow the guide above and the ones listed on Joels articles – recommended approach) OR

Use third party migration tools (though make sure you select the vendor with great care) – Avepoint, Quest, Metalogix, Tsunami apparently have options available.

Of course, whilst following the migration path, it’s also very important to note the differences in the Webparts from 2003 to 2007, and also what you should do to test Web Parts and possible ‘gotchas’. I did this as a blog sometime back but forgot to attach the table properly, so, let’s bring this a bit more up to date. Below is the 2003 to 2007 Web part comparison. Shortly, I’ll do one for 2007 to 2010.

Whilst on this topic, it’s very important to Test, Validate and Verify all components in 2007 when you’ve completed a migration from 2003

From a Technical Perspective.

Web Parts are standard ASP.NET custom controls, it’s important to identify the version where they were developed. Get the code and ensure they can migrate to Visual Studio 2008 / 2010 – reinstall these on a test platform to ensure they can migrate. Several glaring issues can arise due to the way code has been defined for 2003 which use now depreciated events in 2007 (meaning they will break).

2003 Web parts connect slightly differently to the new versioned web parts; Check all the connected events on the web parts and check the connection interface pairing iCellProvider,iCellConsumer, IRowProvider, IRowConsumer, IListProvider, IListConsumer, IFilterProvider and IFilterConsumer.

Web parts that have been defined as compatible and connected in 2003 must remain compatiible and connected in 2007/2010. An incompatibility between webparts will show the connections option (the hook between connected webparts) as greyed out – so check connections are still enabled looking at the ‘Ievents’ mentioned above.

Additionally, I know that this link is definitely still valid and I would apply most of the functional testing using these steps from Microsoft:

http://msdn.microsoft.com/en-us/library/dd583141(office.11).aspx

From a Non-Technical Perspective.

To those unsure about what ‘Functional Tests’ mean. Functional Tests capture user requirements in a very useful way. Traditional development captures requirements in terms of ‘use’ cases – meaning, the developer ‘guesses’ and ‘assumes’ the user will carry out certain functions. Hence, Functional Tests are written from the user perspective; they confirm the product does what the users are expecting it to. Therefore, it is important that all functional tests be written as a dialog. To do this you will require system analysis skills, not developer skills since these dialogs are written in a way the user will understand and with virtually no technical glossary terms!

So, functional tests are written from the user’s perspective and will focus on the area of SharePoint that users are interested in. You will need to develop a good functional testing framework, and use these functional tests to identify what the user really wants. In this way, the functional tester gains an automated tool and has a starting point for using the tool.

Going back to ensuring things work as they should post migration (of anything in SharePoint). You need to ensure you have a full verification and validation programme backed up by a solid configuration management process. This might sound like a lot of twaddle, but if, for example there was adequate documentation and version history concerning the web parts in 2003 concerning the install, development, configuration on 2003 then it is much easier to confirm what needs to be tested when it gets to 2007 land.

The SharePoint Verification and Validation blog I’ve been writing up goes into this from a basic perspective, but my forthcoming book (plug) covers this area in great detail.

Functional testing includes confirming the reaction to virtually every setting in the web part in 2003 and then comparing that with 2007, and getting sign off from the client.

Hope this helps anyone out there!