Cloud Migration Steps – Here's What You Need to Do
If you are considering migrating your organisation's IT systems to the cloud, you may be wondering what steps you need to take.
While every migration is slightly different, there are a few elements common to nearly every instance. Review the list of cloud migration steps below to get an idea of what you need to focus on.
Hopefully, our step-by-step process should help make cloud migration less intimidating.
Step 1: Start with "Why?"
Before you dive into the details, spend some time thinking about what outcomes your organisation wishes to achieve by migrating IT to the cloud. Also consider the relative importance of those outcomes.
An organisation that migrates to the cloud to increase scalability and uptime may take a different approach to an organisation that's primarily focused on reducing a large managed hosting bill. Differences in relative priorities may influence some critical choices such as the choice of provider and the degree to which your existing setup needs to be re-engineered.
Step 2: Find Out What You Have
Before you can get too far into these cloud migration steps, you need to take an inventory of your current IT systems, so you don't overlook important aspects of your current setup.
This review should list your databases, server applications, IP address assignments, DNS servers, frameworks required by your installed applications, firewall rules, virtual machines, subnets, and anything else that will need to be included in your cloud migration planning.
Having all of this information documented and in one place will save you much time later.
Step 3: Check Your Contracts
Signing on with a new cloud provider may mean ending some relationships with other vendors. One of your cloud migration steps will be reviewing any IT-related contracts that are in force - including any you have for hosting, colocation, hardware leasing or hire-purchase, software licences and technical support. Document the end dates, termination fees, notice periods, and termination processes.
This is an excellent time to check what happens to any soon-to-be-decommissioned equipment that's delivered as part of a managed service. Who owns the equipment when the managed service is terminated? Are you responsible for returning it to your former provider, or will it collect it? If you want to cancel the service mid-contract, what would the cost be?
Step 4: Determine Usage Levels
Do your best to determine your current and future IT resource requirements. The latter will require some guesswork.
It is common to over-spec on-premise systems, then contend them so that spare capacity (CPU cycles, RAM, storage) can be liberally borrowed by any application or VM.
If you're moving to cloud-based systems that do not allow your workloads to contend for a shared pool of capacity, you will need to be more disciplined when setting resource allocations - if you're to avoid bill shock after moving to the cloud.
Your initial action is to document current usage levels - including at times of peak stress - as this will be helpful in talking to potential cloud service providers and deciding on your new system's specifications.
Don't just focus on CPU, RAM and storage. Pay attention to bandwidth use, too, as you may need to think about whether to get a higher-capacity connection between your office and your new cloud.
This step differs from step two, as that was about architecture and reserved capacity. This step is focused on usage of capacity - in particular, whether the current level of reserved capacity is appropriate, now and in the future.
Step 5: Secure Internal Agreement
Your exploratory discussions with suppliers will help you get an idea of how technically ambitious you can afford to be. You'll also know how much your new cloud is likely to cost. Now is the time to discuss the matter with those who need to sign-off such expenditure, and other stakeholders in the business who also need to approve any shift to the cloud.
You want to get agreement in principle that - subject to negotiation - your organisation is going to proceed with your cloud migration project.
Bear in mind that gaining approval will usually involve explaining the business implications of technology benefits, rather than focusing on technical specifications.
If anyone who can veto the project has serious concerns, get short-listed cloud providers to help you address those concerns. They may have technical staff, customer case studies and salesmen who can help you allay concerns.
Step 6: Choose Your Cloud Provider
Having completed the previous cloud migration steps, you'll likely want to share some of the information you collected and the decisions you have made with potential cloud providers. The more they can understand where you currently are and where you are headed, the better they are able to offer a solution tailored to your specific needs.
Your conversations with potential cloud suppliers will help you get a feel for which providers really get what you're trying to achieve and are willing to put in the time to help you get the right solution. To help narrow your list of suppliers, you will want to see written proposals, estimates of costs and timings, and in-depth technical specifications. As part of your final decision, you will want to have your likely supplier's terms and conditions reviewed by your organisation's legal team, so you're not delayed in signing the contract once you have decided to proceed.
Step 7: Sign The Contract
It's time to make it official - signing the contract with your chosen cloud provider (or one of their consulting/technology partners).
Be mindful of your organisation's procurement processes and who needs to sign off your agreement with the supplier.
Step 8: Create a Detailed Plan
Working closely with your chosen cloud provider, create a detailed migration plan setting out all remaining migration steps and responsibilities.
Document everything that needs to be done, who is responsible for doing it, who needs to approve it, and who needs to be notified of it.
Migrations can take many weeks or months, and detailed scheduling can ensure that the right work is completed at the most suitable times of day, week and year. You'll need to bear in mind that some business-critical systems can only be migrated outside of opening/trading hours. Also remember that some systems are interdependent, so you need to sequence your cloud migration to take account of that.
You will require input on the schedule from internal IT staff, your chosen cloud service provider, any additional vendors involved in the project, and organisational leadership to ensure that plan includes all the critical components of the migration and that everything is scheduled so as to limit disruption.
Step 9: Communicate, Communicate, Communicate
Moving your workloads to the cloud isn't enough. You also need to communicate this move, in a timely manner, to people likely to be affected by the migration. Cloud migration can be disruptive for managers, staff, and even clients. To reduce anxiety and unforeseen problems, clear, timely communication is essential.
You'll want to give people a suitable amount of notice that a particular system is going to be made read-only, or made (temporarily) unavailable.
You also need to communicate the benefits of your cloud migration project. Perhaps your migration could be a minor 'good news' story in your customer newsletter. One that shows you're investing in making things even better, becoming even more reliable, that you're building capacity, that your services are popular, precipitating this welcome upgrade. It's also a good news story, ideal for 'all staff' meetings where the senior people are keen to boost staff morale by showcasing recent progress.
Step 10: Know Who to Call
Even if you follow all the cloud migration steps we've outlined, migrations seldom go without a few surprises. It's important that you're ready to deal with these. In particular, it's important you and everyone else directly involved in the migration knows how to contact other relevant contacts - so troubleshooting can happen quickly.
You don't want the migration to be put on hold while someone is tracking down a staff member, cloud partner contact, or vendor. Put together a contact list including phone numbers, email addresses, and any other means of contact. It may also be helpful to create a "who to call" list that helps people understand the best person to contact when an issue arises.
Step 11: Clean IT Up
Unless you spend some time reviewing your current files, you may be migrating data you don't need. There is no point in wasting your data storage quota on files that could be deleted. Instead, take the time to search for and remove excessive duplicate files, extensions no longer associated with any program, outdated files no longer required for compliance, unused server applications, databases, and virtual machines that may no longer be used.
Step 12: Back Up Data
You will want to take a complete backup of everything before beginning your migration. More than that, this is an excellent time to ensure that your data can be quickly restored from your backup system. If you are using multiple backup systems to protect your data, it may be a good time to consolidate to a single backup system that's capable of backing up on-premise servers, cloud-based servers, and hosted data (such as Microsoft 365 hosted emails and OneDrive files).
While you are at it, review whether your backup strategy is ready for your post-migration setup. Prior to migration, you may have been backing up an on-premise server to an on-premise storage device. Now your workloads are shifting to the cloud, that solution may not be suitable, given the large amount of data needing to be backed up. If that's the case, it may be time to switch to an enterprise-focused cloud backup service.
Step 13: Keep IT Secure
Pay close attention to data security before, during, and after the cloud migration. For example, whether you are transferring data to the cloud provider via physical media or sending it via the Internet, you may want to encrypt the data before it is transferred.
Bear in mind that your new cloud servers will need virtual or physical firewalls to protect them.
Talk to your cloud hosting provider about the security they have in place to protect your hosted data. If your new cloud replaces various on-prem systems, make sure you temporarily deactivate such systems post-migration, and once you're sure everything's fine, decommission those systems. Where you're getting rid of hardware that's no longer needed, make sure the hard drives are securely wiped.
Step 14: Document Everything
You've documented what IT resources you had and what you were planning to do. Now it's time to properly document your new system.
You plan to create new VMs on a new cloud? Great. How do you add a new virtual machine, suspend it, reboot it, or clone it?
Be sure the documentation includes clear instructions for all common procedures that your internal IT team will handle (even occasionally). Remember to assemble detailed information about accessing support from your cloud provider and the vendors for any additional software or hardware.
If old systems are being decommissioned as part of the migration process, update existing documentation, so you're ready to publish the new version once the old systems have been decommissioned.
Step 15: Review IT and Personnel Policies
Your policies regarding IT were probably designed for a simpler time, when everyone accessed corporate information using employer-owned hardware connected to a local LAN, in the office. Post-COVID, that world is gone, so you need to ensure your IT policies and HR policies are updated to reflect the new realities of cloud-based hosting and hybrid working.
Specifically, you need to ensure you have policies in place to quickly lock out leavers, so you're not just disabling their access to your corporate office network but also to cloud-based accounts that may use different login credentials to your LAN.
Step 16: Perform Pilot Migration(s)
Given the potential disruption of a cloud migration, it is a best practice to schedule and perform some trial migrations first. This may help you quickly discover if there is a flaw in your plan! The trial migration can be of just a subset of your systems, just a subset of your users, or just a subset of your data. This will help ensure there is less at stake if things don't go as planned.
Be sure to schedule initial tests during off-hours and, if anyone will be impacted, let them know far in advance. Upon finishing the test migration, have the team thoroughly test any applications, looking for potential issues - including performance problems. When adjustments need to be made, be sure to document any changes that need to be made.
In some cases, a pilot migration will go so well that you decide to reclassify the trial migration as the actual migration.
Step 17: Finish Migrating
Even though there is quite a bit of pressure riding on a successful migration, you should feel confident and ready for the main migration event. Of course, that doesn't mean there will be no problems. However, you, your team, and your cloud provider will be ready to make adjustments on the fly.
Want to Know More?
Is your UK-based organisation prepared to make the move to the cloud? Check out hSo's free guide to cloud migration to make sure you are ready to make the switch.
To claim your copy, click on the banner at the top of this page.
