Cloud Migration Project Plan - 20 Steps You Need To Take

Migrating to the cloud can be challenging, as there are a lot of factors you need to consider and a lot of steps you need to take.

Creating a detailed project plan is an integral part of any successful cloud migration process.

We've put together the list below to help you plan your move to the cloud.

There is a lot for you to do, but don't feel overwhelmed. Just read the list below, note any glaring oversights in your current migration plans, then start addressing the gaps in your plan.

• Discovery
• Pre-Migration Tidy Up
• Consider Alternatives to IaaS
• Needs Analysis
• Cloud Provider Selection
• Gaining Approval for Cloud Migration
• Create a Migration Plan
• Pre-Migration Updates
• Documentation
• Security
• Backup
• Training
• Monitoring
• Connectivity to Cloud
• Stakeholder Communication
• Proof-of-Concept/Trial Migrations
• Actual Migrations
• Post-Migration Process Changes
• Post-Migration Cloud Optimisation
• Decommissioning/Repurposing Superseded Systems

1. Discovery

• Familiarise yourself with any hosting contracts you may have. Note contractual end dates, costs, specifications, mid-contract upgrades, who owns the servers at the end of the contract, server locations, SLA goals and the process for cancelling the service.
• Document all relevant systems – every VM, database, server application, guest OS, required frameworks e.g. .NET, and dependencies between systems. Document which VMs need to talk to each other and which business processes depend on which stacks. Document hostnames, IP addresses, gateways, firewalls, major firewall rules, subnets, DNS servers, internet breakout details, WAN connections etc.

2. Pre-Migration Tidy Up

• Review the data you store and backup with a view to removing unnecessary files. Look for non-work-related file extensions, excessive duplication and old files that are not used and not needed for compliance, accounting, tax or legal reasons. Look at getting rid of personal directories of employees that left long ago. The more you can trim, the less you will pay for data storage/backup.
• Get rid of any server applications, VMs or databases that are now surplus to requirements.

3. Consider SaaS, PaaS, Systems Retirement as Alternative to IaaS

• Check whether major applications on your servers are actually used in practice. If not, check whether you need to retain the app to allow access to records for legal/reference purposes. If not, strongly consider retiring the system. If it’s running in a VM, perhaps you could store the VM image instead, booting it temporarily on those rare occasions when someone needs to access the app. That would also minimise the security risk of keeping old applications that rely on old, no-longer-supported operating systems.
• If some of your apps are no longer supported or they require an Operating System that’s no longer supported, consider switching to a SaaS/PaaS app for the functionality you need. Look for apps from providers that can help you import your existing data.
• For old but still supported apps, installed at the request of departments, canvas views of whether the apps are still adequate to the department’s needs. Since the original choice was made, better SaaS/PaaS/self-hosted app options may have arisen.

4. Needs Analysis

• Complete the steps on the ‘Discovery’ list.
• Check which VMs, internet sites and WAN sites your individual VMs are communicating with, and how much bandwidth that communication requires. Measure at peak usage times and during backup windows. This information will help you make decisions regarding subnets, firewall rules and dedicated cloud connections.
• Note the volume of data you expect your new cloud system to store and the size of your connection to the cloud. Consider whether transferring data to the cloud via the internet would be quick enough (e.g. transferring ten terabytes of data to the cloud via a 100 Mbps leased line will take over nine days). If not, you may need to think about seeding your new cloud by copying data onto physical media and getting a courier to deliver a storage device to your cloud provider.
• If you have several significant applications running on a single VM, try to disaggregate the resource usage figures for each individual apps. For stability’s sake, it may make sense to give each application instance its own separate VM. You need to know how large to make these VMs.

5. Cloud Provider Selection

