This is the first entry in our “Guide to Creating a Migration Plan” series. If you didn’t see the series Roadmap Infographic, do check it out. The prequel to this series, “Top 20 Data Center Migration Mistakes to Avoid” is a list of twenty mistakes that can grind a migration to a halt, and is definitely worth checking out as well.
The data center is evolving by the day. Meanwhile, there is a growing emphasis on efficiency and a push for ever more autonomy. The last decade’s data center designs are being replaced by self-healing, fault tolerant versions. The need for operational efficiency gains is the primary driver of migrations.
Since this guide has no way of knowing exactly what you, the reader, are planning to migrate, in no way expect this guide to serve as a migration-ready plan. Rather, this guide provides tips that can guide you through the steps to create a migration plan.
Part one of this guide (this post) discusses the following preparation steps:
- Determining the scope of the migration
- Ensuring the migration is viable
- Identifying and recruiting key business stakeholders (and IT leaders)
- Creating of agreeable security restrictions
- Creating or reviewing configuration management policy and ensuring appropriate software exists to support it
There are many reasons to migrate to another data center. Before setting out, it’s worth considering the pitfalls. Dramatically changing how things are done as part of the move may add both technical and operational complexity that, if not carefully thought out, can at best cause the migration to fall behind schedule, and at worst, to fail entirely as downtime and costs spiral out of control.
Scope therefore must be agreed upon and “locked in” before project initiation, and scope creep must be avoided. Right now, US and European companies are running about 20 percent behind the curve in terms of pursuing digital opportunities. These delays might be due to fear of downtime, fear of scope creep, fear of failure, and a for a multitude of other reasons. A well-defined scope ensures that many of these fears are quashed.
Ensuring the Migration Is Viable
Now that scope is agreed upon, the viability can be scrutinized. Performing a Migration Readiness Assessment (MRA) will help provide clear answers to the viability of your specific migration as scoped.
The questions to answer in preparation for the next stage of planning are:
- Does the organization have the staff and expertise on hand to accomplish the migration with in-house talent, or will outsourcing be required?
- What is the available budget for the migration as planned?
- What impacts will the migration have to the running of the business? If it cannot tolerate any impact, can the migration be accomplished without direct impact to business?
A successful MRA will both give provide preliminary answers to the above questions. The MRA also functions as a small-scale simulation of the larger move and can help estimate both timeframes and cost. The Readiness Assessment can be accomplished well before any new hardware is chosen or purchased, as it works with an ‘idealized’ target. The end results are a better understanding of the intricacies of the migration.
Identify and Recruit Key Business Stakeholders and IT Leaders
The next pre-migration planning step is the identification and recruitment of both key players and large stakeholders. Make sure all understand the business goals of the migration, both short term and long term.
Using information gained from the MRA, preliminary decisions should be made at this point on outsourcing vs. hiring. Both options have upsides and downsides: Outsourcing is not a bad solution, and some amount will likely be necessary, where in other cases it may be ideal. If possible, having in-house staff handle most of the migration keeps the critical details of the project under your roof. This option may be more expensive in the short term, but the option will often provide overall value and competitive advantage in the mid-term and long-term.
It must be stressed that budgetary overrun can happen with any large project, but at this stage this should be accounted for by some combination of over-estimating and limiting spend to ensure some budget reserve. The expertise of the finance department can be leveraged to help formulate guidelines. Information gathered during your MRA should prove helpful as well.
The next important consideration when recruiting key stakeholders and leaders is to remember that their availability must be planned as well.. As the project moves forward and grows, so too will its resource requirements.
Lastly, the planning of resource requirements and availability requires an accurate description of the responsibilities to be filled and the specific tasks that need be accomplished [and in which order] to facilitate resource assignments. At this point, a rough map of tasks and deliverables that takes dependencies into account need be assembled.
Agree upon security restrictions
Security restrictions cannot be simply discussed and forgotten about. Output of this step should be formal written agreements reviewed and signed by the relevant security governance groups, and these agreements will guide procedure throughout the entire life of the project. A migration can’t be performed without making the security governance organizations aware of what is about to happen, and methodologies cannot be used to move hardware, software, and customer data that don’t fall within the realm of the agreements.
Much to do with security may seem common sense, so much so that many of the risks lie in its apparent simplicity. When, for example, the contents of large mission-critical databases must finally be migrated to a new location,it might seem simplest to copy the database to a hard disk and have an engineer transport it to the new site. If this is customer data containing social security numbers, medical records, credit card numbers, or one of many other types of sensitive data, however, then this is a disaster waiting to happen – and could actually be illegal.
Is that engineer an employee, or a contractor? Is the vehicle company owned or private, and is the cost of transportation being compensated? These are the small yet important details that could easily be overlooked, rules for which have been established by regulations and standards such as HIPPA, FISMA, PCI DSS, SOX, NERC, NIST, and many others that may apply to your migration.
Configuration Management Policy
A formal configuration management policy must be adhered to. The policy should be consistent with industry best practices associated with Information and Security management, and should highlight the sources for the principles that have been established. The policy should address purpose, scope, roles & responsibilities, and managerial commitments. The policy will also dictate documentation procedure, including who documents, what is to be documented, and where the documentation is to be stored. The same policy should also address policy for change management and control and other relevant changes to Information Systems.
A secondary part but critical aspect of the configuration management policy is the determination of the existing or proposed Configuration Management System’s suitability to perform and scale to handle required tasks. Quality configuration management software will play a critical role in organizing and making sense of the piles of data a migration generates. The new or existing piece of configuration management software (likely an Enterprise CMDB, like Device42) should be evaluated to answer these questions (a task that may warrant a sub-project in and of itself).
Project initiation day isn’t the day to be stumbling about, testing different approaches to get things working between your configuration management software and procedures. By then, it should be a well-rehearsed exercise, its usage and the orders of operations known by heart.
Tune back in for the next edition in Device42’s Ultimate Guide to Migrations: Project Planning, which will cover everything from involving project planners to vendor identification to deciding the fate of the old data center and its contents. Until then, do leave any questions, comments, or requests below!
Read more in our second installment of data center migration guide: Guide to Migration Planning, Part 2: Migration Project Plan.
Sources / References:
“Assessing Data Migration Readiness, Part 1: The Right Way to Begin”
“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.