Data centre (DC) migrations can mean several things depending on the size and scope of the task. It can range from being as small as moving one application offsite, or to the cloud or as complicated as ripping out an entire facility and moving it to the other side of the country.
It can also encompass consolidation activities or the upgrading of applications and infrastructure.
Whatever the scope, security and networking remain the common challenges and are fraught with the same pitfalls.
Here are ten pitfalls to look out for when undertaking a data centre migration.
1. Knowledge is stored in different people’s brains
This is true for nearly any major technology project, but it really comes to light when it comes to the DC. Not only is the knowledge of the overall workings of the DC stored in silo's - it's impossible to know WHO has the relevant pieces of knowledge.
This often leads to certain aspects being missed out, with the impact not being realised until business processes and applications are impacted.
2. Thinking firewalls will solve everything
Many companies seem to hold on to the belief that there is no security problem that can't be solved by throwing more firewalls at the problem.
In the short term, it may seem like the easy option, rather than working out network routes for new applications, one can simply deploy a firewall, stick a custom rule on it and call it a day. An activity which is about as effective as applying some water sealant to a leaky dam.
3. No network diagram
One of the most basic and common traps many large enterprises fall into is not having an up-to-date network diagram.
Any diagram that is available is usually incomplete. Or was designed by a contractor that has since left the company and took the knowledge with them (refer to point 1).
4. Nobody has an idea of what normal looks like
When designing the future state of a DC, many assumptions are made and caveats put in place. Very rarely do these assumptions go through any validation process. Thus, there is no actual analysis of production traffic and/or volumes. Without knowing what normal traffic looks like, it’s almost impossible to predict what the future-state traffic will look like. This could render the target model inadequate for it's purpose.
5. False economies
Financial forecasts and projections can be inaccurate due to false assumptions. Thus, a DC migration that should be cost neutral in 12 months, ends up costing more than had the old system remained in place.
6. No visibility into application connectivity
All too often in DC migrations priority is given to networking at the expense of understanding the applications themselves. Not all applications communicate over standard ports and application dependencies may be deeper than assumed. Not having this information will often lead to applications breaking and a long and tedious process of fault-finding. Points 1, 3, and 4 contribute to this.
7. Insufficient change management
Having a well-defined, mature, and effective change management system in place can help eliminate many of the challenges and issues relating to a DC migration. Unfortunately, well-defined, mature, and effective change management systems are overlooked during major projects which tend to conduct many changes under an umbrella change record.
8. No rollback capabilities
In any project, there is always the risk that things will not always go per plan. Having things go wrong is part and parcel of a major project like a DC migration. In preparation for this, rollback capabilities need to be considered well in advance of any migration. Trying to create a rollback plan whilst rolling back is a surefire recipe for disaster.
9. Lack of assurance
Once the DC migration has been completed, responsibility for assuring the target system that has been delivered is working as expected is often overlooked. Whilst the applications may appear to be working, as per 4, is the traffic normal? Are the connections legitimate? Are any unnecessary ports open or do stray firewall rules allow remote access?
Not validating the security after a migration can lead to issues that are not immediately apparent but have a major impact in the long term.
10. Knowledge in different people’s brains
Assuming the migration is successful and everything goes to plan, it's worth remembering not to repeat the same mistakes in the future and to ensure all knowledge of the new environment is properly documented in the right places.
While these are the common pitfalls to most DC migration projects, it need not be all doom and gloom. With a little preparation and awareness of risks, one can eliminate a lot of the major reasons projects run into issues.
Four steps to bear in mind before, during, and after a DC migration would be:
1. Understand what current state is: Lots of times stuff breaks or stops working unexpectedly when you make changes. Identify the networking components, firewall rules, routing tables, protocols and so on.
2. Define what target state is: What does the complete future state look like? What changes are part of it? How should it differ from existing state in both operation and cost?
3. Make the move: Implement, have a fall back plan, and ensure proper change management oversight.
4. Assure the changes: Validate all changes were done properly.