• Hold discussions with cloud providers (or their partners in the case of AWS/Azure/Google) to see what they could do. If you’d like to talk to us about your cloud migration project, you can call us on 020 7847 4510 or email info@hso.co.uk
• Get proposals, including cost estimates, specs, service level agreements, certification information, diagrams of the proposed hosting architecture, details of what monitoring, backup and support are included, and what extras would be chargeable. Find out how costs would change if you were to store more data, have more VMs, give VMs more RAM/CPUs etc.
• Get the cloud provider’s terms and conditions (T&Cs) reviewed by your legal dept for acceptability. Start this review early enough to avoid this step delaying your migration. If the T&Cs are unacceptable, negotiate changes, compromise, or find an alternative supplier. The T&Cs of the big public cloud providers are rarely negotiable.

6. Gaining Approval for Cloud Migration

• Review our cloud migration benefits cheatsheet for benefits likely to be of interest to the person signing off the cloud migration project’s budget. Also look for benefits likely to sway colleagues that may be consulted about your proposed migration.
• Quantify the cost of each hour of downtime in terms of lost staff productivity, to show that not having resilient, high-uptime systems is a false economy. Companies House publishes full accounts of mid-to-large firms at no cost, including the pay bill, number of employees and net profit. From these you can calculate the approximate hourly cost of salaries and the approximate profit foregone as a result of downtime.
• Highlight that there is a reputational risk whenever systems suffer downtime, stopping staff from serving customers and customers from accessing your public-facing systems.
• Get potential cloud providers (or their partners) to answer any questions and concerns.
• Position cloud migration as a sensible IT upgrade, not as a change in hosting location.

7. Create a Migration Plan

• Decide the order in which workloads and users will be migrated to the cloud. You may wish to take account of interdependency, business-criticality, complexity and scale. Large migrations that impact thousands of users may be worth staggering over several weeks/months, so user-specific troubleshooting doesn’t overwhelm IT Support.
• Collect and distribute contact details of internal IT staff, external IT consultants, cloud provider technical experts and cloud provider support lines. Include the names, email addresses, work landlines, mobile numbers, and the role each contact is expected to play during migration. This will be helpful during migration, if issues arise.

8. Pre-Migration Updates

• Consider virtualising any workloads not already virtualised, except for where you’re planning to retire the old system or supersede it with a SaaS/PaaS alternative.
• Create templates for new VMs (or have your cloud provider do so). These should include an up-to-date OS, malware protection and systems for updating the OS.
• Consider whether to reinstall existing server apps in new VMs based on these new templates. Potential benefits include more consistent OS patching and greater consistency between production/staging/testing environments.
• If you’re not going to reinstall the app over an up-to-date patched OS, at least apply security updates to the VM’s existing operating system.
• Reduce your time-to-live value, e.g. to 300 seconds – so DNS changes take minutes rather than hours/days to propagate.
• Once you know any new IP addresses, prepare to update existing firewall rules, so they don’t unduly obstruct your cloud servers from communicating with your WAN users.
• Make sure your IT team have credentials for your cloud provider’s portal and are recognised by your cloud provider as authorised to act on your organisation’s behalf. If you rely on an external IT support firm, make sure its staff have their own login credentials and authorisations so they interact with your cloud provider on your behalf.

9. Documentation

• Document the new hosting solution in full. This will come in handy should your relationship with your cloud provider ever sour, leaving you in need of quotes from alternative suppliers. It will also come in handy should you ever change jobs, leaving your successor to inherit your company’s cloud-hosted systems.
• Document how to modify the solution, e.g. how to create a new VM from a template, create a copy of a VM, pause a VM, delete a VM etc. Mostly these actions are likely to be via your cloud provider’s customer portal.
• Document support procedures, including how your cloud provider should be contacted and which of your employees or external IT consultants it has been told to take instruction from.
• Document any changes to on-premise systems. Remove decommissioned on-premise systems from your network diagrams. Note any firewall changes.

10. Security

