cloud-whiteboardMigrating from SharePoint on premise to Office 365 has several  benefits that includes the ability to extend collaboration to mobile workers, customers and business partners. Additionally a wide range of features are available to boost productivity and simplify administration. For those considering 2016 for on premise (there are many reasons for retaining on premise farms, be careful about the hype), hybrid scenarios are simpler to deploy and manage. Not sure about the cloud? Read my overview blog. Note since publishing this blog I’ve published more detailed blogs Migrating to Office 365.

From a cost avoidance perspective, cloud based software services help organizations avoid infrastructure (Datacenter, Servers, storage and network) and ongoing management (change management, infrastructure staff and software) costs. But you still incur day to day administration, user training and support, compliance scanning and data protection costs once you’ve migrated. Also, you incur increased networking costs to connect to Microsoft regional datacenters.

Note this blog assumes you have have completed a feasibility study/business case for the cloud and the stakeholders have signed off. Don’t have a business case? Use this template to get started.

With all the benefits there are some areas of risk that must be addressed in the areas of business awareness, migration, data, security and administration. These risks can be mitigated with some careful planning, communications, testing and the adoption of toolsets. This blog is based on my experience working with organizations adopting cloud technologies and in summary format.

1. Create an agreed upon plan

First off, work with the sponsor(s) and stakeholders within the business and IT areas to develop a plan. This plan would define the goals, benefits, outcomes, risks, team, phases and desired outcomes and would be agreed to amongst all the stakeholders and signed off by them. Specifically, stakeholders would include executive sponsor, records manager, security manager, SharePoint service manager, SQL Service Manager, infrastructure manager (Servers, network and storage) and any third parties involved in the support of SharePoint and the data contained within it. Beware of passive aggressive and anti-supporter types, they will introduce a lot of politics that could lead to much extra work and grief. Keep all decision visible, all must sign off and keep communications open using ongoing status meetings and publish accordingly for all to see.

2. Correct any known problems with your farms

Often overlooked are problems with your existing environment such as mysterious event log errors, custom code issues, capacity and other issues. For this step I would suggest a Microsoft RAP or similar service and correct the problems they discover. Understand that if your environment isn’t stable or is out of capacity these issues will impact your migration costs, resourcing and timelines.

3. Conduct a detailed discovery

The detailed discovery will provide two critical reports that detail your SharePoint farms and business data. For the SharePoint farms, a detailed inventory of their configuration, customizations, third party tools to name a few. This inventory is very important because there could be elements of your configuration that cannot be migrated to the cloud (e.g. customizations, third party tools not available for the cloud).  For the business data, a detailed inventory of the data contained within the sites, meta data, classification and security information. This report is critical to understand SharePoints current state regarding data and security policy compliance. Your records manager and security manager will be able to provide significant guidance in this area. For discovery tools, most venders provide tools for conducting the discovery exercises.

4. Develop an information architecture

Your information architecture provides a detailed plan for site collections, templates, features, functionality etc. based on business requirements. You must work with the business, i cannot stress this enough as many bypass this and as a result adoption and usability fail. The persons conducting the exercises must have Information Architecture expertise, facilitation, communication and SharePoint skills. Note this exercise isn’t about asking the business what SharePoint features they require, its much deeper and requires an approach for work modelling and building consensus regarding requirements. Note most companies fail miserably at this for a variety of reasons.

5. Update your site and site collection ownership

Most SharePoint environments have grown organically and the the ownership hasn’t been kept up to date with employees, moving, leaving and changing roles. Having this ownership up to date is critical to communicating migration plans to the business areas and site users. If you have a governance team (IT and Business uses) and provisioning system (for sites and ownership upkeep), great your ahead of the game and if not you have a lot of work ahead of you. Expect to find many out of date and requiring time to update (Work with business unit leaders to find replacement). Also if your organization has a SharePoint user group, utilize that forum as well. Finally, create a control plan to maintain this ongoing which consists of process, policy, tools, staffing and checkpoints.

6. Data mapping plan

This exercise focuses on mapping the data in SharePoint to the the new information architecture. Its critical that this step occurs and that a high degree of communication and sign off occurs with the business users. The analogy I use to explain how critical this is, is my car parking example. if you park your car in the morning and then end of day walk back to the spot where you parked your car and its gone, you will call the police, worry and be very upset. Apply this to sites and business critical documents. If IT moves data without informing business users, escalations to executives will occur, the help desk will be flooded with calls and IT will loose credibility. I know of people that were fired because of this. The mapping plan must address one to one mapping especially if there is significant changes to the classification and tagging of data.

