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.
- VIPs – these are persons are departments that require extra attention and priority. For these sort of users / business units more hand holding will be required and scheduling to minimize impact.
- Resourcing – resourcing in place for pre-migration, migration and post migration activities – usually separate teams.
- Capacity management – capacity plan in place and product roadmap updated to reflect procurement (lead time for purchase and installation) of additional capacity (Servers, storage, backups, network etc.) and services.
- Process – rigorously tested, documented and ready to go.
- Tools – 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.
- 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
- Product management have roadmap in place for additional capacity, services, patching and feature activations.
- 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.
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.
- Product manager – alignment with dependency products (Servers, VMs, Storage etc.), capacity plan in place and product roadmap updated to reflect procurement (lead time for purchase and installation) of additional capacity (Servers, storage, network etc.) and services.
- 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.
- Capacity planning – projecting capacity needs (Servers, network, storage) and accounting for provisioning timelines (Provisioning lead times can be weeks or months depending on complexity of operating environment) for your environment. Weekly reporting is highly recommended to stay on top of projects versus reality.
- 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 email@example.com