Migrating to Office 365 or SharePoint Online? Part 7: Pulling It All Together

Concluding my Migrating to Office 365 – 12 steps that will help you get there blog, this blog is focused on the execution of your migration project – once you’ve completed all the preparation steps. If you haven’t, read my past blogs as they are focused on preparing – Migrating to Office 365 – 12 steps that will help you get there blog. Also, note that skipping any of the steps introduces risk in the form of quality issues and cost overruns but most importantly negatively impacts the business users and their day to day operations. Finally, I’ve had this blog series on my to do list since March 2015 but never got around to it due to family sickness. Thank you for all the emails and feedback regarding how you utilized this series for your projects and articles.

During preparation phases we conducted an inventory, analysis, cleanup and established the controls required to be successful. The controls consist of communications, scheduling, resourcing, budgeting and risk management – all very important topics often carelessly overlooked by management to save time and money but actually results in overruns and unnecessary risks that negatively impacts the business longer term. The following is a quick refresher:

  • Communications – established with lines of business, site collection owners, technical team and PMO. Templates, email, Migration Central site, escalation process to name a few.
  • Scheduling – established based on fiscal, technical, contractual and resource requirements.
  • Resourcing – resourcing in place for pre-migration, migration and post migration activities – usually separate teams.
  • Process and tools – rigorously tested, documented and ready to go.
  • Risk plan – work with extended team to assemble list of risks, likely hood of occurring, impact and plan to addresses them – more on this later.
  • Budget – is based on solidified requirements, extensive peer reviews and allocated for certain – executive sign off in writing.

As part of your analysis you categorized sites by complexity – green, yellow, red. Though you may think green starts first that’s not the case, all sites begin at once – I sure hope you planned your resourcing or you will incur much risk – this is covered later in Blog. What do I mean by start all at once? Here is a quick summary:

  • Green sites can begin almost immediately because no re-work or cleanup is required. For green sites, simply give site owners enough waring to prepare, review training materials on the new SharePoint and prepare the site users.
  • Yellow sites, cleanup and some minor rework will be required – don’t underestimate the work associated with correcting and reworking sites and the risks of not addressing this work properly. The risk of not doing so is business outages and cost/schedule overruns. For example, the rework could be version cleanup, user permission cleanup, site owner updates, simple large lists (Only require indexing and views and maybe some archiving or deletion).
  • Red sites cleanup could mean complete rework. For example, FAB40 templates sites, extensive SPD worked sites, or a third-party tools that are no longer supported, out of control lists (Users that utilize SharePoint as a database 15-25k items 50+ columns wide) or customizations that simply won’t work in the cloud or that the organization does want in new environment due to support costs.

So, let that sink in for a while you’re thinking about migration logistics, risks, resourcing and budget. Let’s come back to sites later in the blog, let’s talk about what you require in place before executing your actual site migrations.

Before communications begin a complete Inventory of sites that is 100% up to date with owner information as they must be notified of the migration early to help them prepare. Your communication plan must include all the standard items such as people, process and tools such as Migration Central site (See prior blog), Help Desk Scripts, Email templates for contacting sites owner pre, during and post migration. Also beneficial is the issues and action plan includes procedures, guides, communication and escalation process for dealing with problematic owners and sites.

Training for your migration such as how to prepare, what to do during and post migration. Topics include how what the site owners, users and migration team are responsible for – helps remove ambiguity.  Training materials for new platform such as Office 365 and or SharePoint 2016 “How to…” for site admins and users. Note that Migration Central can house the training materials as well as other support materials such as FAQs, discussions to name a few. It can also house a discussion area for site owners and user to ask questions but must be staffed so that questions don’t go unanswered.

