In Part 1, we discussed taking inventory. Now that we have our inventory, it is time to plan our Windows Server 2003 migration. The planning phase is very critical. This is where you are going to make major decisions that will affect your infrastructure going forward. We could do a straightforward migration going server to server or we could use this opportunity to make needed or desired changes to the infrastructure. Moving from Windows Server 2003 will make news technologies and advancements available. You do not have to create a plan from scratch. There are a number of tools we can use. For instance, Microsoft has the Assessment and Planning Toolkit. The web is full of helpful tools that you will have to log onto. Also, open your favorite browser and search engine to find what you need (say, a blog like this).
For our planning phase, we need to factor in the following:
- Inventory – We took an inventory of our infrastructure in Part 1. We now need to assess that inventory.
- Budget – How much we can spend determines what we can do to perform the migration. If we can afford to put up a new virtual environment or build on an existing virtual environment, then we virtualize. If we can only afford to utilize the hardware we have, then this is a rolling migration.
- Man-power – The experienced resources available to work on this project and how much of their time they can allocate/dedicate.
- Timeline – Given how long we have to complete this task, we can determine what we can accomplish.
- Infrastructure and environment – The condition of our infrastructure and the environmental resources may require modifications to accomplish this project. If you are adding new servers, you may need new racks, more space, more cooling, and more power.
- Symmetrical Projects – Those projects we can get done in conjunction with this project (i.e. virtualization) or those projects going on that could be impacted by our migration project.
Given the factors above, here are the general tasks in creating your plan:
- Determine the project manager. Make sure you have someone who is dedicated to seeing this project through and can coordinate the plan.
- Put the inventory into categories that make sense to your team and then prioritize the categories. The inventory facilitates our assessment of what we have.
- Given the assessment and factors listed above, we can determine our needs, tasks, and what we can feasibly accomplish.
- Determine the goals:
- Are we migrating everything?
- What are we migrating within our deadline? What can be migrated at a later time?
- Are we trying to migrate and utilize the existing hardware or are we moving to new hardware?
- Where will the supported applications reside?
- New physical server?
- Moving to cloud services?
- Determine your timing – Take your priorities and determine what can be accomplished within the allotted time frame and what needs to be done at a later time.
- Map out the target destinations for the items you are migrating (i.e.virtualize, move to the cloud, upgrade, decommission, etc.)
- Given the priority and desired outcome, determine how much time each task needs. Where possible, leave time for the unexpected. Try not to make your timeframes to tight. (Don’t read this out loud: If you want, use the Engineer Scott method. Give a time frame you know you can beat so you look good.)
- Map your resources to your task. Determine the best available candidate(s) for each task.
- Develop your timeline. Take the information and priorities you have gathered and map the tasks with a start date and time, duration, and an expected end date.
- Include allowances for acquiring new resources. For instance, that SAN you ordered for the virtual environment may take three weeks to deliver. Use other tasks to fill the gaps where you are on hold. Even if they are a lower priority.
- Include research time for each task. It does not hurt to admit that there are tasks your people are not sure how to accomplish. I would not want someone to try and migrate my DHCP from server 2003 to server 2012 without having experience or at least proper instructions. Within the planning documentation, note where to find the instruction sets.
- Don’t oversaturate a resource. We all have environments where certain people will wind up being the subject matter expert for multiple tasks.
- Document everything.
I know that I have greatly simplified the information listed above. The goals of the blogs in this series are to get you thinking, give you a general outline, and help keep you moving. I cannot stress enough that you need to be very detailed with your resulting planning. Your plan is what will be visible to your team and your management. You will most likely be held to the plan you publish. Proper planning will take out guesswork, cut down on surprises, help you handle the unexpected, and keep things running smoother.
In the next blog for this topic, we will look into our next step: ‘Build and Test.’
Craig R. Kalty (CCIA, CCEE, CCA, MCITP:EA, MCITP:SA, VCP)|
Sr. Network Consultant
©2015 Custom Systems Corporation