These days, it’s no longer a question of ‘why’ adopt cloud, but how. And now, customers on VMware enterprise environments are able to unlock the benefits of Amazon Web Services (AWS) alongside a mix of cloud platforms – without the need for large or costly transformation projects.
While this is great news, the migration piece does need to be carefully planned and considered. Done well, it can be seamless, low-cost and hassle-free. Done poorly, it can mean delays, errors and even potential security and compliance risks.
While you don’t have to worry about your workloads fitting (VMware Cloud on AWS can be expanded quickly by adding resources directly or set to auto-scale through demand), or performing (with the latest Amazon server infrastructure, VMware vSAN and fast SSD storage, that’s assured), their successful migration isn’t always guaranteed.
So, when it comes to migration, what key things should you consider? How can you ensure success? Here are our top tips:
1. Get data collection and ownership underway from the outset
Most importantly, a successful migration relies on having a solid and agreed data collection effort underway and understood. Of course, data collection can be tiresome, and not surprisingly, isn’t enjoyed by all – but in a migration project, it’s critical.
Establishing ownership is also vital. Determine, up-front, who will own your migration effort, and more specifically, who will be responsible for collecting and migrating your data. Data collection should be a standard exercise that, if all goes well, will simply leave a series of ‘yes’ or ‘no’/ ‘go’ or ‘no-go’ migration decisions.
2. Prepare a migration sheet
Another key component of a successful migration is having a migration sheet – i.e. a central, easily accessible checklist of everything that needs to be done.
A good migration sheet should include details of every workload server that will be migrated. This should cover:
- Technical details – i.e. IPs, names, disks, sizes, networks.
- Caveats – e.g. ‘don’t touch this server on Tuesdays’ or ‘this application has no backup’.
- Business details – i.e. where in the business does this application fit? Include a description of what the workload provides, relevant information on recent changes, or notes on any future plans that may impact migration decisions (e.g. is it getting replaced?).
- Ownership details – i.e. who knows about this workload? What is the team or person’s details in case there is a question or a problem? It’s incredible how often an application within a business will be ‘owned’ by a random employee (let’s call him ‘Dave’) who has actually now left the business, and only vaguely documented the application’s connections and dependencies.
- Tester details – i.e. what testing is required in order done to sign-off a migration? Who is in this testing team and what are their details?
- Connections – what other dependencies does this workload have? What internal or external connections are there? You can’t afford to simply have a particular workload stop working mid-way through a migration.
- Migration state – i.e. is a specific workload going be migrated? If not, why? If yes, then when?
- Rollback plan – what is involved in putting this workload back on-premise if required? It’s important to know how to recover in a race, or the race could end in disaster.
3. Put solid project management in place
This may seem like a no-brainer, but it’s surprising how many organisations don’t take a step back and approach a migration with a project management mindset.
In addition to the migration sheet mentioned above, a solid project management approach should also incorporate three key elements:
Runbook
This is a set of prescribed steps, including get togethers/run-throughs, migration dates, communications activity, backup checks and exact steps for ‘migration day’. It should also outline who is responsible for each step – with contact details.
Wave planning
All workloads that are to be migrated need sorting into ‘waves’ which can make it easier to plan agreed change windows and communications activity. More on this below.
Workload Passport
This is a one-page document for each service that is to be migrated, which contains its migration details including its change plan ID, date, status, testing results, migration scope (server names, locations, names), firewall rules, vRealize Network Insight (vRNI) outputs, and other information such as associated documentation. This document makes it easier to move this entire service around later – perhaps to an on-premises environment, another VMware Cloud on AWS site, or into AWS.
4. Map your application dependencies
Application Dependency mapping offers an accurate view of all your applications, as well as any dependencies to services and workloads - both known and forgotten.
This could include business applications with dependencies on hardware that are routable to VMware Cloud on AWS. It’s best that these are known about before migration, to ensure the routing is validated - reducing outage times or surprises. Dependencies between applications can also affect the order of migrations or when business communications are issued.
Network traffic is another important element of application dependency mapping.
The VMware Realize Network Insight product gives you a way to capture application dependency mappings by sitting on the network and watching traffic between participating components, including deep into the virtualisation infrastructure. This product will map out the traffic communications between services, while allowing for groupings and tagging to put a ‘business’ overlay onto that information.
While providing this insight into your business workload communications, vRealize Network Insight will also capture firewall triggers and provide a means to map firewall rules to your VMware Cloud on AWS. These firewall rules can lead to a bunch of micro-segmentation goodness, allowing for granular virtual machine service-to-service firewalling… but this is a subject for an entirely new blog.
5. Plan your methods for migration
While planning excitedly how to migrate workloads in several waves, it’s good to keep in mind the methods of migration.
This can be achieved by using a product called VMware Hybrid Mobility (HCX), which is a set of virtual appliances and services that provides functions such as L2 network extension to cloud, and of course, movement of business virtual machines to VMware Cloud on AWS.
Migration methods can include:
Cold Migration Tier 2/Tier 3
This is the easy one. A workload is turned off and flicked across the network, to land on the VMware Cloud on AWS infrastructure, and is then powered on. The outage will be the longest for this method, as no data is sent across while running, and if the on-premises and cloud vCenters are not joined with Hybrid Linked Mode, then HCX can be used.
Warm Migration Tier 1
This is the ‘almost as easy’ one. A workload has a very low downtime. Using on-premises vSphere Replication (free) and VMware HCX, virtual machines can be replicated along with future changes to the cloud. At a scheduled time, a small outage is performed to finish replication and then power on the workload in the cloud. This is a good method to do bulk migrations for situations where you want hundreds of dev machines to ‘just move’.
Hot/Live Migration Mission-Crit
This is for situations where a workload must keep running. This migration method has no downtime as the virtual machine is not switched off and it is live migrated from on-premises to the cloud. A few prerequisites are required for this, including a preferred 250Mbps bandwidth per vMotion. While it appears to be an attractive option, it does need testing relevant to the built situation at the time, and the amount of data being migrated and their rates, available bandwidth, latency etc., all come into play. Live migrations can also be on-demand or planned, the latter using vSphere Replication for seeding.
Content Library Import
This is the method through which you can move media, including templates, to your cloud and provision from scratch.
6. Manage potential roadblocks
In any migration, there are usually a few challenges that pop up along the way, which need to be carefully managed and overcome. Typically include:
Getting hung up on testing
Yes, critical applications and connections to services – in particular - need solid testing. Without question. However, in many instances, it can pay to look at a workload and consider what exactly is changing outside of the hosting location. If you are, within reason, just moving a workload somewhere else, then network routing takes care of most challenges. In these instances, testing can be brief and pertinent.
Making every migration a massive ‘thing’
A workload is indeed precious. However, with the right parties from the business and proper change management, a surprising number of workloads can be migrated quickly and successfully. Have confidence in your data, your team, and your tools. Get this right at the beginning and build on that success.
Valid migration criteria not established or adhered to
To prevent this problem from occurring, set minimum business criteria, as well as technical criteria (such as size or connectivity areas) that can/cannot migrate. Alternatively, this could be simplified to a base-line CPU and other criteria where items below are to be migrated and those above are to be discussed.
Process not understood by all parties, or the “oops I didn’t realise that”
This can be avoided by using runbooks for capturing a repeatable end-to-end set of steps. Simply make sure all parties involved attend a “learn-it or no migration” run-through prior to starting, so that on the day, activities are known and co-ordinated.
Service management examination not examined
Involve your service management team right from the start to ensure infrastructure state changes can still be wrapped in existing service level agreements, or brew some new ones up to capture this.
Business continuity is broken
Overcome this by examining existing disaster recovery services and dashboards for the to-be-migrated services. Hopefully, by going to the cloud, this has improved or at least, will continue. If it hasn’t, then it’s worth reaching out to a trusted partner for assistance. In fact, DR using VMware Site Recovery Manager as a service to VMware Cloud on AWS is an offering that may cater for this gap.
Service owner considerations are skipped over
As part of your migration sheet, ensure that all workload and task owners are identified. Use considerations and findings from successful migrations to assist other owners with their challenges, and build on past success.
7. Be flexible
Let’s get back to how we manage those applications ‘owned’ by former employee, ‘Dave’, as an example of the need to be flexible and adaptive in any migration.
Initially, we may start by dumping two of Dave’s virtual machines into the migration sheet via vCenter export. Both workloads meet the base criteria of 4vCPU + 8Gb memory or less, so can be considered a ‘go’ for migration.
However, once we run vRealize Network Insight and examine the application dependency mapping for Dave’s application, it may turn out that we have one physical server for running reports and the database is on a virtual SQL server which is not being migrated.
As long as all processes are in place – and we have a flexible mindset – this won’t be a problem. We simply conduct a quick check to validate the network routing between pieces, remembering that no changes occur to migrated virtual machines, and that vRNI firewall rules are ported up to the Cloud, then we put the two workloads into Wave 4 and off they go. Simple.
In summary, as long as you have a solid plan in place – from the beginning – and follow the right steps, you can go a long way to ensuring the overall success of your migration.
If you would like to learn more about planning a successful VMware cloud on AWS migration, get in touch with the team at Fujitsu today.