7. Security plan

This exercise is focused on creating a security model that depicts how permissions will be applied to sites using SharePoint groups so that business users have appropriate access to their data once its migrated. Work with site collection admins / business unit leads to create plan and conduct a cleanup of permissions. Address items such as people with full control, users that are no longer with company, unique permissions – the simpler and cleaner the permissions the less business interruption and audit risk. During this stage expect much cleanup as most site admins don’t use SharePoint groups and instead apply permissions individually. Also, many are implementing improved encryption, DLP, identify management, multifactor authentication, intrusion detection, security event management and vulnerability assessments ongoing. Finally, create  a control plan to maintain this ongoing which consists of process, policy, tools, staffing and checkpoints.

8. Develop a technical architecture

Your end state architecture will depend on your information architecture, security and data policy, service levels, capacity plan and deployment scenario. Specifically, whether you plan deploy hybrid or Office 365 only – Read my how to choose blog . Microsoft has much information on this topic so I wont go into much detail but will say that if you plan to go hybrid, consider SharePoint 2016 as hybrid is greatly improved. Also note you will require a divers team such as Architecture, SharePoint Admin, SQL Admin, Server and Storage admins, Security and network as well to name a few. Finally, create  a control plan to maintain it ongoing (Capacity plan, monitoring, correction etc.) which consists of process, policy, tools, staffing and checkpoints.

9. Document and test your processes and staff accordingly

The processes the team will follow must be documented and tested. The processes include and communications, pre-execution checks, detailed how to checklists for each migration scenario such as migrate to Office 365, to SharePoint 2013 on premise, split large site collections, combine small site collection, link updates, cleanup large and wide lists, refactor customizations etc. By documenting and testing your processes the team members will have a consistent easily repeatable approach to follow for the migration. Use tools to automate process and reporting such as reporting on site owners, large lists, third party etc. But remember that Microsoft doesn’t support using migration tools to jump versions. Use a intermediary farm if you do jump or else your in for a lot of pain. Also note your staffing must be augmented to include expertise to conduct the migrations, complex site remediation (dealing with complex sites such as composite applications) and post migration support. Expect anywhere from 2-6 people depending on current staff availability and skills, number of sites, timeline and budget.

10. Create and execute your communication plan

Informing the business users and IT of the migration is a critical and often overlooked step. Bypasses this step and or minimizing your level of rigour in this area could lead to much pain for your stakeholders and the business. Leverage all forums available to you such as executive communications, user forums, user groups, email, lunch and learn and a central collaboration service site. Plan to initiate communication 3-6 months in advance depending on the size and complexity of your organization. Setup a centralized site (e.g. Migration Central) for managing communication to users and the project team as a whole.  The site would act as a communication hub and provide site migration status, FAQ, Discussion areas, online training to name a few. Don’t use email and spreadsheets! Its chaos.

11. Test, test test…and document

Using a sampling of business and IT users that are “friendly” to your testing and minimally impacted but have political clout, test your process, tools, help desk and technical team utilizing a contained representation of the user community. Please don’t make the mistake of only testing IT users because they have acumen that is beyond most business users and this isn’t an accurate sampling. Conduct a few migrations as required and review, refine and improve until your stakeholders agree your ready. Finally, document the test cases and results and distribute for review and sign off by all stakeholders.

12. Phased deployment

I tried to fit this into “10 steps…” but could not :). Phase your deployment based on the amount of change your organization and team can manage. This phasing could be based on business units ability to support change, geographies or sites collections and their readiness. To get started, perhaps work with site collections that require the least amount of work to prepare such as those with no customizations and third party add-ons. If your migrating from 2007 note that large lists, FAB 40 and interface changes may cause headaches so be prepared. The key message is don’t take on  more than you can handle and risk a failed deployment.

Some final advice, tools are enablers only – do the heavy lifting. Focus on tools only and you will fail. Focus on your organizations needs, preparing the business units, IT help desk for increased work load, test your process and communicate often.

Want to know more? Have questions? Feedback? Contact me