Welcome to the second entry in “Device42’s Ultimate Guide to Migration Planning, the Migration Project Plan”. In the series’ first entry, we covered “Readiness Assessment and Creation of the Pre-Migration Plan,” which scoped and began to assess the migration. Subjects covered included ensuring that the migration was viable, identifying and recruiting key leaders and stakeholders, creation of agreeable security restrictions, and configuration management policy creation and enablement. If you are just joining us, reading out of order shouldn’t be a big issue. Be sure to check out our series Roadmap Infographic to help familiarize yourself.
Introduction
In this article, we’ll touch on and expand upon some of the subjects above, while at the same time taking the migration planning discussion into new territory. We’ll begin by discussing the importance of working with Project Planning Staff, and then move on to defining hardware, software, and vendor requirements for the migration. We will then discuss the importance of ensuring monitoring systems are ready to support the migration, and we’ll finish by discussing plans for the legacy data center.
Work with Project Planning Staff
Project Planning staff are going to be key players when it comes to planning from here on out. They are key in acting as the communication liaisons between those on the ground doing the migration work and the business’ management staff who need to know where things stand.
Project planning staff will also have a wealth of standardized templates at their disposal or will be the ones with the know-how to create templates and formal documents for your migration. These documents may include Vendor and Supplier agreements, policy and required security documentation and agreements, change management requests/reports, project progress reports, etc.
Some of these documents may be formalities, but the sign-offs and agreements, make up an important part of the migration plan, and someone has to do it. Thus, it can be seen how it is in everyone’s best interest to work together on the formalities. Depending on the audience, much of them can be just as important as the real work of migrating.
Define the Hardware & Software Requirements
To define your hardware and software requirements, you’ll need to create a list of relevant questions to ask yourself:
– How many racks will the new location require, and how densely will each be filled?
– Do we plan to leave room for future growth, or is the purpose of this migration consolidation – and thus the ultimate goal a move into a smaller facility?
– Will rack density be increased, or will it stay as-is? What about wiring?
– What machines will the team use while the migration is in progress?
– Conversely, what hardware will serve the customers during execution of the migration, is there enough capacity, and what, if any software will be necessary?
– Will software licenses transfer, or will they have to be purchased anew?
– How many and of what software and Operating Systems?
To accurately answer these migration project planning questions, you must first have an accurate record of all of the details about your physical, virtual, and cloud servers, their supporting network components, the software and services they all support, and how all of this is interconnected.
Under-ordering on any of these fronts can be disastrous. Too few licenses could halt the migration or risk the possibility of unlicensed software going into production, putting your company at risk of fines. Similarly, over licensing can cause budgetary bloat. The same logic applies to hardware, and though it seems obvious, it still needs to all be figured out, accounted for, added, subtracted, totaled, and purchased.
Nobody wants to be the one to count wrong, so ensure your CMDB is up to date. Ensure that this critical software will still be live during the migration. The same goes for ITSM trouble and ticketing systems, change management tracking systems, monitoring systems, and of course the project’s planning and tracking software, too.
If your organization is in the software development business, don’t forget about duplicate environments like Test or QA. To repeat:
[ctt template=”11″ link=”2EdaB” via=”yes” ]For the migration to succeed, you must have an accurate record containing ALL of the details about your physical, virtual, and cloud servers, their supporting network components, the software and services they all support, and how all of this is interconnected![/ctt]
Identify Vendors that fit Your Needs
This stage of planning is a great time to ensure vendors that are supplying servers and software will be available to meet your demands in the quantities and at the times required. It’s also a great time to determine and plan for any external expertise that may be required. For example, if part of the migration involves moving to a new type of storage, such as a SAN technology that no staff member has direct experience on, this is the time to locate and earmark a vendor that can supply the necessary expertise to assist with the project.
When scheduling and or creating 3rd party vendor or supplier agreements, nothing can be left to chance. Everything needs to be clearly negotiated, properly scoped and planned, and agreed upon in writing beforehand. Lean on and work with Project Planners to make these arrangements. For example, cabling contractors must know that they’re expected to make all terminations on both ends, and they may not run cables if the patch panels aren’t yet there. Likewise, networking vendors need to know exactly how much they’re going to be expected to do. Will they just be supplying the access points, or will they be connecting them to the cable drops, or will the cabling contractors handle both those tasks, while the network contractors handle only the configuration?
Security agreements that were discussed in step one need to be formalized. Project management staff can supply the proper documentation and arrange clearances that will allow vendors access to the tools, access, and credentials they will need to do their specific tasks.
Designate and Assess The Central Location That All Documentation Will Be Kept
In Phase 1, we talked about creating a configuration management policy and ensuring the appropriate software exists to enable it. At this point, that software should be designated as the central location that all documentation will be kept. The Configuration Management Database, or CMDB, will act as your infrastructure’s single source of truth.
Vendors that will be utilized, the hardware details from makes to models to serials to rack positions and cables they’re plugged into. All credentials that will be necessary and all credentials that are newly generated should be stored in your CMDB. Those who need access need to ensure they have it or that it’s been requested, and it needs to be checked and double checked that this access is correctly granted well before the first item is migrated. SLA’s, where appropriate, should be stored within the CMDB, along with maintenance contracts and the like. All critical application and architectural interdependencies should also be clearly highlighted in the system, as well. Application maps and inventories need to be up to date, and all software, services, and their versions recorded within.
The data stored within your CMDB will be key to each phase of the migration. The map of interdependencies that lie within your infrastructure will prove paramount to planning the order of operations in which things can and should be migrated, as well as for creation of a sound back out plan.
Verify Monitoring Systems and Processes
Running a data center operation without monitoring is a disaster waiting to happen. Administrators need a system that is attuned to monitor all business-critical applications and application stacks. There needs to be a way to visually verify that applications are passing health checks before live loads are moved to them. In addition, monitoring tools must verify that performance metrics remain within acceptable values when they receive new loads.
Administrators therefore need a working monitor for every critical component of their migration. This is not only good for regular business, but is critical for visualizing the real-time impact of making each cutover. It’s also a great time to assemble “migration dashboards” that display key metrics that can illustrate the overall health of the systems being migrated at a glance.
Depending on the size of the migration, it’s very possible that there is too much to be shown on a single dash.. Admins can make more than one dashboard, and different dashboards can be displayed for different audiences during different phases of the migration. You obviously don’t care about traffic statistics on the old production database when you’ve made the cut over to the new one, and same goes for traffic to the new web front ends before traffic has been redirected.
The monitoring system is going to play a very large role in ensuring things proceed as planned. Checking it for different key metrics should be part of the plan as each relevant migration step is executed. Do this legwork beforehand to ensure that data is organized and presented in a meaningful way..
Ensure that the monitoring system is working flawlessly, and test, test, and test again. Ensure the right people are getting the right alerts at the right times, both from the new systems and from the old, and be sure to plan to cut over alerting to new systems as part of each step, disabling alerts from old systems as they are migrated.
The last thing anyone needs on migration day is a flood of now-meaningless alerts from a system that has just been decommissioned drowning out a key alert from a brand-new system that has just been brought up. Plan to turn off and disable monitoring on the old servers as the new take their roles.
Plan for the Legacy Data Center and Equipment’s Retirement
There’s more to turning down the old datacenter than just flipping the lights off, turning off the power, and calling it a day.
The data on those old servers, if they haven’t been moved, may be subject to regulation that may include exacting destruction procedures. Ensure that final backups are scheduled to be taken before the systems are turned down and wiped. Also, ensure that those final snapshots are taken, stored, transported, and if required retained in a compliant manner.. Certain data must be destroyed, certain data must be retained for X amount of years, and some of it can go in the trash.
Whether you need a trash can or a physical hard drive shredding truck onsite to bag and tag each drive while providing destruction certificates depends on your industry regulations and the data your organization holds. These details will all affect the cost of your migration, as well as the usefulness of old hardware. If it can be sold, plan to do so, but ensure that buyers are aware of things that may or will be missing, such as the shredded hard disks, before they come to pick up the hardware. These details can mean the difference between offsetting the costs of the migration, and creating another significant expense..
Synopsis
For every migration step that has an unknown, testing is the key. Migrations, like IT departments, are usually understaffed – especially from the eyes of those doing the migrations. This results in long hours and weary eyes, and if left to its own devices, possible bad decisions. That’s why planning for every contingency and testing every unknown is key.. Ensure every piece of necessary hardware and software is accounted for and documented, and has a planned purpose both before, during, and after the migration, and ensure that the monitoring system is up to the task of verifying that these purposes are being fulfilled.
Finally, ensure your CMDB is up to date and that all information about your infrastructure and every change that is and will be made is handled per change management procedures so that all documented statuses, and therefore interdependencies, are always up to date. And of course, don’t forget to plan for the fate of the legacy hardware and software in the old datacenter.
If in doubt, test. If still in doubt, test again! And if all else fails, start over. There will be no do-overs come migration day!
Read more in our third installment of data center migration guide: Migration Prep & Solution Design.
Sources / References:
“Data Center Migration Roadmap Infographic”
“Data Migration Project Checklist: A Template for Effective data migration planning”
“Three steps to a successful data center migration plan”
Editor’s Note: This post was originally published in February 2017 and has been updated for accuracy.
