With organizations spending over a quarter of their IT budget on Data Centre (DC) expenditures, according to IDC, a DC can easily become a major cost center. As CIOs look to reduce budgets, the reality is that organizations can’t afford not to evaluate their DC layout. This often means consolidating multiple DCs into a more efficient configuration or relocating disparate DCs to a more cost-effective location. Or both.
Migrating business-critical services and the server estates is one of the most potentially disruptive changes you can make to your IT estate. Even when the move itself goes smoothly, the CIO will still need to quickly demonstrate measurable improvements to justify the arduous process.
DC migrations shouldn’t be scary. Certainly they are difficult and time-intensive, but if you are seriously concerned about the consequences of a migration project then it is likely that you are not yet ready and you need to finish the planning process. The old military maxim applies here too: “No plan survives contact with the enemy”, and DC migrations invariably require more time and resources than originally anticipated.
Taking an Intelligent Migration approach to DC transformation will ensure the project succeeds at the first attempt. Here are my four key takeaways:
1. Don’t rely on guesswork
One of the most disastrous mistakes organizations make is overestimating their knowledge of their IT infrastructure and the applications and services that it supports. Worryingly, this is also one of the most common assumptions. There’s no disputing that new technologies and staff churn make it difficult to retain historical DC knowledge.
Despite everyone’s best efforts at documentation and debriefing, as staff retrain or leave, they take useful knowledge with them. Even if documentation does exist it can be poor quality and inconsistent: for example, developers failing to document a change of policy to re-index on a nightly basis following the new release of an application. Taking this approach will result in a botched migration and the lack of a single version of the truth data-wise.
The answer is to plan meticulously. Build in enough time to do the initial mapping and discovery phases properly as this will save time and money in the long term.
2. Don’t bite off more than you can chew
It is tempting to view a DC migration project as part of a larger upgrade program and implement other major changes at the same time. Whilst this might save time and money on paper, in practice it increases the chances that one project will fail and bring the rest crashing down with it. When multiple projects are a must, you should consider a sequential implementation and ensure there is enough time for the migration.
Similarly, a common mistake is setting unrealistic targets and completion schedules and proceeding without understanding the implications of the timescales. This might start with a statement such as “the lease expires in three months so we have to be in the new DC by then”. For a small company with 10-50 servers this may not be a problem, but for larger estates it will take a lot longer than three months. Complexity also impacts the timescales. When the same 10-50 servers are subject to inflexible SLAs for a 24x7 revenue-generating web site, balancing service delivery with migration deadlines can result in significant conflict.
Even with a sensible migration plan, it is important to provision adequate manpower to ensure deadlines are not missed and employees aren’t over-stretched. Assuming that IT support and operational staff can resource the migration while continuing their normal duties will inevitably lead to a drop in quality for both activities.
3. Be sure to get broad buy-in
Managing user expectations needs to be part of the migration strategy from the start. By securing involvement and resourcing from the affected business and IT communities as early as possible, the migration becomes collaborative. This will help align the new DC’s capabilities to the needs of the business, smoothing the transition period and supporting measurable Return on Investment (ROI).
The sheer technical complexity posed by DC migrations leaves little room for dispute or deliberation. Advocating a holistic, rather than a siloed, approach will help with attaining unanimous buy-in across the organization. Any objections must be addressed and resolved early to prevent them from slowing or damaging the implementation. The scale of DC migrations demands a decisive, unanimous force to maintain momentum through to completion.
4. Don’t assume Business As Usual (BAU) procedures will apply
Effective governance of day-to-day DC activity is critical to deliver timely, reliable and secure services. However, we have found that even the best client and service provider BAU processes are unable to deal with the volume or speed of changes that are required to support a DC migration.
Change management processes at both the client and the service provider side are designed to limit access, move and decommission activity in the DC. Normally such level 1 or level 2 changes operate under the strictest of change management controls such as multiple Change Approval Boards, resulting in extensive lead times even before migration dates can be confirmed.
A DC migration cannot be viewed as lots of small changes: migrations, upgrades or decommissions. Instead, it has to be planned, approved and actioned using an agreed number of devices and within a set period of time, known as a wave process. The wave has to be agreed at senior business owner level and the changes, although highly disruptive, will have to be lower than usual at a level 3 status to avoid overloading the BAU change management processes or delaying change approval SLAs on both the client and service provider side.
Similarly, request management processes are designed to operate as BAU for the provisioning of new equipment or access to systems and cope with major project demands. Nonetheless, we have seen DC migrations that absolutely swamp the request management process and even bring it to a standstill.
The way to minimize this is to group requests into waves, and secure approvals well in advance. Then, when the time comes to update the associated configuration management databases, details about the affected configuration items can be managed as bulk updates to an agreed schedule, rather than as labor-intensive individual requests.
However much you plan, even the best migration strategies will face unprecedented complications. To help mitigate the risks we advocate a pragmatic approach called Intelligent Migration. This ensures thorough initial groundwork and discovery, allowing organization to remain flexible in the face of disruption and make quick, informed decisions to overcome obstacles. Then the CIO can feel confident they will be able to meet the needs of an evolving business.
Bill Broadley is principal consultant at ECS, a British company that designs, builds and operates IT infrastructure.