Update: Device42’s Ultimate Guide to Migration Project Planning, Part 3: Migration Prep and Solution Design, can be found here!
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 aforementioned subjects, 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 and software requirements for the migration. We’ll talk about identifying vendors that fit defined needs and designating a central location to keep migration related documentation. 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.
When all’s said and done, you’ll be just about ready to move onto the third planning phase – “Migration Prep & Solution Design”. But until then, there’s a lot of work to do!
Work With Project Planning Staff
Project Planning staff are going to be key players when it comes to planning from here on out. It’s never too early to involve your Project Planners, but waiting too long can result in major setbacks. Project Planning staff’s roles are many, but 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 formalize how stakeholders will be informed and communicated with. This means formalizing a communication plan for each person on the list you made during migration project planning Part 1: Identifying and Recruiting Key Leaders and Stakeholders.
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. Project Planning staff will create and distribute these documents as Vendor and Supplier agreements, policy and required security documentation and agreements, and of course, knows and can deliver the reports and documents management requires: change management requests/reports, project progress reports, etc.
From an external perspective, much of what project management does can feel like formalities, and the truth of the matter is that some of it absolutely is. However, the sign-offs, the agreements, and the countless other formalities make up an important part of the migration plan, and someone has to do it. Those someones will be your project management staff. Working closely with them will ensure things move smoothly and stay on schedule, and most importantly, if something isn’t going to plan, they’ll be the ones asked to explain why. 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, the answers to which will lay the foundation for your plan. Important questions to ask yourself when planning for your migration are:
– How many racks will the new location require, and how dense 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, or worse yet a failure. 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, otherwise communicate and plan for the time needed to make it so. Ensure that critical pieces of software that will be depended on for information DURING the migration aren’t being moved at a time when they’ll be needed, making sure they’re hosted somewhere unaffected. Otherwise, make sure that the plan includes moving that software! The same goes for ITSM trouble and ticketing systems, change management tracking systems, your CMDB, 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. They can be easy to overlook when you spend all day working only in production, but that’s no excuse for lack of planning. It was mentioned before, but it’s so important it must be emphasized: 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!
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!
Identify Vendors that fit the 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, to determine and schedule resource availability, and to ensure budget for the cost of their assistance.
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?
In these details lies both the potential for a lot of confusion and setbacks or a flawless, perfectly executed migration. Careful planning here can make the difference between and migration that goes executes so smoothly, staff even gets to sleep post-migration night (lets be real here; does anyone sleep the night of?) – or embarrassment and utter failure.
Security agreements that were preliminarily discussed in step one need to be formalized and 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.
While we’re on the subject of credentials, where will things like contractor and newly generated credentials be stored? This brings us onto the topic of a designated, central documentation location, AKA your CMDB…
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. That means 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”, and anything related to the infrastructure as it stands and as it will stand should be stored within.
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 softwares, 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. This data will also be the only way to prove to the business stakeholders that the plan considers all risks and mitigates for them in such a way that downtime risk to the business is minimized, ensuring the acceptance and ultimate success of the migration plan.
Verify Monitoring Systems and Processes
Running a data center operation, small or large, without monitoring is a disaster waiting to happen. So too is attempting to migration without a monitoring 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, and when new loads are moved to them that load levels and performance metrics are within, and remain within acceptable values.
It must be therefore ensured that a working monitor exists for every critical component of your migration. This is not only good for regular business, but is critical to visualizing the real-time impact (or hopefully, lack thereof) of making each cutover, and 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; that’s ok. More than one dashboard can be created, 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, as well as all of the servers, both virtual and physical, networking equipment, and even power equipment that drives it all.
The monitoring system is going to play a very large role in ensuring things proceed as planned, and checking it for different key metrics should be part of the plan as each relevant migration step is executed. Doing this legwork beforehand to ensure that data is organized and presented in a meaningful way, and is correct will be very important to the success of the migration.
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, and with that said, we’re on to the last part of planning Phase 2… What to do with all that old hardware.
Plan for the Legacy Data Center and Equipment’s Retirement
This sounds obvious. It always does, just like verifying power redundancy before powering off a UPS, but we’ve all accidentally unplugged a server… There’s more to turning down the old datacenter than just flipping the lights off, turning off the power, and calling it a day.
Depending on your industry, the data on those old servers, if they haven’t been moved, may be subject to regulation that is anything from strong suggestions to exacting destruction procedures. Ensure if final backups need to be taken, that they are scheduled to be taken and they are of course scheduled for a time before the systems are turned down and wiped. Also, ensure that those final snapshots are taken, stored, transported, and if required retained in a way that is within the regulations and the laws that the data is subject to. 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 for each completely 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 collecting a hefty sum that offsets the costs of the migration, or of another substantial write-off for the company.
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.
However, even perfect planning cannot remedy poor execution. There is no shame in testing something more than once or in practicing something that has never been done before to ensure process correctness or that a plan as written is technically feasible.
There is also no shame in admitting that you or your department does not internally possess a given skillset and bringing in outside help. It is, as a matter of fact, much more embarrassing to keep quiet about these things until they possibly cause an issue on migration day.
Everyone isn’t expected to know everything, and that is why we test, we monitor, and we plan. However, not knowing something isn’t an excuse for not testing it, monitoring it, or planning for it, as in the eyes of the business, downtime is downtime no matter what the reason. Make sure project planning staff are informed of any snafu, and work with them to identify vendors that can be called in fill technical debts. 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 regulations allow, and if thought through carefully, the businesses used “junk” can be sold and can possibly recoup a healthy amount of capital, while granting the hardware and software a second life.
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!
Join us for our third entry in Device42’s Ultimate Guide to Migration Planning: “Migration Prep & Solution Design”. In our third entry, we’ll cover everything from the importance of a detailed assessment of your current data center to backout plans to mapping application dependencies, pre-migration testing, backout plans, and more. Until then, please leave any questions, comments, general thoughts, or even a friendly hello in the comments below. We really do enjoy hearing from each and every one of you.
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”