As with any project, staffing is critical but keep in mind that SharePoint is a customer facing highly business visible application. As a result the lack of a skilled and experienced team and honed methodology will be very noticeable. So advice for assembling your team:

  • The lead architect and PM must have migration experience on the resume or you’re at risk
  • The help desk must have person(s) trained on the migration so they can triage calls properly – primary and backup is a good idea and make sure the shifts are covered. Support scripts will be required so process and policy can be followed consistently
  • The development team tasked with yellow and red site cleanup must have experience with SharePoint and tasks such as large lists, InfoPath, custom templates and third party tools. The team will also have access to the version control library and documentation collected as part of the analysis phase.
  • The SharePoint team will require augmentation because of increased call volume. Issues will arise such as how to, minor site migration issues and basic handholding. They will also be required to help provision sites, related content databases and most likely trend reporting. To help, training staff will be required as some just won’t have time to review online training so this can be dedicated staff of conducted by the SharePoint team.
  • Coordination and reporting staff will focus on managing the Migration Central site, communications to site owners and trend reporting. Your team will also consist of toolset venders and most likely Microsoft to assist when issues only they can resolve.

You will also have representation from cloud, networks, servers, storage, security, compliance and communications team.  On a final note the less experienced your team is, the more risk you assume because they don’t know what they don’t know.

Each phase of migration must be incorporated into your master plan and master schedule, published in a project schedule and on the Migration Central site. Each phase will include preparation emails to site owners, notifications to the persons operating the migration tools, persons conducting post migration support. Don’t forget reviews of migrations at each phase and incorporate the learnings to improve your overall program. If you haven’t read ”
The Fifth Discipline: The Art & Practice of The Learning Organization” By Peter M. Senge, I highly recommend it.

Risk Planning
Though we covered a risk planning exercise in a prior blog I want to recap some common risks to highlight that you cannot skip this step and be successful. Risk planning must one of the first exercises you carry out with the extended team:

  • Executive support – no executive/or an executive with weak funding capability, no ties to the business, lacking strong relationships and empowerment over technology area and all its silos.
  • Management – management disempowered and in denial, with no funding or weight they are not able to support the project team effectively.
  • Funding – no funding for the experienced people, tools and venders required for success.
  • Project team – one small inexperienced team that must do it all – this results in staff turn over, quality problems and schedule overruns.
  • Project manager – hasn’t worked on migrations or in the solution space before.
  • Lead architect – hasn’t worked on migrations or in the solution space before.
  • Culture – not conducive to team work – soloed and full of anti-supporters – traditional organization.
  • Site remediation – is skipped or done poorly – no clear line of sight to work required and risk areas.

If you haven’t already, read my Migrating to Office 365 – 12 steps that will help you get there blog – use it as a checklist. If you have completed all the steps then good for you, you have minimized your risks and had a great chance at success. If you haven’t completed all the steps, you’re at risk and expect a rocky road and have your resume ready. If you work in a traditionally structured organization such as government and financial for example conduct aggressive risk planning as these sorts of cultures will have great difficulty with projects such as migrations because their culture  isn’t conducive to success. Note most fail at their first migration projects, people quit and IT managers get fired – do your company a favor and hire experienced people and listen to them.

Have feedback or experiences you want to share? Contact me roncharity@gmail.com

How to staff your SharePoint Team

people at workHaving seen both good and bad I thought this would make an interesting blog. After having a chat with some of my industry peers I realized that some management teams don’t staff sufficiently and their SharePoint team and business users are suffering for it. Specifically, management staffs SharePoint teams like they would IT infratrsucture and not a business facing service.

With SharePoint being a global service in many organizations that have offices in the America, EMEA and ASIAPAC, SharePoint’s reach is broad and its user base very large. This places a huge support burden on IT departments as the support requirements are 7/24 and the must staff accordingly. The downside of not staffing correctly is higher than usual staff turn over, not meeting expected service levels and not containing costs.

So how staff? Here is a baseline model:

  • Executive sponsor – Owns budget and ultimately service quality and compliance with company policy. This is an active role, supporting the team during budgeting, downsize, escalations and being able to say NO to the business when resources are not available or the request is not in the best interest or suited to SharePoint.
  • Product Management – Owns product roadmap, new feature releases, risk planning, develops budget and other operating models. Works with other product managers to align roadmap such as Operating Systems, Database services and other related infrastructure. Also work with business unit and SharePoint User Group to collect establish two way communications.
  • Service Manager – manages the service to control plans for availability, performance and compliance. Deals with staffing, outages, escalations, reporting and problem management.
  • Business Analyst – works with business unit and user group community to facilitate and capture requirements. This role requires strong communications, knowledge of business, technology, writing and facilitation.
  • Engineer / Architect – work with business analyst and technical team on requirements to design enhancements and supports broader team from a technical perspective.
  • Developers – work on code, manage source code and documentation. Know and enforce development standards, know the customizations inside and out. The number of developers depends on size of environment and number of customization. there should be at least one that knows all the customizations to some degree.
  • Quality Assurance – develops test plans, test cases and reports for testing new features and performance ongoing. Maintain quality assurance environment such as data set, toolsets and related documentation.
  • Administration onshore (Day) – day to day administration which includes Help Desk, service sustainment, provisioning, service packs and other changes.
  • Administration off shore (Night) – day to day administration which includes Help Desk, service sustainment, provisioning, service packs and other changes.

