Early in my career I was a technical project manager working for a certain phone company in Northern California. Back then, before one company gobbled just about all of them back up, there were still several RBOCs (Regional Bell Operating Companies) with ever-expanding lists of competitors, looking for every opportunity to reduce costs and stave off the loss of customers moving to the telephony upstarts. During this interesting time in telecommunications, I was part of a "technical marketing" team tasked with arming the company's consumer marketing and operations teams with the latest in campaign management and data analysis tools, rolling out applications like Business Objects, Crystal Reports, and numerous SAS modules.
In this role, I helped manage a huge datacenter consolidation effort that moved assets from three data centers down to one (not one of the three). If that wasn't big enough, we were also tasked with switching out our SGI hardware with new HP machines, and then deploy the new productivity applications, coordinating end user training and handing it all off to support. It was a massive project involving dozens of architects and PMs, and took over a year to plan out. Did I mention that all of these systems were real-time, which meant our windows for execution were tiny?
I share all of this background with you to help drive home the impact of one little fact: the operations teams at those data centers were not part of the initial planning. That's right – the teams that owned and operated the data centers, and who were responsible for physically switching out the hardware and installing the new software – were not part of the initial planning discussions.
As the PM, I became acutely aware of this mistake upon my first visit to the destination data center, where (thankfully) I ran into some helpful folks who shed some light on the project planning and approval process. I then had the delightful task of bringing this information back to my team.
Your SharePoint hardware may not sit in a data center, but there is still the need for staging your platform for migration. SharePoint might be on a server sitting underneath the desk of someone in your IT department (hopefully not), but any change will impact your end users – and you should have a plan in place. As your migration plan begins to fall into place, you should start working closely with your IT or operations team to coordinate the migration. Make sure you understand your system and operational requirements, and schedule ample time to work with these teams to prepare.
At a high-level, this plan should consider:
- Hardware – do you meet the Microsoft recommendations? Have you planned for growth and scalability? Will the farm meet your performance needs?
- Software – have you installed all of the latest service patches?
- Network – have you prepped your users and IT team on the upcoming migration, and how it may impact the system while in progress? If you're planning to move to Office 365 or another dedicated hoster, have you benchmarked performance for your migration? If you have terabytes of data, you may need to consider alternatives to help expedite your move.
- Virtual environments – have you included them in your upgrade and migration plans?
- Hosting / datacenter – is your project on their schedule? Are the appropriate people and resources available?
- Downtime / end user impacts – have you estimated and communicated the project plan and schedule to all of those who will be affected?
- Communication plan – have you published a proactive communication plan to all stakeholders, giving visibility into your plan (especially in the days leading up to the migration) and sharing regular updates as the migration progresses?
- Location of your teams – does your plan take into account different regional requirements for downtime, hardware, communication?
- Backup/recovery – what is your plan should your migration fail and/or the clock runs out?
Migration planning is all about risk mitigation. What may seem like planning overkill will help you to identify risks beforehand and avoid making what could be very costly mistakes. Make sure you take the time and prepare – because it is much easier to justify time for risk mitigation steps than it is to explain away mistakes that could have been caught with thorough planning.