Top 5 Issues When Migrating From Sharepoint 2007 To Sharepoint 2010

Upgrading Challenges from SharePoint 2007 to 2010

The upgrade from SharePoint 2007, built on Windows SharePoint Services (WSS) 3.0 and Microsoft Office SharePoint Server (MOSS) 2007, to SharePoint 2010 brings both opportunities and challenges. Organizations can take advantage of new features and capabilities, but must also contend with architecture changes, rebuilding customizations, and training end users.

Loss of Customizations

Because SharePoint 2010 has a new underlying architecture, custom solutions built for WSS 3.0 or MOSS 2007 may not work properly after an upgrade. Companies will likely need to rebuild workflows, custom Web Parts, custom fields, and other custom elements from scratch in the new environment.

Rebuilding custom solutions from scratch

In many cases, custom code will simply fail to run in SharePoint 2010 because of changes to the underlying object model. For example, developers may encounter errors related to deprecated APIs or changes to the naming conventions of certain classes and methods. Rather than troubleshooting each customization individually, it may be more practical to completely rebuild solutions using the SharePoint 2010 approach.

Assessing impact of upgrade on custom code

Prior to beginning an upgrade, administrators should conduct an inventory of all customizations developed externally, or by IT staff, for the SharePoint environment. Document details related to system integration touchpoints, APIs/objects referenced, and business logic dependencies. Identify customizations at high risk of breaking during upgrade based on factors like complexity, system integration tight coupling, and usage of deprecated elements.

Strategies for migrating customizations

Custom solutions with minimal dependency on changing architecture elements may be salvageable via minor tweaks. Solutions with deeper ties into impacted components will require rebuilding from the ground up. Consider staged migration “lift and shift” tactics, isolating risky custom code upgrades from baseline upgrade rollout. Conduct proof-of-concept testing with copies of production data to gauge effort level.

Changes in Architecture

SharePoint 2010 consolidates MOSS and WSS under a shared architecture and platform stack. This shift drives simplification in some areas of configuration and management, while also impacting stability for customized systems integrated with earlier architectural approaches tied to MOSS or WSS specifically.

Shift from MOSS and WSS to shared platform

In SharePoint 2007, MOSS and WSS were built on different software stacks — MOSS on ASP.NET 2.0 and WSS on ASP.NET 1.1. This drove complexity and management overhead when running both systems. SharePoint 2010 draws both products under the same .NET 3.5 and ASP.NET platform, but still provides multi-tier site collections via service applications for more sophisticated portal scenarios.

New service applications model

Previous WSS solutions may have interacted directly with SQL databases or file shares for services like profiles and search functionality. The service application architecture layers a structured set of isolated, shared services behind a common Service Application Proxy. This improves consistency but may require updated configuration for integrated systems interacting directly with those underlying data structures.

Example: Configuring service applications

Managed metadata, the lexicon of enterprise keywords/tags, was previously maintained at the content database layer. In SharePoint 2010, this becomes the Managed Metadata Service application. Custom solutions interacting directly with those databases will need to be updated to leverage the terminology store via the service application, which also provides management interfaces for organizing keywords hierarchically.

New Features to Learn

Acclimating end users to new capabilities in SharePoint 2010 requires planning, training, and support. Major functionality areas seeing a step change in improvement include social computing, advanced content management via managed metadata, enterprise searches, and upgraded interfaces.

Major new capabilities like managed metadata

SharePoint 2010 introduces substantial new features IT staff will need to learn at an expert level to unlock ROI and deliver end user enablement. This includes managed metadata for content classification, flexible multi-lingual publishing, FAST search integrations, and building data-connected dashboards via PerformancePoint Services.

Getting up to speed on social computing features

Capabilities for community interactions, microblogging, content tagging, user profiles, wikis, and discussion threads position SharePoint 2010 as a social computing hub for many organizations. This represents a major expansion in functionality requiring training even for experienced SharePoint administrators on the underlying components from both a technology and user enablement perspective.

Training end users on new interface

Even the approach to front-end interface layers sees dramatic change in SharePoint 2010. The traditional SharePoint asset layouts are augmented by newly flexible page rendering templates leveraging ASP.NET master pages. The ribbon UI also draws comparisons to familiar Office products. User education on these experience-layer upgrades is key to driving engagement and consistency.

Information Architecture Changes

Content modeling approaches undergo foundational changes in SharePoint 2010, with key data classification elements like site columns and content types shifting from local, site-collection-specific definitions to centralized, reusable elements. Similarly, the basis for organizing and tagging content categories moves from simple taxonomy to fully-managed ontology via managed metadata service applications.

Site columns and content types

Previously siloed site column and content type structures limited reuse of these information architecture assets across different sites and site collections. By centrally defining these tools in the managed metadata service, content architects can build maintainable, authoritative structures mapped to business functions rather than per-site owner discretion.

Transitioning to managed metadata model

Simple taxonomy-based keyword organization is replaced by flexible ontology support in SharePoint 2010, requiring upgraded approaches for transitioning legacy tagging metadata. The breadth and depth of hierarchical keyword collections defined as term sets for managed terms now provide precision tagging as well as multi-language support based on a given term’s language-specific aliases.

Mapping existing taxonomies to term sets

Managed terms can be organized into term sets structured as hierarchies, supporting more sophisticated content classification schemes. Data architects should analyze previous taxonomy approaches used across WSS sites and MOSS portals, identifying commonalities such as shared keyword groupings that can translate into organization-wide term sets. Terms themselves often map directly from simpler taxonomy labels in the prior environment.

Managing Multiple Versions

Transitioning fully from SharePoint 2007 to a 2010 footprint without maintaining some 2007 system access during a transition window poses business continuity challenges. Upgrade strategists should define policies for managing hybrid SharePoint platforms temporarily during upgrade rollouts, determining appropriate dev/test/production isolation tactics to support upgrade validation while avoiding version conflicts.

Strategies for staged upgrades

Due to sheer data scale as well as integration dependencies to legacy SharePoint 2007 systems, companies commonly implement phased upgrade schedules spanning 6-12 months or more. This requires interim system coexistence and synchronization tactics, like configuring explicit production 2007 to staging 2010 replication and verification mechanisms prior to decommissioning legacy portals.

Integrating different SharePoint versions

Custom crafted SharePoint workflows may need to span web front ends across both platforms when 2007 tools remain in production but 2010 systems are introduced for new development. Bidirectional workflow actions can be configured via web services, as well as read-only database syncs if isolation requirements permit cross-environment integration at the data tier.

Example: Setting up coexistence farms

Within the SharePoint farm server topology, deployment teams might configure “shadow” SharePoint 2010 farms which mirror the content databases of 2007 predecessors, allowing site collection comparison testing but isolation from production data at the index and configuration layers. Once verification completes, path mapping and DNS adjustments accelerate final cutover from the 2007 farm to upgraded 2010 farm.