Migrations – What, Why, How? Part 1

One of the mainstays of my role is migration projects. I thought it would be worth doing a post on this to provide some food for thought for anyone contemplating this at the moment or in future.

The What and the Why

So first of all, what does a migration entail and why would you need to do it? Simply put, a migration is the movement of workloads from one place to another. These workloads could be virtual, physical, modern or legacy. In a VMware context, we are familiar with the concept of vMotion and DRS moving workloads within a cluster. For the purposes of this post, we’re thinking about migrating between platforms. There could be a number of reasons why you would need to do this. A data centre exit or consolidation programme is a typical one (data centres are expensive things and consolidating them can make a big impact on the IT and overall budgets of companies). The target could be another owned or leased data centre, or increasingly, it could be in the cloud. Another typical example is migrating from a legacy platform to a new one. In this case, the new platform could be in a different data centre or it could be in the next rack of the same data hall. Depending on the different architectures of the source and target platforms, this could be quite straight-forward or very complex.

A typical platform might have a lifespan of 4 or 5 years. Some companies may opt to build a new platform alongside, directing new workloads towards the new platform and essentially closing the original platform, operating them in parallel on the basis that over time, the workloads on the legacy platform will be decommissioned and/or refreshed onto the new platform with the original eventually dying out. The problem with this approach is that, in reality, the legacy platform will probably still be there when it comes to do this all over again. And operating multiple, disparate platforms has an associated (high) cost. The alternative is going all in and migrating everything off the old platform and decommissioning it entirely. This is the optimal approach from an operating perspective as it means only supporting one, strategic platform which provides all the benefits across the boards such as increased agility, speed, flexibility etc. That said migration projects aren’t exactly cheap and easy either and so making this decision can be difficult and finely balanced and requires proper analysis and a business case. The high (but often hidden) Opex costs associated with running multiple platforms over a prolonged period vs the upfront and more visible Capex costs of running a migration. In my experience, running hybrid or bi-modal operations acts as a drag on innovation.

The How – Planning

Planning is the most important part of any migration. Migrations in 2020 are so much easier than in times gone by as virtualisation has been widely adopted and that additional abstraction layer makes mobility easier than moving from a physical server to a virtual server and the changes to the operating system that entails. But that is only half of the story. Although moving a virtual machine in itself is not difficult, the complexity comes from moving hundreds or thousands or virtual machines which make up applications, and those applications have dependencies on other applications. And so on. Depending on the architecture and physical locality of the source and target, introducing latency (even a tiny amount) can cause havoc. It’s essential therefore, to have a comprehensive plan of what needs to move and when. This may involve a combination of people (talking to application owners etc.) or technology or both.

On the technology side, organisations generally have things like Configuration Management Databases’s (with varying degrees of quality). There’s also things like RVTools and vROps but unless you’re lucky those things aren’t going to help with real application dependencies because in the real world, these things are generally poorly documented and critical applications can evolve over time. vRealize Network Insight can be really useful here because it can analyse actual network traffic flows between servers as well as port usage to build up a mapping of communications and dependencies. The end goal is to break up the big bucket of workloads into smaller buckets consisting of one or more applications into suitably smaller buckets which can be moved at the same time.

These can then be added to a schedule which allows resourcing to be planned, change windows to be secured and all stakeholders to agree the plan which can then be tracked and reported upon back to management. The risks and impact of issues and mistakes is extremely high and confidence in the project can easily be compromised. It’s crucial therefore to ensure that the analysis and planning is watertight.

I’ll cover more of the how (specifically execution) in my next post.

Advertisement