• If you decide to transfer data to the cloud physically, consider encrypting the data beforehand, in case it gets lost en route to your cloud provider.
• Update policies and processes so departing employees rapidly lose access to SaaS/PaaS apps, cloud provider portals, file syncing tools and the corporate VPN.
• If your organisation is high profile or unpopular with activists, consider how you would handle a Distributed Denial of Service (DDoS) attack on your cloud servers – technically and financially. Talk to your cloud provider about what it can do to help.
• Consider outsourcing OS patching to your cloud hosting provider.
• Delete old decommissioned VMs from now-superseded on-premise systems once it is clear they are no longer needed.
• Securely wipe any surplus hardware prior to reselling/recycling it.
• Be security-conscious when setting up subnets. If servers don’t need to be accessible to the internet generally, merely to authorised users of your VPN/WAN, lock down network access accordingly. Do database servers powering your web site need their own public IP addresses and to be reachable by general internet users? Possibly not.

11. Backup

• Make arrangements to back up cloud-hosted VMs and any data you store in major SaaS services such as Microsoft hosted versions of Exchange, SharePoint or Dynamics. Ideally, use a single system to back up your clouds, SaaS data and on-premise systems.
• Take a full backup of systems before attempting the migration.
• Test that your backup solution can back up your new cloud. Create, change and delete non-essential files, then check you can restore deleted files and earlier file versions.

12. Training

• Train IT staff on logging support tickets with your new cloud provider and using its portal.
• Train IT staff on how to add VMs, resize existing VMs, set up new subnets and update cloud firewall rules, and ensure they understand the cost implications of such changes.
• If you’re using SaaS, users may need training to really get the most from the software.
• If you have in-house developers, consider training them to write cloud-native code, e.g. with multiple simultaneous instances, the ability to use Kubernetes to scale elastically and the ability to provision additional hosting via the cloud provider’s API.

13. Monitoring

• Implement your own server monitoring, so you have your own independent record of measures such as uptime, ping times, web page response times or VM CPU utilisation.
• Check your monitoring is working. Freeze some VMs. Block traffic between your VMs and the monitoring system server(s). Check your cloud provider notices these outages.

14. Connectivity to Cloud

• Check you have enough bandwidth to your new cloud provider’s network. Bear in mind that after migration, traffic that was formerly between in-office end-users and in-office servers will instead travel over your office’s leased line to cloud-hosted servers.
• If you’re hosting in the biggest public clouds (AWS, Azure, Google Cloud Platform), talk to your leased line provider about getting a dedicated private connection to those clouds using AWS Direct Connect, Azure ExpressRoute or GCP Partner Interconnect.
• Consider whether you need to add resilience to your WAN so individual connection failures don’t cut your end-users off from your new cloud-hosted systems. Leased lines often take 3-4 months to install, so order any additional connections in good time.

15. Stakeholder Communication

• Convey the high-level overview of your cloud strategy to stakeholders outside of IT. Focus on benefits relevant to the organisation as a whole, its end-users and customers.
• If you are shifting the processing of personal data to servers hosted abroad, ask your legal department whether additional disclosures are required, such as updating your organisation’s privacy policy or the T&Cs signed by customers, employees or suppliers.
• If you’re switching to a SaaS/PaaS provider, check their T&Cs to see if they regard you as the data controller or the data processor, and if the latter, whether they’re willing to change this if you sign a Data Processing Agreement.

16. Proof-of-Concept/Trial Migrations

