Shortly after the 2010 Australian SharePoint Conference back in July (2010), I was approached by Step Two Designs (http://www.steptwo.com.au/), a vendor-neutral Web design agency based here in Sydney Australia, to deliver a presentation (Webinar) on SharePoint 2010 to their customer base. They wanted more a business-level, 100-200 level, presentation which would be targeted to those customers either planning on upgrading from SharePoint 2007 to SharePoint 2010, or migrating off of another CMS onto SharePoint 2010.
As per most of my other presentations, there was a lot of interest with the majority of the audience planning on moving to SharePoint 2010 within the next 12 - 18 months. I uploaded the presentation to Slideshare and you can find it here: - http://www.slideshare.net/kathyhughes/share-point2010-ilgforumhughesk.
Questions received throughout the Webinar included topics relating to compatibility between SharePoint versions, compatibility between clients and SharePoint 2010 versions and a bunch of architectural questions. The following 3 questions were ones I followed up on post the webinar so I thought I'd post them here since I'm sure others have asked or will ask similar questions.
Q: What about Office 2003 and SharePoint 2010 compatibility. We already have a number of WSS (3.0) team sites and are in the process of determing when to upgrade to SharePoint 2010. We want to do this before we upgrade everyone to Office 2010. As I mentioned, there are a number of browser-based benefits to moving to 2010, however there may be some issues with client integration with Office 2003 depending on your requirements and I would suggest that you download a trial version of SharePoint 2010 and thoroughly test client integration - things like document templates and versioning between the Office 2003 clients and SharePoint 2010 document libraries. It will be a matter of testing and then weighing up the pros and cons between any document management degradation experienced with Office 2003 and other benefits derived by moving to 2010 now - like the richness of in-browser editing and other functional areas mentioned during today's presentation. For instance, if you see InfoPath list forms as being beneficial (*list forms in SharePoint Server 2010 Enterprise version may be replaced) then only the people who will design the Infopath list forms will need to have the InfoPath 2010 Designer client installed - others will simply access the published forms via the browser when accessing SharePoint sites and completing online forms.
Q (related still to Office client version) What if we migrated to SharePoint 2007 now and then SharePoint 2010 later - will that help with our current level of Office client? IF they did choose to go with SharePoint 2007 now for the sake of Office client integration (and, mind you, some of the office integration issues experienced in 2010 are also experienced in 2007 anyway), then they will have the option to upgrade later; however, they should then consider features used in 2007 which are redundant in 2010 - like site templates (STP files) and 2007 themes - so they would also need to factor in any design and customization work they did in 2007 if they went down that path. Here is a link which further explains some of the issues between Office 2003 and SharePoint 2007/2010: http://www.sharepointusecases.com/index.php/2008/08/office-2003-and-sharepoint-2007-comparision/ - see especially some comments.
Also, you should download and review the Office Compatibility Pack, which can be found here: http://www.microsoft.com/downloads/en/details.aspx?FamilyId=941B3470-3AE9-4AEE-8F43-C6BB74CD1466&displaylang=en.
Q: What about Secure ID? How does that impact end users - do end users need to 'do anything'?
As I mentioned, this has no bearing on the 'end user' - or it is 'seamless' to the end user - rather it's an area which the SharePoint architect and/or administrator needs to address upfront as part of the overall SharePoint 2010 security design, especially where the plan includes business intelligence functionality and connections to backend / external data sources. Basically, the Secure ID store is going to handle how data is authenticated to and passaged between the SharePoint server, the SQL server (back end data connections) and the client (user requesting the data in a SharePoint site) where data connections are configured for back end data sources such as those which reside in a SQL database aside from SharePoint content; a prime example in SharePoint 2010 is where an external content type/external list is configured in SharePoint Designer 2010 and a Secure ID Store (token) is required in order to manage the access to a SQL or Web services connection. There are numerous articles available on the Web about configuring the Secure ID store - here's one: http://technet.microsoft.com/en-us/library/ee806889.aspx.
Q: What about exporting Sharepon
Regarding the question from yesterday's Webinar about exporting SharePoint 2010 taxonomies, I've come across a couple of online references which may help. It does appear that the solution will involve using code, although there is a project currently underway, and listed on CodePlex, which may eventually lead to a UI solution: