Taking The Leap - Managing The Risk of Datacentre Migration

There are a host of strategic reasons to move and migrate Datacentre based services; reducing BAU costs, re-platforming, consolidating DCs after an acquisition, moving to an xAAS approach, implementing a more flexible infrastructure based on containers, separating a business that has been sold off, on-boarding or off-boarding a client (if you are a Provider), improving your resiliency and DR, etc.

All of them, however, require the planning and execution of one of the riskiest of all IT projects; the datacentre migration. Risky because of the high likelihood of something going wrong, and the undoubtedly high impact of that failure.

Stories are rife of datacentre migrations that went catastrophically wrong. What you don’t hear about is how many times a migration was delayed at the last minute, or even cancelled because of the fear of failure. Delayed migration events are very common – causing huge cost overruns and other knock-on consequences.

Causes of Data Centre Migration Risk

Sources of risk come from many directions, including;

• Migration team inexperience – many IT professionals will have never done a major migration, most will not have done one in the last few years (so Cloud/AAS, Containers, DevOps, Docker, etc. will all be new)
• Incomplete understanding of the assets (servers, firewalls, applications, third-party services, etc.) being moved – and their inter-relationships
• Lack of method – a lot of migrations are approached with a plan based on a blank sheet of paper rather than with a tried and trusted process. At best an old migration plan is re-purposed – often the same plan that moved services into the facility 5 to 10 years ago!
• Incomplete project planning – the migration activity plan needs to be complete and detailed, and flexible enough to cope with new assets/relationships being discovered/acquired, unexpected issues, uneven progress, reliance on third-parties, etc.
• Overambitious scope, multiple objectives – whatever the core reason for the migration, it is very tempting to add in additional objectives to a migration project. For example, improving the Firewall, changing a core application, platform, service provider or OS, increased virtualisation, new levels of service availability. If this is not managed carefully, risks become compounded leading to an inextricably confused position where the non-strategic delays the strategic. The simplest form of migration (“lift and shift”) should always be an option!
• Change – because of the length of a typical migration (anywhere from four months to five years), it is inevitable that something will change to impact the project. It can impact just one application, OS or server type, or it can be the whole strategic approach (“we’ve decided to move it all to AWS”)
• Fear of failure – risk-aversion is understandable, but in some organisations the overlapping levels of risk management and governance means that accountability for delay is spread over so many individuals, that one of them is bound to press the big red button labelled “no-go”!
• Ineffective Project and Programme Management – you can get away with a lack of good P&PM practice in some projects, but not in a migration. Stakeholder management, risks/issues, governance, etc. must all be top drawer
• Technical issues – while the more interesting technical areas often get plenty of attention from the technical specialists in the Migration Team, there are certain areas that seem to cause a disproportionate amount of difficulties. In particular; data (ETL, cleansing), legacy application portability, testing (strategy, management, environment provision, execution), firewall rules and perimeter migration, and middleware & tooling in general

Managing Migration Risk

IT Organisations that treat Migrations as adventures inevitably hit problems. These projects require an enhanced level of professionalism and systematic management. The ideal migration project will meet the following criteria;

• Follow a proven method – with more effort invested up front in discovery and planning and less in execution
• Build a complete end-to-end project plan and have the capability to change it – quickly and often! Consider the use of a specialist Migration Management Platform like Xceed Group’s mX that allows you to connect your as-is asset model, with multiple to-be models and standard libraries of migration tasks, multiple to-be models and standard libraries of migration tasks
• Invest in migration experience – knowledge of your environment is essential, but so is understanding of multiple migrations. Be prepared to bring in specialists who do this all the time. Consider multiple approaches and compare multiple plans.
• Use enhanced, better Project Management and Governance – build a project and risk management approach that is fit for purpose (not just more risk-averse.)
  • Nail down the RACI to make decision-making fast, effective and, well, decisive.
  • Prioritise risks properly based on realistic impact assessments – don’t have hundreds in a long list of poorly worded excuses-in-advance.
  • Build a complete stakeholder map, understand what each individual or group needs from the migration and what their possible issues and objections might be.
• Test and rehearse – when the big migration events happen they should have been rehearsed and tested (as well as the reverse-outs) so systematically that the failure probability and impact levels are comfortable