In my role as a Technical Consultant at Rackspace, I spend most of my time helping customers migrate their applications and workloads between a range of different platforms and environments. In my time at Rackspace, I’ve worked across a range of different sectors, geographies and technologies, and have also worked with customers at different ends of the modernisation spectrum. From extreme legacy customers on end-of-life hardware & software, through to cutting-edge customers utilising the latest technologies to deliver at scale.
Nowadays, the vast majority of the migration projects that I work on are migrations to cloud. Be that AWS, Azure, GCP, or one of the many other cloud providers. When speaking to organisations that are at the very beginning of their migration journeys, there’s one topic of conversation that almost always arises – image based migrations.
The image-based migration
Image based migrations, also known as V2V (virtual to virtual) or V2C (virtual to cloud) migrations refer to the practice of migrating applications between environments by copying the underlying virtual machines that an application runs on to a new environment. There are a huge range of tools available from various vendors to perform these types of migrations, including some native tools provided directly by cloud providers.
Image based migrations are nothing new and have been around in traditional data centre environments for years. As a result, there is no shortage of organisations that view their migration projects as purely infrastructure-based exercises. This infrastructure focused-lens often leads to organisations immediately setting their sights on an image-based migration, without considering any other approaches.
But settling on a bulk migration approach for all applications upfront can be dangerous and viewing migrations as purely an infrastructure-based exercise significantly reduces the chances of a successful project.
In reality, its critical to adopt a structured approach that puts the applications front and centre. The importance of understanding and choosing the right migration approach for every business application simply can’t be ignored.
Determining the appropriate migration approach for each application
When performing any migration, one of the key measures of success is whether or not the application being migrated functions in its new environment. If the application does not function and continue to deliver the business value that it did in the source environment, then the migration cannot be considered a success.
With this in mind, it seems only logical that any migration project should first start with a thorough assessment of every application that’s in-scope. This assessment needs to cover the application in its entirety, to fully understand the impact of moving it to a new environment. This is an essential precursor to being able to successfully plan a migration event. A migration should never be viewed as the movement of some compute and some data. In reality it is the migration of an entire business service that not only needs to move, but it also needs to function in its new home.
It is therefore important that when assessing applications ahead of a migration, you not only cover the typical elements such as how to migrate the applications code and data, but also consider the ecosystem that the application is plumbed into and how that is impacted by a move. That’s both technical considerations, such as application interfaces, batch schedules, user access methods, route to live processes, and also business factors such as peak periods, RPO’s, RTO’s and maintenance windows.
To get to this level of detail, it’s critical that the right stakeholders are involved in these discussions. Typically, I work closely with application business and technical owners, so that I’m able to get a full view of the application from not only a technical perspective, but also to understand the business value it provides and the constraints that need to be adhered to for any move.
As a result of performing this application-centric assessment, you’re left with a detailed picture of each application and can then best decide how to move it. Instead of focusing on migrating 3 Servers (APPSVR01, APPSVR02 and APPSVR03), you’re now focusing on moving a customer billing system responsible for taking payments that make up 100% of a business’ revenue. By approaching migrations application-first, you shift your focus to successfully moving each application rather than just getting its underlying infrastructure to a new environment.
Using the billing system as an example, during the application assessment you may find that due to the business critical nature of the system, it has a huge rate of data change, and can only have an hour of planned downtime for any migration. This may rule out performing an image-based migration, and lead to you taking a greenfield approach whereby you provision new servers, re-install the application, and implement data-replication to minimise downtime during a cutover event.
An application-based migration approach is critical for the success of any migration.
Why image-based migrations are not always best
To expand on what I said above, if someone asked me to define the term migration, I would define it as the successful movement of service from one environment to another. It should be as transparent to the end-user as possible, and when in the target environment the application should function as it did in source (albeit with any performance improvements or desired tweaks).
Within any migration there are a range of steps, one of which is often the movement or transfer of data. Be that an entire virtual machine, a database, or data from a local filesystem. The transfer of data is just one step of many and goes hand in hand with other equally as critical steps such as batch suspension, source shutdown, interface reconfiguration, testing, source start-up, and so on.
Image migrations are often seen as the “silver bullet” to migration projects of any scale or complexity. Partly due to the huge marketing budgets of tooling vendors. In reality, image migration tools are just an execution vehicle to move blocks of data from one place to the other. They’re application unaware and are never an end to end solution for successfully migrating applications and service. They don’t remove the need to thoroughly assess applications to understand the steps involved in moving them to a new environment.
Image migration tools are often not the best execution vehicle for moving applications at all. When I am working with customers, I typically advise customers to avoid performing image-based migrations (particularly “V2C” cloud-based image migrations) unless a very specific set of criteria are met, and this is for good reason.
Image based migrations come with a lot of disadvantages and challenges, that can limit the benefit you’re able to get out of a migration to a new environment. They can also make your migration to a new environment more challenging and riskier.
3 key examples of the challenges I see with image-based migrations are as follows:
- Reduced ability to transform: When performing an image-based migration, you lose any ability to transform or optimise your application for its new environment. Applications must be taken “as-is” because you’re copying the underlying Virtual Machines to the new environment. In doing so, you are also copying any issues from the source environment to the new environment in the process. The benefits of cloud in particular are best leveraged when applications are optimised to take advantage of cloud ways of working. And adopting technologies such as PaaS and auto-scaling.
- Increased Risk: Greenfield (or new build) migrations are inherently less risky than performing image-based migrations. By provisioning new infrastructure and re-installing your applications in your new environment, you’re able to thoroughly test your applications in an isolated environment, away from the source application. This gives you a much higher level of confidence when beginning a migration and reduces the number of moving parts during the migration event significantly. When you perform an image-based migration, migration events become much riskier.
- Increased Cost & Timescales: While there are many tools available to perform image-based migrations, it is important to remember that they’re just “execution vehicles” to get an image from one place to the other. They don’t remove the need to perform detailed application assessments and planning. When performing an image-based migration you also need to factor in the time required to implement and configure migration tooling, and the associated licencing costs.Migration tools often require significant remediation post-deployment, which is typically a customer responsibility, receiving little help from the vendor. Firewall rules, agent installation, and OS tweaks are just a few examples of remediation that is often required. All of this can make image-based migrations significantly more time consuming than a greenfield approach.
Clearly there will always be some applications where an image migration may be the best approach, for example legacy applications where the installation media no longer exists that need to move short term before being retired.
But to conclude and to reiterate the general theme, it is vital to approach any migration project in an application centric fashion. Start by fully understanding each application that needs to move to a new environment, and then decide on the best way to move it.
Avoid settling on bulk migration approaches from the offset and be careful not to fall victim to some of the marketing in the wild. There really is no “silver bullet” to magically move your applications to a new environment. Each business application is different, and consequently the migration event for each application must be carefully and meticulously planned for to ensure success, and minimal business disruption. If you are considering a move to a new environment, Rackspace Professional Services can help.