SharePoint 2013 Migration Readiness Decision Points around Migrating to SharePoint 2013 MARK ECKERT
Contents Purpose... 1 SharePoint 2013 Implementation Options... 1 On-premise installation... 1 Cloud... 2 Hybrid... 2 Summary of Implementation Options... 3 SharePoint 2013 Planning and readiness... 4 Performing and inventory and audit... 4 Information Architecture... 5 Authentication, User security and Permissions... 6 Features... 7 Customizations... 8 Summary... 9
Purpose The purpose of this document is to evaluate what implementation options there are for SharePoint Server 2013 while describing the some of the decision points that should be raised during the migration planning and readiness phase of a SharePoint Server 2013 upgrade or migration project. The benefit of understanding these decision points upfront will not only guide an enterprise in the decision making around carefully choosing their implementation, it will also provide a preface to all the planning activities necessary for a successful upgrade. SharePoint 2013 Implementation Options The past few years there is a lot of buzz about the cloud. A lot of enterprises are considering the cloud even more so now as the benefits have evolved or improved greatly since SharePoint Server 2010. A few of these benefits are: The cloud leverages SaaS, IaaS and PaaS models There is a business case or interest to move from capital expenses to operational expenses Increased alignment of enterprise resources to more strategic initiatives relative to the business Great for small to mid-sized companies, were data sensitivity is minimal Given these benefits, there are a variety of implementation options available. Regardless if it is a business or IT driven desire to migrate to SharePoint 2013, careful selection of the implementation path should be performed. SharePoint 2013 can be implemented on on-premise or in the cloud (both public and private.) The following sections describe these implementation options and some questions to consider when evaluating them. On-premise installation On-premise installations are self-descriptive, SharePoint Server would be installed within the enterprises existing network and infrastructure. At this time, on-premise installations offer the fullest feature set of SharePoint Server 2013 (when compared to SharePoint Online), scalability and control. When upgrading or migrating from SharePoint Server 2010, an enterprise is required to implement a new SharePoint 2013 farm to migrate to, as in-place upgrade is no longer an option with SharePoint Server 2013. Then after the upgrade is completed, sunset or retire the SharePoint 2010 environment. This implies that there will be cost involved with purchasing hardware and licensing to support the new SharePoint 2013 environment. On the flipside, migrating to SharePoint Online will require more planning, as the enterprise will be moving toward a different service model and processes, whereas the on-premise installation relied on existing infrastructure and processes that were already defined in the enterprise. For small enterprises this may be insignificant as they may not have established service models and processes. For large enterprises, the effort and timeline will be more significant as it will require migrating not only to a new cloud infrastructure, but also migrating and in some cases defining or enhancing the service models and processes to meet their business needs. 1 P a g e
Cloud Cloud is a broad term, there is some distinction between cloud offerings. These can be categorized as virtual private cloud, shared service provider, and the Microsoft offering Office 365 / SharePoint Online. Virtual private cloud (VPC) is used to describe a cloud infrastructure where network and server resources are logically separated, made private from other tenants within the cloud infrastructure. VPC solutions would be used to house SharePoint, SQL Server, and Active Directory. When considering movement to the cloud, some enterprises also look to move their Exchange, Lync and SharePoint platforms to the cloud as they are closely integrated platforms. When moving to a VPC solution, close attention to service provider models and processes is necessary in planning. Questions like what are the SLAs or OLAs are typical. For enterprises that have an Infrastructure team that managed the previous SharePoint infrastructure, this poses the greatest change. As they will have to work within the new service provider model, as well as any tools the VPC provider uses. It is important to engage the Infrastructure team early in this aspect, as they will be able to raise problem areas with the service provider model that need enhancement or clarification, as well as simply raise any items that impact the support or operation of the system before any contracts are signed with VPC provider. Shared service providers provide an enterprise with SharePoint web applications or in some cases site collections. The enterprise is just one of many tenants within the shared SharePoint farm. This scenario of cloud is mainly suited for smaller companies that do not rely on many customizations or features. This offering is also well suited for enterprises where data sensitivity is low, or there is no regulatory or compliance related content. Typically, access is limited to what options are available through provider s administrator control panel, and server level access is usually not possible. The cost involved with this offering is significantly less than VPC, and the migration and planning efforts are usually less as well. Office 365 / SharePoint Online is Microsoft s public clouding offering for SharePoint, it is tenant-based similar to the shared service provider offering. As versions progress, the feature set of what is offered via SharePoint Online is getting closer to the full-feature set offered in the on-premise version of SharePoint Server 2013. For large enterprises with customizations, it is beneficial to do a detailed evaluation of SharePoint Online to identify if the limitations in feature sets present difficulty when migrating customized applications. For some cases, it is possible to retool or replace customizations with OOTB features that were not present in SharePoint 2010. In other cases, it is possible that enterprises can purchase apps from the Office 365 app store by third parties. However without detailed evaluation, it will be difficult to assess whether or not a suitable third party exists to replace the customization. For all three cloud options, licensing needs to be carefully evaluated in terms of cost and manageability. License structures differ across all offerings and providers, and the management tools to manage licenses differ. Hybrid Hybrid cloud environments are increasing in popularity for some companies. Hybrid offers the benefit of maintaining an enterprises on-premise resources and online (cloud) resources. Online resources can be 2 P a g e
other instances of SharePoint or could be other cloud-based services that are exposed to SharePoint. Some hybrid environments are complex with multiple different online resources while still retaining a common internal IT infrastructure. New functionality included in SharePoint Server 2013 allows some services to span hybrid environments, allowing integration of search and Business Connectivity Services (BCS) to bridge the gap between on-premise and online (cloud) environments. This configuration would be helpful for enterprises where regional offices operate independently from their main corporate office. Another case would be regulatory, where it is of interest to keep certain content within the confines of on-premises, while having less proprietary content or solutions being deployed to the cloud. Summary of Implementation Options Having described some of the implementation options above, we can now see what some of the trends have been. Base on Forrester Research across all industries in Figure 1, there is still a large presence of on-premise installations. Since this is not industry specific, there are various reasons to attribute larger percentage (e.g. compliance reasons, custom applications, loss of control or change of service model, etc.) Generally speaking, nearly 40% using some flavor of cloud or hybrid. Figure 1 SharePoint across Industries When compared to Life Sciences in Figure 2, roughly around 40% are also using some flavor of cloud or hybrid. So the trend is in alignment with broader industry trends. The NextDocs results goes one step further to say that there is a significant number of organizations that are considering cloud options moving forward. 3 P a g e
Figure 2 SharePoint in Life Sciences So, to conclude when evaluating options with SharePoint in the cloud versus on-premises, enterprises in Life Sciences should consider: Cost and licensing considerations Migration efforts around complexity of existing architecture and customizations Service Provider Model, SLA and OLA considerations Increased effort around compliance, regulatory Limitation in feature sets (Office 365 / SharePoint Online) when compared to on-premise (full) version, as well as third party support SharePoint 2013 Planning and readiness Having reviewed what implementation options are available, we can now discuss how an enterprise would prepare for a migration or upgrade to SharePoint Server 2013 with these implementation options in mind. Most migration planning starts with a planning and readiness phase, where an inventory and audit is performed. Performing and inventory and audit An inventory of various areas should be collected and audited to validate if they should be migrated into the new SharePoint 2013 environment. Simple audit processes should be carried out in the follow areas: Information Architecture Authentication, Users and Permissions Features Customizations The overall intent of the auditing of SharePoint prior to migration is to only move content that is relevant and necessary, identify what remediation needs exist, and identify if any general changes are needed for improvement. While performing each of the inventory and audits in the areas above, confirmation should be made to ensure that the existing (source) farm configurations fall within the limits defined for the target farm platform. For example, on-premises have boundaries, limits and thresholds that are defined 4 P a g e
in Software boundaries and limits for SharePoint 2013. However, Office 365 / SharePoint Online has its own boundaries, limits and thresholds some are dependent upon the subscribing plan, details are found in SharePoint Online: software boundaries and limits. These limitations generally speaking cover most cases with SharePoint 2013. Information Architecture As part of the readiness and planning, the existing SharePoint farm Information Architecture should be assessed. Having a sound IA, will optimize the migration process. Assessing the IA will identify what components are working well and which ones are not, leading way to identifying if a redesign is necessary. In addition to optimizing the migration effort, redesigning an IA that needs improvement will go miles toward improving business value and improved user adoption. Navigation, site structure design and search are common areas in IA that often need improvement. Reevaluating IA as part of a SharePoint 2013 migration is an ideal time to make improvements. It should be noted in some cases, poorly executed or defined IAs, sometimes stem from lack of governance and cost constraints placed on web applications and site collections. This would be a good moment to assess if your governance plan is working as desired. Also, if you have any cost constraints that enforce bad IA behaviors leading to issues like site sprawl, so you can ensure bad practices are not carried over to the new environment or does not exist in the service provider model you are moving toward. The following checklist is a few items that should be performed in an IA assessment. A typical IA assessments would involve roles such as Enterprise Information Architect, SharePoint Architect, Business Users (site owners) and possibly compliance managers if regulatory or compliance is involved. It is important to note for each of these assessment points, consideration may be different if you are migrating to on-premise versus a cloud solution. This assessment is given as a sample of the types of questions that should be answered. 1. Evaluate sites and site collections to determine if the existing site structure is adequate moving forward. a. A site map should be created of the existing IA if one does not exist. b. Should consider best use of sites, site collections, managed paths and web applications For example: i. Identify cases where additional web applications should be implemented (e.g. to isolate true custom sites from OOTB team sites, or to isolate remote partner collaboration), ii. Other cases where site collections should be used instead of sites and vice-versa, etc.) iii. Consider content database sizing in the evaluation, and max file size of items. iv. Consider security and permissions, and v. Any gaps that exist in the current IA. c. Identify list and site templates. Identify what can be consolidated, refined or eliminated d. Assess if sites and site collections should be migrated, not migrated or archived. i. If Archived, is there is an Archive strategy defined? If not, define one. 5 P a g e
2. Evaluate navigation from a findability and usability perspective. a. OOTB navigation for Quick Launch, Global Navigation for both structural and managed (term-set driven) navigation. b. Third party navigation and custom navigation c. Evaluate default views for custom list templates and default libraries/lists 3. Evaluate Content, Metadata and Taxonomy a. Consider gaps that may exist with content types and site columns regarding team sites and custom sites. Evaluate usages of content type syndication (hub.) Identify cases where lists need to be merged or split, or if items need restructuring b. Evaluate current usages of site columns, content types, folders and document sets c. Consider how managed metadata service (term sets) can be leveraged more d. Is there a need to reduce large lists, or reduce the number of columns in list i. Determine if content in the Workflow History lists for example are needed in the new environment e. Should some libraries have document versions that are unnecessary removed f. Removal of orphaned sites 4. Evaluate Search from a both a team site and custom site perspective a. Evaluate current usages of content sources, scopes, search centers, etc b. Evaluate usages of keywords, thesauri, rules, etc. After performing an assessment of the four items above, a determination can be made if some areas of the IA require redesign or if all areas require some redesign in an effort to improve business value and user adoption. If redesign is required, that will require resourcing, planning and alignment around the overall migration plan and schedule. Authentication, User security and Permissions Along with IA assessment, various elements of security and permissions should be assessed. The same point being that only the relevant security and permissions should be migrated, and any opportunity for improvement is identified to either incorporate with the migration plan or planning for a post-migration implementation. Typical security and permissions assessments would involve both Business Owners and Technical Staff, these topics are typically raised through governance committee participation in the migration project. If governance is lacking, these topics will be driven by need, or alternately could be included as a subset of the IA assessment. Some topics are more business focused, while others are more technical. In both cases, it requires partnership with business and IT especially in larger enterprises. Authentication types need to be assessed. For example, if Windows Active Directory accounts are being used for remote partner authentication, enterprises may want to consider if process is working well, or if they want to move to another authentication type like ADFS, Forms-based authentication (FBA), etc. for improved business agility. In general, user security should be assessed. Site owners should remove any unwanted or unnecessary user accounts from site security as to not migrate them into the new environment. Use the migration as an opportunity for housekeeping of user accounts. 6 P a g e
Permissions should be evaluated. Is there a need for any special permission levels? For example, if you have a site request process, however site owners are not following the process because they can create sub-sites themselves. A starting pointing would be to reduce the permissions levels of site owners, and improve the process through governance therefore minimizing site sprawl. Does your organization have the proper tool set and processes to manage user security? Once again, use the migration as means to not migrate bad practices or processes that are not working as effectively as they could be. o If you are moving to Office 365 or Hybrid model, does your toolset and process for security still apply? Do you need to look for different tools? Implementation options, cloud versus on-premise, factors in to the outcome of this assessment too. For example with SharePoint Online you will be limited with authentication types available when compared to on-premise SharePoint Server 2013. Likewise, with tool sets for user account management, if you have a service provider, you may be limited to what tools they have available or may have to purchase your own if those tools if the tools provided cannot be configured to meet your business need or requirement. Features Features should be reviewed, as some features are deprecated in 2013. Feature assessment also is used to minimize what features are truly necessary as to avoid activating features that are not being used. Skilled site owners and site collection admins should deactivate any unneeded features as a general housekeeping task as part of pre-migration. These discontinued features are noted in Technet Changes from SharePoint 2010 to SharePoint 2013. Some highlights are: With SharePoint 2013, Search moved entirely to FAST and thus will need to be assessed. If search has been customized, it is likely there will need to be remediation efforts. Some site templates were discontinued, most notably meeting workspaces. The functionality for meeting workspaces has been replaced with OOTB team sites, Lync and OneNote. To move to the Microsoft suggested replacement of meeting workspaces, will likely require user training. Some enterprises have opted to create their own customized version of the deprecated meeting workspace template, while others have moved to more modern approaches like third party solutions such as AvePoint s Meeting App. Recently, InfoPath 2013 was announced as retiring after the 2013 version. Though still supported in SharePoint 2013, enterprises that have leveraged InfoPath 2010 in their SharePoint 2010 environment and who are in process of migrating to SharePoint 2013, may want to consider other options for forms in SharePoint 2013. One parallel related to features on the subject of cloud versus on-premise, is that of Office Web Apps as they are licensed differently. For Office 365 / SharePoint Online users are allowed to view Office documents online, however to edit documents specific subscriptions are required for online editing of Office documents. With on-premise it is similar to view Office documents online, however to use Office Web Apps to edit documents they must be licensed with Office, either through Microsoft Volume licensing 7 P a g e
or select Office 365 subscription plans. Consideration also needs to be made with the Office version being used to maximize the compatibility with SharePoint 2013. Customizations Customizations of all types should be inventoried. Organizations should use the upgrade as opportunity to minimize customizations where applicable. Customizations can be described as: Custom code solutions either farm or sandbox solutions Designer solutions SharePoint Designer, client side scripting (JavaScript, JQuery, CSOM, REST, etc.) Third party solutions like Nintex, Cosign, Bamboo, etc. User solutions list templates, site templates, etc. Each of these customizations can be evaluated separately but in most cases, efforts are usually around minimizing custom-code solutions so that these are moved to Designer, User or third party solutions. For this case we will focus on custom code solutions, specifically farm solutions. End-states are defined below for some farm solutions depending upon the implementation type: End-state for on-premise or VPC SharePoint 2013 1. Replace existing solutions with OOTB 2013 functionality (native functionality of 2013, Client side scripting, and Designer) 2. Replace existing solutions with third parties (third party app in App Store or third party farm solution, preference to App Store) 3. Replace existing solutions with custom App (in App Store) 4. Upgrade existing 2010 farm solutions to 2013 farm solutions (server deployed) End-state for Office 365 / SharePoint Online or shared service provider 1. Replace existing solutions with OOTB 2013 functionality (native functionality of 2013, Client side scripting, and Designer) 2. Replace existing solutions with third parties (third party app in App Store) 3. Replace existing solutions with custom App (in App Store) To start, an inventory of the farm solutions should be assembled, including information like the solution name, sites its deployed to, the site owner, to name a few. The various farm solutions should be evaluated with three considerations in mind: complexity, effort (time/cost), business value and desired end-state and end-state effort. Other categories such as solution usage (e.g. Branding, Forms, Reports, Workflows, etc.) can be included in the inventory to further describe the solution, further categorize it and identify common themes. A SharePoint Architect or team of SharePoint Architects that are both knowledgeable about SharePoint 2010 and 2013, and the solutions themselves can then gather the additional detail and assess the targeted end-state. Once this is complete, the solution inventory can then be prioritized based Complexity, Effort, and Business Value (Criticality.) In some cases, it becomes easy to prioritize too, for 8 P a g e
example, if core and generic solutions like branding, field types, content types, etc exist, they should probably be the first customizations approached, as they represent the framework for all the other customizations. After the above analysis is performed, remediation teams will need to be formed to perform the remediation of farm solutions to the end-state solution. Each solution remediation should be treated as a small project. Typical roles on a remediation project would consist of a SharePoint Architect, Developer, Project Manager, Business Analyst and/or Business Owner. Some remediation projects will be more complex than others. Generally speaking, a SharePoint Architect and Project manager could be assigned to oversee the majority of all remediation projects, with developers and business analysts being assigned for each project. Business owners would be assigned relative to the site or custom solution. Depending on the volume of farm solutions, it is possible there may be a need to add staff or resources to augment the SharePoint Development team in all the remediation efforts while still maintaining support to the existing SharePoint 2010 environment. Also, it will require existing staff time to gain experience and knowledge around SharePoint 2013 (OOTB features, custom apps, and third party.) The project methodology for remediation projects can be tackled a couple ways, by prioritizing based on Critically, Complexity, and Effort for example then sequentially walking through all the customizations. Or, they can grouped by end-state solution type, and organize resources around skillset. Additionally, remediation projects can be executed in parallel or concurrently if enough resources are authorized to support that approach. Summary In Summary, this document highlights the implementations options on-premises, cloud and hybrid for SharePoint 2013. Decision points are described such as cost and licensing considerations, information architecture assessments, complexities around customizations, and movement toward a service provider model to name a few. While these are decision points are just sample, they provide the basis for moving toward an enterprise-level implementation of SharePoint 2013. For more information, please contact: Mark A. Eckert Principal Consultant PHARMICA Consulting Mark.eckert@pharmicaconsulting.com www.pharmicaconsulting.com 484-554-9574 9 P a g e