SharePoint Administration | SharePoint Migration

Understand the SharePoint Migration Schedule

  

 Email Article  

Tweet  

  

When people think schedule, they generally think project timeline -- a work breakdown structure of the business and technical tasks, culminating in a product or service going live. But with your SharePoint migration planning, it is equally important to understand the business drivers behind the migration, not just the technology drivers.

Are there cost implications for maintaining the current hardware, and a migration is going to allow you to reduce your footprint and repurpose or reduce hardware? Is the project schedule based on realistic goals, or arbitrary dates set by a manager who wants to please the board of directors by "launching SharePoint 2010 by end of Q1" regardless of the impacts? Do you have the necessary skill sets on your team to accomplish the work, or service providers (also with the right skill sets) engaged and ready to begin working? All of these issues impact the schedule, but have nothing to do with the technical activity of migration.

There's more to a project schedule that a list of tasks. Understanding the drivers will help you better understand the project priorities, or allow you to negotiate terms with various teams, vendors, and stakeholders when decisions need to be made or risks to be mitigated. To ensure that your project is on-time and meets stakeholder (i.e. management) expectations, the schedule should be defined only after you:

1. Understand and document the "future state" of your SharePoint environment
2. Work with key stakeholders and end users to refine and set priorities
3. Get both bottom-up (end user) and top-down (management) buy-in on the plan

While these sound obvious, it is amazing how many projects get off the ground without following even the simplest of project management best practices.

That's my high-level planning advice, but what about some specific advice? What are some common pitfalls in migration planning? Where do people go wrong? Well, here are some additional -- and much more granular -- activities that you should definitely include in your plans:

• Allocate time to backup your systems before attempting any migration. Most migrations follow Murphy's law -- anything that can go wrong will go wrong (if you don't have a back up).
• Ensure all systems are on the latest services packs. This is not a nice to have. Many of Microsoft's workarounds assume you have done this. Just do it.
• Create a communication plan for your end users and partners to regularly help them understand what is next on the plan and what has been completed, including what is being migrated, and (hopefully) how long it will take to complete the migration. People will tolerate schedule slippage if they know what is happening. Keep people in the know.
• Make time for ample testing. The tendency is to chip away at testing as other aspects of the schedule tighten. Don't do it. This is your last stand to find issues before releasing the new system to the end users. Use testing time for testing.
• Include a lock down period when no servers should be added or moved. Having a baseline for your testing is just common sense. Don't make it any more complicated than it already is.