Data Center Migration Project Plan
So, you want to migrate your data center. You may be asking yourself: “how important is thorough planning, anyways?”
If you ask companies like Samsung and AT&T that lost literal billions as a result of easily preventable data center mistakes, the answer is “very.”
Even if nothing goes wrong, many data center projects also run behind schedule.
We’re your one point of contact for data center services
After all, it’s no small feat to move 350 tons of equipment. The Titan project took 40 people months and that was just for the decommissioning project.
Thankfully, we’ve been around the block a few times to help you avoid some of the problems we’ve seen. In this article we’ll discuss the discovery, decommissioning, and migration process, principles, and steps to follow when formulating your project plan.
The Big Picture
The fact of the matter is, every data center project is going to be different, and so will require a different plan. You may have to migrate half and decommission the rest of the servers. You may need several subcontractors to handle the scale of material. For this reason, this article will not attempt to give you a catch-all project plan, but will instead provide guiding questions and a general framework for building your own data center migration project plan.
Generally, there are a few phases involved:
- Executive level project initiation
- Network discovery and assessment
- Data center decom planning
- Data center migration planning
- Finalized master plan and day of implementation checklist
We will go through each phase in sequence and at the end of the article, we will provide a template and sample checklist for your project plan.
Executive Level Project Initiation
Obviously the decision to migrate a data center has to come from on high at the stakeholder level before it’s handed down to the applicable service manager or project manager.
Everybody knows that buy-in is critical, but in terms of the tangibles:
One of the most common problems with a data center migration is a disconnect between stakeholder expectations and how a migration progresses.
To avoid this, getting a third party estimate for total costs and timetables early on can be invaluable. Additionally, discussing common points of tension to manage expectations can help avoid a lose-lose situation. The last thing anybody wants is to start a gargantuan project that gets cancelled half-way.
Questions to Get Out of the Way
At what point will there actually be deliverables? What if the migration gets delayed, are the stakeholders informed of the unknowns?
Another issue is resources: are any experts or critical team members busy on other projects, leaving only suboptimal human resources for the project?
If you’re migrating to the cloud, which loads need to be maintained in your own hosting center? Do they have delusional fantasies about a perfect lift and shift where every application magically works the exact same in the cloud?
And lastly, do all the decision-makers actually understand what this project is? Never mind the migration project plan itself, but the actual plan’s point.
It sounds like a silly question, but many times the hands-off decision makers conceptualize a migration as just a simple logistical task, if a large scale one.
They also may not understand how the migration translates to a better end-user experience.
For example, automating your infrastructure build and server provisioning can ensure that end-users aren’t disrupted, all without a person touching a thing.
Working through these task-keeping points can help prevent a decision-maker from cancelling the whole project once the going gets rough and wasting everybody’s time.
Some Common Data Center Migration Challenges
Data center migrations present a number of challenges. The sheer volume of things to audit and document over the course of the migration is staggering. Additionally, a data center migration can accelerate the rate of change within an organization.
Most issues within an organization are caused by some kind of change, and so a data center migration can place greater demand on an organization for change mapping and management. As a result of many different teams with various quickly moving parts, communication can be spotty.
Conditions are ideal when boots on the ground, management, and the executives are able to collaborate closely, but this is often challenging for organizations to facilitate.
Steps to a Successful Data Center Migration
Create a Plan
A plan should include:
- A preliminary schedule
- A communication plan
- Roles and responsibilities
- Goals and objectives
- Budget estimate
- Move plans
- Contingencies, disaster recovery
- Discovery and asset validation
- Compliance and regulatory concerns
Identify Scope, Time, and Cost
Depending on app and workload volume, system setups, personnel, and experience, a typical data center migration to the cloud can take anywhere from weeks to a few months in more extreme cases.
A typical timeframe is closer to 1 or 2 months, however. A rough estimate of costs for a physical relocation can be around $5,000-$20,000 per rack. Costs for a physical to virtual migration are not as significant.
Determine Resource Requirements
Most organizations do not have the in-house human resources required to carry out an optimal data center migration. Additionally, IT personnel can be spread thin as it is. This is especially true with InfoSec employees.
This nearly always necessitates contracting a migration company to consult at the very least. In some cases, an internal experienced employee can serve as a proficient project manager, but that role is often outsourced as well.
Once logistics, operations, support, compliance, and other steps are mapped out, it can be easier to identify which tasks will need bolstering from outside resources.
Build a Data Center Migration Checklist
The creation of a data center migration checklist is specific to your organization, so it can be worthwhile to consult a variety of other resources to get a better idea of what the best data center migration checklist would look like for your organization.
Planning Data and Application Migration
There are three basic steps to migrating data:
- Extract the data
- Transform the data
- Load the data
As data grows, it attracts other data to it and becomes more specialized to your environment. As a result, it is helpful to detangle the data, much like a set of tied up cables. For each type of data migration there are different considerations.
Some data migrations only involve moving data between arrays, but others involve applications moving environments. Many of the same principles apply to data and app migrations as with the aforementioned data center migration information, as data migration is itself a step within data center migrations.
Data Migration Pro has a helpful checklist which is oriented towards data migration. NextPathway also has a helpful step by step data migration article.
Planning Hardware Migration
When moving hardware itself, it’s important to take small preventative measures, such as the use of tip guards.
One option that we would not recommend is the use of any professionals or contractors who don’t have experience moving data center hardware.
Components can be damaged easily in transit if not secured properly, and static discharge can damage the circuitry on occasion.
Verify Target Data Center
Data center environments vary considerably. As such, there are a few things worth considering to ensure the new location doesn’t cause issues.
An evaluation of power costs and local conditions such as bodies of water, humidity, and temperature can have significant effects on ongoing operations expenses.
Another critical step is the evaluation of needed infrastructure, or existing infrastructure at the data center / colocation. Your vendor can provide valuable assistance in the process of choosing and verifying the target site.
During this step, networking, server provisioning, application performance, etc will be tested in staging to add another layer of validation.
In post-migration testing, it’s necessary to identify redundancies, database security, integrity of value, format, schema, etc., as well as load/stress tests, and functionality of the environment for both back-end and front-end use.
The data migration testing article above contains very helpful information on this step as well.
Discovery to Avoid Disaster
An important aspect of planning out the migration is knowing what you’re actually migrating in the first place.
Surprisingly, this is a really common issue. As it turns out, keeping track of thousands of servers can be tricky.
Depending on whether or not your network is more flat or more virtualized, the choice of discovery tool can make a big difference.
You’ll also want to do a physical audit of the place. It’s amazing what you can find by just walking around the building.
Once inventory and applications are mapped extensively, you can begin to plan the technical aspects of which applications will map to the cloud and how.
Data Center Decommissioning- Reasons a Checklist Is Helpful
While the data center decommission is not the most tricky part of the migration, it’s still no joke.
Electrical specialists to shut down the behemoth power infrastructure.
ITAD services to buy off and recycle valuable and non-valuable assets respectively, in addition to returning leased equipment by contract deadlines. You also may need subcontractors to teardown and remove the heavy infrastructure like HVACs, chillers, and generators.
For a comprehensive checklist to follow for the decommissioning step of the migration, you can download it here.
Data Center Migration Project Plan
Now to the meat and potatoes of planning your data center migration project plan.
You’ll want to make sure that every relevant party has every other relevant party’s contact information, to start.
Then typically a good chunk of days is blocked out strictly for getting the team together to plan the project out.
The first phase of migration planning should involve the following:
- Data center real estate, power, and cooling needs
- System backups
- Disaster recovery scenarios
- Necessary human resources
- Insurance coverage
- Site access needs for personnel
- Remote access needs
- Spares for equipment malfunctions
- IT hardware logistics vendor and internal point of contact
- Recycling or ITAD services for unneeded hardware
- Service level agreements and leased hardware contract dates, terms
Once that’s all done, you may need a month to double back and plan out the pre-migration prereqs:
- Is the date set for the logistics vendor to move the hardware?
- Are chain of custody, data erasure, and responsible recycling established for disposed assets?
- Are all necessary licenses available
- Have the spare parts been received at the new location?
- Has connectivity been tested across cabling and patch panels?
- Do all system admins have the requisite network info?
- How will the equipment be moved from shipping to receiving dock?
- What moving equipment is available at the new location?
- In what order should hardware be moved?
- Who will install racks, cabling, and set up the infrastructure?
- Has a dry run been done of the moving day?
- Which administrator will check port configurations to ensure equivalence between new and old location?
- Who will power on equipment, and in what order?
- Which team members, consultants, vendors, and supervisors need to review the finalized project plan?
Finalized Master Plan and Implementation
Once you’ve discussed and ironed out time tables for the aforementioned points, a day-of plan is invaluable.
At this point having a pre-determined action and/or escalation list for any foreseeable problem is typical. If there’s an issue, who will notify end-users and with what message?
Is everyone present and online? Are all backups valid and tested?
Has every objective been given to specific team member with time estimates?
Has a disaster dry run been performed?
Once your data center migration project plan has been formalized, it wouldn’t hurt to have another 3rd party migration consultant take a look to ensure that nothing has been left out.
For the big picture:
Migration Best Practices
Aside from the content covered in this article, there are many frequently discussed “best practices” which are quite frankly, common sense. However, some others that are commonly missed are worth discussing as a footnote. These are things that are easy to overlook. For example, the documentation phase is critical, but excessive documentation can overrun the budget and established schedule. If the servers, infrastructure, existing cloud services, and applications have already been mapped fairly rigorously, and recently, then a quality auto discovery tool followed by double-verified physical and data audits will suffice. Failing to adequately prepare the target site for circuitry, power, cooling, etc is another best practice that is easy to miss. Finally, making sure all parties have the right contact information for relevant team members should emergencies come up is absolutely critical.
If you have any questions regarding data center projects, server liquidation, or other IT projects, don’t hesitate to contact us!
Commonly Asked Questions
When Is the Best Time to Migrate?
The best time to start a data center migration is going to depend on what your network dependencies look like. After doing a thorough network analysis, it is more feasible to estimate how long it will take to document and evaluate everything required for the migration process. In terms of literal time of day, it is more safe to begin a data center migration after peak hours when less end users are likely to notice an outage.
What are the different types of data migration?
Data migration can take a few different forms, with the most common being app migrations, database migrations, storage migrations.
- An app migration is the change of application vendor. For example, if your organization switches its entire human resources fleet from G suite to Microsoft Teams, you would be doing an application migration. These migrations are difficult, because the data frameworks between applications are quite different.
- Database migrations are fairly straightforward: if you move your entire database from Google’s Cloud to AWS, that would be a database migration. If you updated your database software to something else, that could also be considered a subtype of database migration.
- Storage migration is the classic “move my actual data from one server to another one.” An easy example would be moving data that has become stale and unimportant onto cold storage archives.
What is a lift and shift?
The “lift and shift” process essentially tries to migrate your workloads/applications exactly as they are onto a different IT environment. The trouble with lift and shift projects is that the cloud is a very different environment from what you might have on-premises, and so the more efficient approach is usually to make a more thorough migration that utilizes the capabilities of the cloud (or whatever other environment you’re migrating to) fully.
How do you do data migration testing?
Testing must be performed before and after the migration. A very broad overview might be:
- Set a scope for all of the data migrating
- Do thorough data mapping (compare legacy vs new in terms of type, interfaces, mandatory fields, etc.)
- Test everything you can think of in the new apps
- You’ll want to test if you would be able to roll things back/ test for backward compatibility
- Make record of your exact data beforehand to make sure none was lost in the transition.
- Migrate apps
- Modify all network facets like ports, hosts, software configs, firewalls, etc.
- Check security, connectivity, stress tolerance, functionalities, updates, field level checks, data mismatches, etc.,
Should I migrate to the cloud?
At this point, the large cloud providers like AWS are so cost-effective compared to having on-premises equipment that outside of specific circumstances, nearly every organization should be migrating largely to the cloud. Even where latency is a large concern, the recent advent of edge computing nodes will change this, and the cloud will provide the best solution in even those use cases.
Have something to add? Let us know your thoughts in the comments below!