The aforementioned model assumes you have teams allocated to shared services such as help desk, monitoring and reporting, coding and source code management, networking, servers, compliance/risk management, storage and quality assurance.

It’s important to remember that most organizations rate SharePoint as a Administration level application or tier 3 or 4 – whatever is lowest in your organization. As a result its not allocated the same funding and attention a mission critical tier 1 or 2 application but that doesn’t stop business units from building mission critical applications and there in-lies the political rub – the disconnect that makes life difficult.

Have feedback? Send me your ideas roncharity@gmail.com

SharePoint Test and Quality Assurance – Part 5 Office 365 Migration Testing


Some of you may have read my blogs on SharePoint testing, I wrote several blogs on the topic such as SharePoint test and Quality Assurance – Testing SharePoint out of the Box Part 3. Often overlooked, any complex product that requires the amount of configuration and infrastructure that SharePoint does must be tested and tested ongoing especially when migrating between versions because of the user interface, data and security policy impacts especially when migrating to Office 365.

The blog will focus on the creating your test plan, test cases, report and presenting the results to manage expectations and correct any faults. Where possible I will provide documented example templates you can use to kick start you’re testing.

So where do you start? Create a test plan as follows:

  • Define the purpose of the testing – generally it’s to manage the risk associated with migration to understand the following:
    • Impacts of migration to end user from a usability perspective
    • New training required for end users
    • Determine initial impact help desk and support resources
    • refining communication plan
    • Verifying connectivity required between the environments
    • Verifying ability to enforce data and security policy
    • Testing migration tool sets to understand what can be automated
    • Identifying manual process tools wont address
    • Where additional scripting is required
    • Creating migration guides for the migration team (forms the basis)
    • Determining impact to servers, storage and network
  • Determine the staff and skills required.
  • Funding required for the staffing.
  • Defining the test environment from a technology perspective.
    • Source and destination environments (Servers, network, software etc.)
    • Network requirements (e.g. bandwidth, firewall rules etc.)
  • Defining the dataset that will be used (e.g. what datasets are available that mimic production? Must a dataset be assembled from scratch?)
    • Create manually (Takes a lot of time or use scripts)
    • I’ve implemented a mix of both to best try a mimic production
  • Defining key outcomes such as answering the six bullets above as an example.
  • Link to test plan template

Once you have completed writing your test plan, circulate the document for review and sign off with the key stakeholders such as the following:

  • IT Director – Executive responsible for environment. Depending on signing authority I suggest the CIO be looped in as well.
  • Product manager – owner of SharePoint / Collaboration service.
  • Service management – operation teams such as support, server, network, storage and directory teams
  • Quality Assurance Manager – manages QA team.
  • Engineering – engineering / architects responsible for the environment
  • Microsoft – your friendly Microsoft support person / team.
  • Third party – any third parties that support the environment such as staff augmentation our outsourcing.

Note it’s important to collect everyone’s feedback, answer their questions, educate each other and obtain sign off. By completing this stage correctly you will avoid organizational risk that could create roadblocks due to misunderstanding objectives and outcomes.

With the Test Plan signed off, you can now create your test cases and report documents. Your test cases document will contain a list of test cases which must follow the Rational Unified Process (RUP) format. Keeping its simple, each test case should contain:

  • Name – A descriptive name.
  • Description – Short description of the test case.
  • Data set – A description of the data set being used using the test.
  • Preconditions – What must be in place or is expected to occur be for test.
  • Post conditions – expected post conditions as a result of completing the test.
  • Steps – steps for tester to carry out test.
  • Outcomes – The results of the testing
  • Screenshots – Screenshots that show the outcomes where it makes sense (can be very effective in communicating).
  • Link to test cases template

