It’s easy to get stuck in the weeds with a giant migration initiative, but distilling the cloud prep and migration process into manageable phases for the move from a physical infrastructure to cloud presents an overview that fosters a more holistic and accurate approach.
Here are three phases to a smoother cloud transition:
PHASE 1 of Moving from a Physical Infrastructure to Cloud: Discovery
What Do I Have?
The first question you need to answer is “What is running on my current infrastructure?”
Knowing what workloads are at stake and the state of their resiliency will help you determine if your application:
- is supportable on a virtualized infrastructure and will easily migrate
- needs to be rebuilt for cloud compatibility
- should be embedded in other applications
- can be shut down and removed altogether
Security Governance, Risk, and Compliance
You should also take this opportunity to assess your data protection and retention requirements as they pertain to cloud environments. Depending on the level of security required, some types of data may not be safely stored and managed in public cloud environments. While PCI, HIPAA, and SOX are generally possible in IaaS environments, you might prefer to retain some physical infrastructure to making meeting these standards more straightforward. Knowing this in advance will enable you to design around strict security requirements.
Software Licensing
Bear in mind that some enterprise applications can become an issue because of how they are licensed. Consequently, they might not be supported on a VM because they are not certified (this primarily occurs with databases or smaller, third-party apps).
Consider an application that is running on a physical machine with two processors. The VM you are looking to migrate it to might have two virtual processors, but the underlying machine might house up to 16 or 32. Some agreements require that you purchase licenses for all cores of that physical machine even when they are not used by the VM itself. Consider this scenario in a cloud environment where you might know nothing about the underlying physical infrastructure. You need to do your homework to avoid an expense breach of your software licensing agreements.
PHASE 2 of Moving from a Physical Infrastructure to Cloud: Architecture, Network, and Sizing
How Large Should My Environments Be?
Before you begin the migration process, it is critical that you confirm the size of the VM that you will need to run each application. Determine if you require specialized networking for the application to be able to run (whether it needs a specific LAN or subnet) and confirm CPU and other requirements that physical servers have. (This stage is also a good time to introduce new architecture ideas, microservices, containers, etc.).
- Example 1: An application that is configured to run internet-facing workloads:
- You will need network rules that enable that machine to connect with the internet but not necessarily to be fully open.
- You will also need ports in a DMZ with ports in the backend connecting to the database (with the database protected from public internet).
- Example 2: An application with a hard-coded IP address:
- You will need to redesign the application to rely on hostnames instead of IP addresses.
- OR, you will need to design the network to support that IP address (via separate vNAT in AWS that maps back to the correct address range).
- Example 3: A database running on a physical server that needs to be moved to a virtualized platform:
- You need to connect to a storage infrastructure that will support the amount of data and I/O that your database has.
- You might choose to move from a traditional RDS to a NoSQL-style scale-out database.
Ultimately, you need to consider how latency may affect the performance of your application. To mitigate the potential for this and make this an easier cloud transition, you must ensure that you will have adequate bandwidth to and from your cloud provider.
PHASE 3 of Moving from a Physical Infrastructure to Cloud: Setup, Migrate, and Rollback Plan
How Do I Get There, and How Do I Get Back?
If you’re moving from a physical environment to a virtual one, you don’t want to carry forward old software (with old bugs) into the new virtualized environment.
To mitigate this, you need to build a new image that is:
- virtual and/or cloud-native
- patched
- up-to-date with a modern OS
From there, copy your data over to the new environment and then confirm that everything works. Then repeat as necessary for each p2v server. Yes, this one will be time consuming.
There and Back Again
What happens, though, if this migration doesn’t go to plan?
Either way, you need to have a plan for recovery and rollback, and you can start by doing a full backup of your system the day before the migration.
- Schedule the migration itself for a day and time where the impact will be minimal (typically these are done on weekends in the early morning).
- Get your IT team on a call together
- Do the cutover
- Turn your environment on in the new virtualized environment.
- Unplug the legacy system or turn on single-user mode (to ensure that no traffic is running across the old environment[1])
Once you have made the cutover, have the application team do a “smoke test” to confirm the new environment is working adequately. If it isn’t, try to troubleshoot and solve for the issues. If you can’t solve the critical issues, you need to roll back to the old environment to reduce downtime.
Even if everything does work, however, leave the old environment in its place for a week or two after the switch over. If you run into a critical error or an unrecoverable outage, you have that legacy fallback.
Getting Over the Hurdle from Physical Infrastructure to Cloud
The move from a physical infrastructure to cloud is a big step towards your company’s digital transformation.
With cloud, you enable scalable performance, more customizations, and added functionality—but with all those features come more considerations than with your legacy hardware-housed networks. Cloud will be more dynamic, the infrastructure management tools will be different, as will your approach to its security.
You have a lot of planning and implementation ahead, so let’s get started.
[1] Turning on an old machine can cause an IP conflict that can bring down your application.