• Ask your chosen cloud service provider to help with trial migrations. Make sure they have people on standby to help advise on any issues you may encounter.
• Once your cloud platform is secure enough to connect to your WAN/HQ, update on-premise firewall rules so that WAN users/HQ LAN users can access your new cloud.
• Pick the least disruptive time to migrate, e.g. several hours after close-of-business, at weekends etc. That way, if things don’t go to plan, there will probably be enough time to try to fix the issue and to revert to your existing systems if required.
• Create a test plan. If you need to test thoroughly at scale, create test scripts.
• Schedule the trial migration. Forewarn people if you plan to block or lock production systems during working hours or soon after.
• Arrange in advance for users from different departments to test the migrated systems.
• Shorten DNS time-to-live settings in good time, if DNS changes are planned.
• Attempt the trial migration.
• Run any test scripts. Check the results. Attempt to fix any problems found. Document successful changes, so problems aren’t repeated on subsequent migration attempts.
• Click around manually, trying to find issues, such as problems with networking, incorrect file permissions, slow performance, and web servers not able to connect to databases. Attempt to fix these issues. Document any changes to settings required.
• Re-run proof-of-concept migrations until they go smoothly or you run out of time.
• Decide whether to leave the migrated workload on the cloud (i.e. reclassify your trial migration as the actual migration) or to bin the cloud VMs and go back to your old systems until it’s time to do the ‘actual’ migration.

17. Actual Migrations

• Schedule migrations for the least disruptive time of day, at a time when your cloud service provider can provide named staff to help troubleshoot issues.
• Give departmental leaders advanced notice of the cloud migration so they don’t feel blindsided by the forthcoming email notification to end-users.
• Let affected employees and customers know of planned migrations well in advance, e.g. let them know they’ll lose access to a certain system at 8 pm on Friday week for an estimated period of 3 hours. Try to give customers at least a few weeks’ notice.
• If possible, lock access to legacy systems. If this isn’t possible, consider pointing DNS servers away from the old servers temporarily, then to the new servers once they’re up.
• Repeat your last successful trial migration, but for real this time.
• Check that your new cloud’s guest Operating System and software are properly licenced/activated. You may need to deactivate/uninstall software on your old platform to stay compliant with your software licencing terms.
• Update any systems referencing the old servers if updating DNS isn’t already sufficient. For example, if you have new database servers, update website settings and server applications that currently list the old database server’s hostname and credentials. Keep the old credentials though, in case you need to revert.
• Restore your normal DNS time-to-live value.
• Check the firewall is blocking access to any cloud servers that shouldn’t be directly reachable via the Internet. Test from home, your mobile, or a non-corporate VPN, if the corporate LAN/WAN/VPN is subject to less restrictive firewall rules.

18. Post-Migration Process Changes

• Update internal documentation on IT provisioning to reflect that you’re now setting things up via a cloud provider’s portal rather than ordering physical hardware.
• Update internal documentation of your IT architecture now that certain on-prem hosts and storage devices are no longer in use.
• Make sure you’ve done what’s required to enable speedy payment of cloud provider invoices. You don’t want to risk your IT systems temporarily disappearing due to non-payment or late payment.
• Add a periodic review of cloud usage/costs to your IT department process, especially if your cloud provider’s bill includes usage-based charges that could result in unexpectedly large bills – due to increased usage of your new systems.

19. Post-Migration Cloud Optimisation

• Check VMs for utilisation levels that are a bit too close to their quotas for comfort. Check apps for sluggish performance. If an app is slow, check whether CPU, RAM, storage latency or bandwidth are the primary performance constraint.
• Check VMs for very low utilisation levels during peak usage times.
• Amend VM resource quotas – up or down - while being mindful of cost implications.
• Pay close attention to your initial cloud hosting bills in case there are surprises.
• Having adjusted resource levels up/down, check for new bottlenecks.
• Periodically, check whether quotas have become misaligned with recent usage levels.

20. Decommissioning/Repurposing Superseded Systems

• Wait a short while to see if things go wrong with the new system. If nothing goes wrong, feel free to decommission the old systems.
• Keep a temporary copy of the VMs/files/databases from decommissioned systems in case they are needed.
• If you no longer require certain software or hardware, cancel the relevant automatic licence renewals and hardware maintenance agreements. Some software may need to be deactivated or uninstalled before you wipe it, to avoid licencing issues.
• Decide whether the hardware should be reused, resold or recycled, after data wiping.

---

This cloud migration plan is taken from hSo's Complete Guide to Cloud Migration. To receive your copy, please call us on 020 7847 4510.