With the above format in place, the following test cases are recommended:

  • Site Migration to destination environment(s) SP201x and or O365
  • Home page migration (especially from 2007 environments)
  • Permissions groups migration
  • Large list migration
  • Complex list migration
  • Custom site template migration
  • Custom list template migration
  • Custom workflow migration
  • Custom forms migration
  • Custom .Net code migration
  • Custom embedded HTML/Java code migration
  • Site migration duration 500 MB, 1 GB, 5 GB and 25 GB (Do for both SP201x and O365)
  • Broken links identification and correction (Update)
  • Impact on server work load
  • Impact on storage work load
  • Impact on network work load

The above items are some basic tests than you can start with and build from their depending on your environment. For example, you might want to test Content Editor WebPart migration that contain custom CSS and Java, third party application migration, test impact to version settings and recycle bin. From a manual process perspective you might want to test Large List cleanup processes (Views, Indexing etc.).

For monitoring during load tests you should monitor server, network and storage devices. For Servers you can use PAL, for network speak with the network team and monitor traffic between new and old farms and O365.

Some lessons learned include documenting everything, circulating and communicating results, dealing with problem employees quickly and managing expectations aggressively. Involve all stake holds and make sure they sign off in writing to avoid roadblocks and politics.

Found this helpful or have feedback? Contact me roncharity@gmail.com

How to onboard a new employee

1207671864ZIz0d4Chatting about this topic with some colleagues last week there were some interesting comments such as “You should know what to do…” or “We haven’t hired a new person in 12 years and don’t know what to do”.

Onboarding is a process of welcoming, educating, connecting, and acculturating new employees. It helps assimilate them into work and team processes and into an organizational culture. It provides new employees with the necessary tools and resources to carry out their jobs and clear channels for ongoing knowledge acquisition and collaboration. It instills in them a sense of connection to individual, group, and organization goals and a drive to contribute.

Keeping in mind the onboarding experience sets the employees perception of the organization they joined. Therefore it’s in the employer’s best interest to make sure the experience is positive.

The best examples I’ve seen of onboarding are as follows:

  • Manager introduces employee to the team and persons they will work with directly.
  • The usual tour of the office and its amenities.
  • Explains how their performance will be measured – the specifics prioritized.
  • Establish the communication rules between the employee and new hire – for example, use email? meetings? face to face? Explain how you prefer to communicate.
  • Highlights what’s in scope of the job and what isn’t giving real examples.
  • Outlines required reporting, tools he/she will use and training required to achieve performance levels.
  • Provide laptop, IDs and access tokens as required.
  • Connect employee with HR for payroll and benefits information and enrollment.
  • Help employee understand company culture and politics – makes employ mindful of landmines.
  • Assigns a great mentor (Has people and technical skills and knowledge of environment and how to get things done) to help the new employee be successful.
  • Establishes regular updates to provide feedback and coaching – use specific examples with background, not “I heard this…or someone said…”. Use actual job activities and peoples names.

The following is an example of a general onboarding checklist you can use as a basis.

Any funny stories to share?

Migrating to Office 365 or SharePoint Online? Part 6: Document and test your processes

iStock-Unfinished-Business-2Early in my career I lucked out being able to conduct process related consulting for business processes, receive Capability Maturity Model Integration (CMMI) and Rational Unified Process (RUP) training at HP and later work with some great quality assurance professionals. They say if you ask a manager for a solution, they will recommend rigorous process and policy to enforce. If you speak to a technologist, they will recommend tools – they are both correct. Not taking a holistic approach to migration projects will lead to delays, cost overruns and quality issues – a lot of frustration as well for all involved.

To proactively manage expectations, quality and consistency, document the processes for conducting inventories, communications, site cleanup, site migrations, customer support, training and retirement/archival of old sites and content. For a summary of my approach read my Migrating to Office 365 – 12 steps that will help you get there blog which is a summary of my migration framework scars and all.

