9 months ago
132
Cloud computing has been a staple of many organizations for years, offering an array of online services such as collaboration, communication, data storage, backup, and CRM tools. The cloud has served a useful role as many companies have expanded or switched entirely to a remote-based workforce.
As cloud vendors have evolved and improved their offerings, businesses have taken advantage of their various strengths by opting to utilize multiple providers of multicloud technology.
If you’re considering a multicloud migration, this guide will help in the decision-making process.
SEE: What Is Multicloud Architecture? (TechRepublic)
Types of cloud platforms
There are four main types of cloud computing:
- Private: Dedicated to a single user, group, or organization which can be on- or off-premises.
- Public: Dedicated to multiple users, groups, or organizations which can be on- or off-premises.
- Hybrid: A combination of private and public clouds.
- Multicloud: A combination of private and public clouds spanning multiple vendors.
There are three main types of cloud computing services:
- Infrastructure as a Service offers standard compute, storage, and network resources on a demand-based scale.
- Platform as a Service offers software development and deployment resources.
- Software as a Service offers software distribution to end users.
SEE: An Introduction to Multicloud Strategy (TechRepublic)
What is multicloud?
Multicloud is a concept involving two or more cloud service providers being used for various business functions. For example, one vendor offers collaboration and messaging, and another vendor provides data analytics.
SEE: The Art of Multicloud Deployment (TechRepublic)
Why adopt a multicloud approach?
The primary advantage of multicloud is to spread your company eggs across multiple baskets, so to speak. Risk is decreased when you reduce a single point of failure and vendor lock-in. Companies gain more flexibility to switch providers as needed to find the most advantageous mix and match of providers.
Multiple vendors each providing multilayered security solutions can help segregate data and resources such that if one vendor should suffer a breach, the other vendors are still protecting the company resources they support.
SEE: Hiring Kit: Cloud Engineer (TechRepublic Premium)
What is a multicloud migration?
A multicloud migration is the process of moving resources from one place to another — on-premises to the cloud, from the cloud to the cloud, or from one source to multiple cloud providers.
SEE: Multicloud vs Hybrid Cloud: Which One Is Right for Your Organization? (TechRepublic)
Steps of a multicloud migration
Here’s a comprehensive look at the migration process.
Planning phase
As with most projects, the planning phase is the lengthiest and most detailed compared to the actual execution of the migration.
Assess and determine scope of needs
First, determine what you want out of a multicloud platform. Ask these questions: what needs are in play, which functions and services should be relocated, which ones may or should stay in house, what constitutes a successful migration, and what advantages and pitfalls may arise?
You may have a lead on a vendor offering incentives or discounts, or company regulations may prohibit another type of vendor or multicloud service, and this should be part of the assessment.
Assess and determine budget and costs
Next, determine what sort of funding you have to work with and match this against the estimated costs of the new platform. There may be a per-user or per-usage fee, flat fees for services, annual subscriptions, or specific support charges.
It may be helpful to do some initial research on average multicloud migrations or vendors offering the services you intend to use. This will help provide finance and management a baseline as to what they should expect to allocate, so there are no misconceptions or surprises regarding costs.
Identify stakeholders and responsibilities
Involve a diverse cross-section of personnel from the groups who will use or make decisions regarding the proposed platform.
Each individual should be assigned a role, whether it is taking inventory of information and assets, vetting vendors, establishing the migration path, ensuring compliance, or engaging in user training and documentation.
Ensure all users are valid
Assuming the intent is to migrate user accounts to multicloud environments, make sure only the active ones are slated for migration. Utilize account administration mechanisms like checking for inactive accounts to ensure all unused and former users are disabled or deleted.
Ensure data is valid
Assuming the intent is to migrate data to multicloud environments, make sure only valid, actively used data is to be migrated. Unnecessary information will consume time and resources best used in getting critical information moved over instead. Archive or purge that which is not needed to streamline your dataset in advance.
Ensure services are valid
Where applicable, determine the validity of services which are under consideration to be moved. Don’t waste time fixating on a web server no longer being utilized or a tertiary DNS server which was unnecessarily implemented. Most likely, your focus will be on messaging and communication, collaboration, company portals, data, and infrastructural services.
Make an inventory
For most companies the inventory would likely entail users, data, and certain services such as email, file storage, and collaboration functions. If you’re planning to utilize PaaS, you’ll have to factor in your development environment.
For IaaS, include infrastructural components like VPNs, DNS, DHCP, and other back-end structures. For SaaS, this will involve the software you need to distribute to end users and systems.
Prioritize migration components
Decide what to migrate in which order and keep in mind that the preliminary migration doesn’t require an instant cutover. This isn’t like leaping from building to building but more like extending a ladder from one building to another to bring items over until you complete the move to the destination.
Likely you’ll want to implement services on the target then copy users and data over. Determine which is the most important versus less important. For instance, outdated data is probably going to be near the bottom of the list, whereas active customer data will be near the top.
Determine necessary permissions and plan to use group or role-based access
The permissions needed for user accounts and data access in a multicloud environment will likely be modeled after what already exists in your current environment. Assess the current permissions, making sure these are valid, and determine how to migrate these access structures.
Ideally, the accounts and permissions can remain intact, but if these need to be created anew, gather reports of your existing layout. For instance, Active Directory can utilize PowerShell scripts to extract this information, in preparation to duplicate these structures.
Always plan to rely on group or role-based access methodologies to help streamline and safeguard access to critical data.
Establish SLAs and acceptable performance baselines
Every prospective vendor must be able to provide service-level agreements and performance optics to identify how a multicloud environment is operating.
Before looking into vendors, identify appropriate SLAs to determine factors such as guaranteed uptime, environment support, and individual client support. Most critical functions are going to warrant the five nines, 99.999% uptime, but keep in mind you may pay a premium for this, and it is really justified only for environments with 24/7/365 operations, such as global companies.
Performance baselines establish what sort of service quality is acceptable. Response time, connectivity speed, and resource utilization all factor in here, and armed with this as well as the SLA necessities, you can now start the vendor analysis process.
Research the vendors
Now that you have an inkling of what is being migrated, start researching prospective vendors offering products which fit your company’s needs. Focus both on their marketing information as well as independent reviews to analyze product quality, customer satisfaction, and potential pitfalls. Then, narrow your search to select three potential vendors to proceed with.
Prospective vendor selection
Engage the top three vendors to open a dialogue to discuss company needs and expectations. Most of the remaining steps in the planning phase will be based on narrowing the vendor selection from three to one.
Determine where resources will migrate to and how they will sync (if applicable)
This entails subjective analyses to map out how your current company resources are going to fit into the multicloud platform. This includes users, data, services, and anything you intend to migrate. For instance, if you were looking at Microsoft, users might end up in Microsoft 365, data in OneDrive, messaging apps in Exchange, etc.
It’s important to determine if a sync from your source to target will be in place, which is highly preferable. You would want bidirectional synchronization, so both environments are identical and any changes (deltas) are passed between both.
Determine how migration tools will function
The migration process itself may involve connectors, exports, and imports, fresh setups, or some other way to get point A duplicated to point B.
Determine how automation will factor in
Automation should be a key ingredient during the migration process. Having to manually sync resources from source to target is tedious and time-consuming.
Ideally, something that runs every five to 10 minutes should suffice. You don’t want to overload network links with unnecessary traffic, but you also want to make the cutover point as quick and painless as possible.
Logging is a must to confirm success and help identify any issues. Plan to verify that resources exist in both locations and are fully up to date.
Make sure all compliance regulations are met
The stakeholder assigned to handle compliance regulations should ensure any and all applicable regulations related to company operations are fully in effect with all prospective vendors.
Determine access to the new solutions
Access to a multicloud environment will work through a variety of means. Mobile devices, laptops, and workstations will likely require access via multi-factor authentication means over VPN tunnels. There may be browser-based access or desktop and mobile apps involved or a combination of both.
The goal is to establish how users will connect and work to the new platform to set the expectations for daily operations and support.
Factor in disaster recovery
Disaster recovery in a multicloud environment doesn’t just refer to lost data or unavailable services and resources, but also connectivity and access issues. This ties in with SLAs, but it’s still important to establish how company resources can be recovered.
Is there a backup site or system users can access? How long can data be recovered for? How quickly can an accidentally disabled or deleted user be restored? The vendor should be able to lay this all out in comprehensive detail.
Determine if you need current and new environments to interoperate
This entails linking your current environment to the new multicloud environment, so user access, data, and services can be shared. For instance, users on the old system being able to send email and instant messages to the new and vice versa.
This is a highly recommended arrangement which will greatly ease the transition and reduce risk to the organization as well as help users maintain their daily operations to attend to their workloads.
Engage in a trial, demo, or proof of concept to confirm desired functionality
Reputable vendors will always provide a way to try out their products or at the very least view a demonstration as to how it works. A proof of concept using live, albeit test, data is ideal, and this should entail a thorough testing of all features and functions to ensure expectations are met.
Identify company versus provider responsibilities
Every company is going to have its own set of priorities in terms of assigning administration tasks both during migrations and for general operations after the fact. For the migration this will entail setting up users, services, and resources; getting data copied over; developing training guides for admins and users; and every detail involved with relocating to a multicloud environment.
Determine who will handle these responsibilities as well as day-to-day activities after the migration. This will entail provisioning and disabling users, managing data and permissions, maintaining services and resources, and handling troubleshooting and disaster recovery.
Make the final vendor selection
The vendor that matches the criteria above as best as possible should be chosen, but also select a runner-up in case of any issues finalizing the arrangement.
Arrange a post-migration date to terminate any existing contracts or plan for decommissioning
This is something that can be easily overlooked or downplayed, as many might feel they should hold onto existing contracts, plans, or equipment just in case they need to fail back to their current environment.
A 30-day “burn in” period is probably fine, but it’s recommended to arrange to terminate any existing contracts or plans and have any relevant equipment for an on-premises data center decommissioned by a certain date.
Build plan to fail back if needed
All migrated elements and resources should be factored into a plan to revert operations to your current environment. This may be as simple as directing users to connect to existing resources and websites which remain intact following the migration. However, it may be more complex in the form of updating external DNS records to point traffic back to the original configuration or external customers to revisit prior URLs for company resources.
Notify users as to what to expect
Develop and provide documentation and schedules to users as to how and when the migration will proceed. In most cases, sections of the user population will switch over in a timely fashion.
The documentation should be laid out in an FAQ format and include a migration timeline and contacts for internal and external support. A checklist for users to follow to confirm full access and functionality is preferable. Live tutorials are highly recommended.
Migrate data and build apps in preparation to go-live
The final element to the planning phase is to set up everything you can in the target environment to mirror the current landscape. User accounts, data, and services can be provisioned on the target system to streamline the migration to the point it becomes as easy as stepping from one rock to another in a stream.
Migration phase
Final data sync
This merely involves catching up the target environment with the source environment, so the two are equally identical. Since users and data are on the move quite frequently, schedule this for a period of minimal activity such as the middle of the night or on a holiday.
Make sure any elements somehow missed can easily be retrieved and moved over as needed.
Complete the migration via cutover
This is ironically the simplest part of the operation and involves pointing systems and resources to the new environment, either through direct access via desktop apps, browser-based access, or infrastructural elements such as DNS records.
Make sure to leave the current environment intact until the agreed-upon termination cutoff date.
Post-migration phase
Terminate any existing contracts or plans
Once the termination deadline has expired, arrange any existing contract or plans to be discontinued. This will also entail disposal of user accounts and data as well as shutting off services.
Decommission of existing equipment
Where applicable, plan to shut down and remove from the premises any equipment no longer needed. Make sure to securely erase any storage devices and then either sell the equipment or engage a recycling center to pick up or have the equipment delivered for disposal.
Documentation updates
This is a step often neglected and the least glamorous part of almost any endeavor. All documentation pertaining to the former environment must be updated to reflect the new environment. Include diagrams, operational runbooks, user onboarding and decommissioning, troubleshooting guides, support contracts and contact information, licensing data, and SLAs.
Ensure all individuals responsible for maintaining and supporting the multicloud environment have access to this information and that it is updated routinely.
Plan for the future
No migration is a final destination. Better and more flexible options may arrive down the road. Make sure to keep an eye on performance metrics, gauge user satisfaction and operational efficiency, and stay abreast of new developments in multicloud technology to be aware of the options out there.
The future may simply involve adding more storage capacity, services, features, or redundant access paths to an existing multicloud environment, or it may entail a whole new migration.
This article was originally published in September 2022. It was updated by Antony Peyton in July 2025.