Where do you start? First off you will require a team consisting of the following roles/persons and note the list varies in accordance with the size of your organization and staffing:

  • Technical writer – This person is a writer by profession and is tasked with writing the documentation (Very involved).
  • Communications person –This person is responsible for communications being distributed to the end user community such as emails, website communications, lunch and learns and posters.
  • Migration tool vender technical person – This is a contact from the vender of choice that will help you with inventory and migration testing and documentation (Very involved).
  • Project manager – A friendly PM that will help coordinate the efforts and herd cats as required – such as procedural ambiguity, anti-supporters that want you to fail – have seen a lot of these.
  • Quality assurance person – This person will create the test plan, test cases and write the test report (Very involved).
  • Operations person – This person will provide production insight and support.
  • Product management – The product manager for SharePoint/O365 must be involved to help with project activities and decisions related to the service offering and roadmap.
  • Engineering/architect – This is the technical lead with SharePoint, O365, Migration and procedural experience.
  • Security person – The security person provides security insight specific to SharePoint site security and data protection.
  • Legal counsel/records manager – provides guidance and direction regarding audit and records management such as site and data disposition.

The persons with “Very involved” are tasked with most the hands-on work while the others play and very important role as well but mostly provide guidance, reviews and other required insight specific to their area of practice.

Once you have the team assembled, they will be tasked with the following:

  • Create a Migration Central Site – this site will act as the hub for site owners and the migration project team for communicating project goals, site migration status (dashboard of sorts) and actions required, provide training materials, FAQs, host discussions and related project materials. By utilizing this site, you will reduce confusion significantly as people will know where to go for information and not chase down email and spreadsheets. Read more
  • Document your inventory process – working with either your toolset vender or developer, document the process for running inventories, assessing and categorizing sites by complexity (work required to migrate). I use the traffic light analogy, Green = out of the box, yellow = out of the box but with large lists, InfoPath and workflows and Red = Visual Studio customizations and or third party add-ons or those that have seriously exceed software boundaries (e.g. 250k item lists and 400GB site collections.
  • Document your quality assurance materials – this includes test plan, test cases and test report. You will be very surprised by the discussions this work initiates and it’s all good. The plan will include how testing will be conducted, why, the data set to be used to name a few. Test cases will include detailed test cases for migrating and testing sites. The test report is the outcomes of the testing and recommended next steps. I use the rational unified process, if you’re not sure what to test contact me or read more
  • Document your migration process – this is a document that steps the reader through the end to end process for migration sites whether they be simple (Out of the box) or complex (customized with custom code, add-ons etc.) sites. These steps will be tool specific and in the case of heavily customized sites, specific to your environment. To get started utilize the toolset vender’s manuals as they will help jump start the process significantly. if you’re not sure what to test contact me.
  • Document your communications – all processes related to user awareness, preparation, status and follow-up. For example, what emails (Prep, during and post communications) will be sent to users, what it will contain and how replies and no-replies will be handled. Also how the help desk will be integrated into the process to screen and escalate calls accordingly. For example directing users to site migration status, FAQs, Training and Discussions on Migration Central Site. Or engaging support for port migration issues such as permissions or other functionality that not working as expected.
  • Sign offs – Signs offs on all documentation by the major stakeholders such as IT, Records Management, Legal Counsel, Security, Operations, Engineering, Architecture and everyone else that is a stakeholder such as third party service providers.

But this is a summary only! Correct, it is. I’m under NDA in most cases and these materials are customer specific and cannot be distributed. Do I reuse them to help my customers fast track? Yes, but they require scrubbing and refactoring.

Some advice, work to involve all the stakeholders, remove negative people early in process as they will only work against you, raise awareness at senior levels (2-3 layers above frontline management), be prepared to deal with anti-supporters and noise makers – make sure everyone is actively involved as best makes sense and finally make sure your toolset provider has a local presence and experienced staff.

In summary, the aforementioned list of documents and advice will help accelerate your efforts. If you’re in a regulated industry such as Pharmaceuticals you might require more sign offs and documents such as IQ/OQs – your executive sponsor and PMO can guide you in this area. As I’ve mentioned in prior blogs I’ve worked in many industries and countries which helps me guide clients – make sure your PM and Architect have such experience.

Found this blog helpful or have suggestions? Contact me roncharity@gmail.com

Migrating to Office 365 or SharePoint Online? Part 5: Develop a technical architecture

Information-OverloadThere is a wealth of information available regarding how to design and build technical architectures but there isn’t a clear view of your organizations infrastructure, risks and operational details and politics. We can talk about the number of servers, network connection to Microsoft if your deploying O365 but at the end of the day the design will depend greatly on your environment from a technical, operating and financial perspective. For a summary of my approach read my Migrating to Office 365 – 12 steps that will help you get there blog which is a summary of my migration framework scars and all.

Let’s dive into these topics further and I’ll recommend some reading for those wanting more information.

  • Financial – First off, what is the operating budget for your environment (e.g. funding for staff, infrastructure and contingency)? Do you own the infrastructure or is it leased (e.g. is it new? Fully depreciated? Lease ending soon)? What funding do you have remaining currently? What have you budgeted for next year? If you can answer the questions, then great and if not I suggest you seek out someone with financial management insight and experience. With financial insight, you can  assemble a meaningful business case for your new environment based current state as a baseline. When selling to the business you can speak to new services, agility, consistency, simplification and mobility (Speaking to enablement, alignment with business roadmaps and ease of use are best). When selling to IT management its generally about cost optimization and risk mitigation (Value add will create road blocks as IT people especially Operations hate change and are usually oblivious to business roadmaps and risk).
  • Operating – What staff and skills do you have? Current workload? Full time vs contractors? Service agreements with venders and service providers? For example, depending on skills and workload you might have to lean on service providers more than usual. If you have outsourcing agreements in place, contractual changes might be required for new infrastructure and staffing for the proposed environment. Another example focuses on your organizations support model and the alignment between the groups such as SharePoint, SQL, Windows, Network and Storage. As organizations grow larger, outsource and pepper in company culture you quickly end up in a politically charged environment full of poorly designed handoff points, nebulous process and policy, finger pointing and management that doesn’t know how to execute or has lost control. For example, in 2010 I managed a large SharePoint environment and most the issues were organizational – people did not work together due to trust issues, IT did not have a solid grasp of their infrastructure – IT was powerless as they didn’t have executive support. Add poorly documented and negotiated outsourcing agreements which ended up paralyzing execution.
  • Technical – There are many variables that will steer your technical architecture such as funding, functional requirements, compliance and audit obligations to name a few. To simplify the discussion let’s assume you have decided on a Hybrid model with SharePoint 201x and O365 (50/50 workload distribution. There are a few key areas I’d suggest focusing on:
    • Data management – using you control plan as a reference, what tools and settings are required to ensure your data will reside in the correct environment and be enforced ongoing. For example, how will O365 Compliance Center be configured, reports required and staffing to operate? How will classification be optimized for user experience? What have past audits recommended? Yes, this is a huge topic, search my blogs for more information as this blog is merely a summary. Read more here
    • Network – what changes are required if any to support the network bandwidth required between your network and the Microsoft O365 data center(s)? Has your network team conducted an analysis? Your network team can run reports on your current SharePoint workloads from a network perspective. If additional bandwidth is required, how will it be funding? Key message, involve your network team and vender in the study and be aware of global implications as some regions have limited bandwidth and latency capabilities. Read more here
    • O365 tenancy – what applications do you require? Features and functionality? Capacity? Microsoft has some excellent documentation on the topics that will help you through the process of answering the questions. Read more here
    • On premise – what do you require on premise? Virtualization options? Server standards? How flexible is the virtualization team? How stable is their environment? How quickly can they respond to capacity and feature add requests? For example, I’ve worked with organizations where the SharePoint team owned the virtualized environment and optimized it for SharePoint and SQL Servers – ran smooth and was optimized. I’ve also worked with organizations where the Virtualized environment was not optimized for SharePoint and SQL workloads, it took 3-4 months to adjust for capacity and feature requirements and the team track record was not so good. Key message, as you look at options know who you are working with, their ability to deliver and reputation for team work. Read more here
    • Tools – You’ll require tools for migration, moving content, enforcing security and data compliance. For example, how will you migrate content to O365? How will you copy content from your on premise 201x environment to O365. How will you meet data backup and restore requirements? Assuming your migrating from 2007 or 2010 you will require a migration tool that that will migrate you to O365 and or 2016. Or maybe you have 2013 and can use DB Attach and then copy to O365 using tools. This all assumes your source environment can be migrated as is and doesn’t require significant remediation due to data policy violation and or technical issues such as exceeding software boundaries (e.g. large lists, site collection size, custom code or third party add-ons). Read more here

Many topics covered in a summary manner, yes it would be nice to have an end to end checklist or best practices but nothing replaces experience. The worst scenarios I’ve witnessed are oblivious management, an inexperienced technical team and project management. It’s not their fault, the executive team has not supported them sufficiently – SharePoint is generally a nice to have and not mission critical so doesn’t get much of their attention until an “Incident occurs”.

In summary, your end state architecture will depend on your information architecture, security and data policy, service levels, services available to you such as virtualization, capacity plan, operational model and deployment scenario. Specifically, whether you plan deploy hybrid or Office 365 only – Read my how to choose blog and SharePoint pro articles on Architecture. Microsoft has much information on this topic so I won’t go into much detail but will say that if you plan to go hybrid, consider SharePoint 2016 as hybrid is greatly improved and user experience more consistent with O365.

Found this blog helpful or have suggestions? Contact me roncharity@gmail.com

Migrating to Office 365 or SharePoint Online? Part 4: Enforcing your data and security policy

data-breachesMost SharePoint environments have grown organically and as a result SharePoint sites have become digital landfills with no monitoring, reporting and or enforcement. Its not that IT departments don’t want to do the right thing, they simply can’t in most cases due to lack of staff and tools. In addition, no control plan and executive support to execute and manage the control plan ongoing. Unfortunately, until there is a serious breach or lawsuit most executives are oblivious regarding the risks and the steps required to correct the situation. For my 12 step plan for moving to the cloud, read Migrating to Office 365 – 12 steps that will help you get there.

In Part 3, you were tasked with updating and reporting on all the site collection owners. Completing Part 3 the site collections ownership has been updated to include the business area executive, primary and secondary owners to reestablish security and data policy compliance, billing and audit requirements.

In Part 4, you will focus on a detailed data classification and mapping exercise that will enable your organization to enforce its data and security policy. For example, migrating data to the appropriate platform (Cloud / On premise) based on your policy. Transitory data that isn’t classified confidential or non-public can be moved to the cloud. Data that is confidential will be kept onpremise. In addition, cleaning up permissions before the migration is recommended as most environments have not been setup and managed by untrained site owners. It’s common to find permissions issues ranging from numerous sites owners, lack of group usage and broken permissions at all levels of the sites and subsites.

Sounds like a lot of work doesn’t it? It is and many skip it and risk data loss and law suits from exposing client information and or other non-public information. As one of my colleagues said to me once “Pain me know or pain me later”.

The following are the tasks that must be carried out:

  • Data Mapping – This exercise focuses on mapping the data in SharePoint to the new information architecture. It’s critical that this step occurs and that a high degree of communication and sign off occurs with the business users. To carry out this activity you will require a tool (e.g. NextLabs Enforcer) that scans your site collections and tags data based on your data policy. Work closely with your vender of choice as they will be able to provide you with the support and guidance required. Most scanners have options for scanning based on PCI for example. To determine what you must scan for speak with your Security Manager – request the Control Plan and Data policy documents. These documents will provide you with the information required to run scans and classify data. Keep in mind you’re not conducting an exhaustive classification exercise, that would take much to long in many cases due to the sheer amount of data that exists in many organizations and lack of resources. What your aiming for is traceability back to your Data policy so you can demonstrate compliance to an Auditor. Note that some may choose to simply migrate to Office 365 and then utilize Microsoft Compliance Center in Office 365. The key outcome of this exercise is an itemized listing of sites that must remain on premise and or data removed from SharePoint sites to remain compliant and a updated control plan (e.g. how to handle non-compliance such as notifying site owners and removing PCI data from cloud).
  • Security Model – Your security will provide guidance to SharePoint Admins and Site Owners for applying and enforcing security for site collections and the data that resides within them. I highly recommend keeping this model very simple as most likely your organization won’t invest much in site security. Here are some simple guideline and feel free to adjust them to your needs:
    • Utilize SharePoint Site Groups as the standard.
    • For data requiring different permissions (e.g. confidential vs public) utilize another site or create a library and break permission inheritance.
    • Allow site owners to manage all groups except Site Collection Admins and Site Owners.
    • Provide online how to videos – quick 1-2 minute how to.
    • Provide your help desk with support scripts.
    • Make site owner SharePoint training a yearly mandatory exercise.
    • Automate the deletion of users that have left the company.
    • Create procedures for audits and the work involved. Provide links to the site owners for the procedures.
    • Updated control plan that details how security will be configured, training required, reported on and enforced by tools, policy and staff.
  • Security cleanup – Here you will report on the current state of security for each site collection. This involves running reports on the site collection security and itemizing each entry and correcting if required. Sounds exhaustive? Yes, it is but in regulated industries you must provide such reports to Auditors to demonstrate compliance. There are many scripts available that can help you with this step such as https://gallery.technet.microsoft.com/office/SharePoint-20132010-68415a22. As with any such resource and time intensive process utilize common sense. You have site collections that your SharePoint admin knows are a mess, focus on those first – think 80/20. The outcome of this exercise is a plan that addresses the highest risk site collections, how to address audit exercises and a plan for enforcing ongoing that is endorsed by the executive sponsor.

Note that as you address your data and security needs, auditors do not like SharePoint (My Audit training in NJ 2008 was valuable, it gave me insight into how auditors think and how companies handle them) Why? Its distributed security model (e.g. Think AD which is centrally managed with rigour vs SharePoint sites which is in many cases a free for all) and lack of enforcement and structure. If you can demonstrate that your enforcing security and data policy to the best of your ability (e.g. executive support and funding) your ahead of the game.

Found this blog helpful or have suggestions? Contact me roncharity@gmail.com

Office 365 Migration How to Methodology

reading-traffic-management-moves-to-the-cloud2I’ve assembled an Office 365 How to Methodology based on my experiences consulting and being on the customer side of the fence from 2010 to 2015. You may have read my 12 steps blog which is a summary of steps. Migrating to the cloud especially in a regulated industry adds much complexity that must be managed with an aggressive risk management plan. These risks include organizational, regulatory, audit, workforce and technology.

What I’ve found working with companies is the following but this isn’t a comprehensive list, just a sampling:

  • There’s no complete plan
  • The project team isn’t staffed with all the disciplines and representation required
  • No risk planning was conducted
  • The business isn’t engaged and an open line of communication established
  • No product management staff to manage platform lifecycle and roadmap
  • The executive sponsor has no ideas what they have signed up for
  • The team doesn’t have experience with migrations
  • No cloud experience on the team
  • Testing isn’t formalized or there’s none at all
  • Companies expect tools will do all the work
  • Detailed platform and data inventories do not exist
  • No site ownership inventories and remediation plan
  • No comprehensive communication plan

My methodology it’s a practical one that an experienced architect can implement with a strong PM and team from the required areas or discipline. A series of documents such as template feasibility study, risk plan, project charter and team staffing and skills matrix, they help fast track and organizations path to the cloud and realize the benefits of:

  • Service cost optimization
  • Faster deployment of services and features
  • Measurable progress indicators
  • Reduced technical complexity
  • Support staffing optimization
  • Improved reach and service for mobile users, customer and business partners
  • Hardware leasing and or capital costs savings
  • Audit compliance
  • Product roadmap

Yes, there are how to guides out there but they are all tool focused mostly, using the iceberg analogy, most the complexity is below the waterline in the form of organizational complexity, nebulous policy and process, required experience, organizations ability to execute, skillsets and audit compliance.

What’s included in the methodology:

  • Cloud overview benefits presentation
  • Feasibility study template
  • Risk plan template
  • Control plan
  • Project charter template
  • Team staffing template
  • Tool installation and testing template
  • Tool configuration template
  • Migration process guide template
  • Communications plan and templates
  • Migration central site collection template

The assemble of this methodology has taken a few years to refine I’ve had help from several SMEs in the area. The fun part of this personal project was hearing from other in the industry and about their experiences.

Want to know more? Have feedback on the blog? Contact me roncharity@gmail.com