How to handle a multicloud migration: Step-by-step guide

Cloud computing has been a staple of many organizations for years, offering an array of online services such as collaboration, communication, telephony, data storage and backup, CRM tools and more; every technological element needed to run a business. The cloud has served in a particularly useful role as of late since 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 and focus by opting to utilize multiple providers of multicloud technology.

According to Faction, “today, 92 percent of organizations have a multicloud strategy in place or underway, and 82% of large enterprises have adopted a hybrid cloud infrastructure. On average, organizations are using 2.6 public and 2.7 private clouds.”

Furthermore, Faction cites Flexera’s 2022 State of the Cloud Report which “shows that more than a third of enterprises (37%) report annual spending on cloud computing exceeding $12 million.” Clearly cloud is a significant investment for organizations both in funding and skilled personnel resources needed to navigate these waters.

Indeed, as Faction points out, “Multi-cloud trends for 2023 will focus less on the initial adoption of multi-cloud environments but instead on the continued growth, efforts to control costs, security, and matching the right applications to cloud services.”

SEE: Hiring Kit: Cloud Engineer (TechRepublic Premium)

Jump to:

Types of cloud platforms

There are four main types of cloud computing:

• Private Cloud: A cloud environment dedicated to a single user, group or organization which can be on- or off-premises
• Public Cloud: A cloud environment dedicated to multiple users, group or organizations which can be on- or off-premises
• Hybrid Cloud: 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 (IaaS) offers standard compute, storage and network resources on a demand-based scale.
• Platforms as a service (PaaS) offers software development and deployment resources.
• Software as a service (SaaS) offers software distribution to end users.

What is multicloud?

Multicloud is a concept involving two or more cloud service providers being used for various business functions. For example, one vendor such as Microsoft might offer collaboration and messaging, and another vendor such as Google might provide data analytics services.

A multicloud can also be a hybrid cloud and vice versa, but these terms are not interchangeable; multicloud involves a more diverse array of providers.

Why adopt a multicloud approach?

The primary advantage of multicloud is to spread your company eggs across multiple baskets, so to speak. Risk is reduced when you reduce a single point of failure as well as 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.

Intuz states that 93% of enterprise organizations (1,000 employers or more) rely on multicloud solutions, emphasizing the value and versatility of such implementations.

In order to yield the advantages of a multicloud strategy, a multicloud migration is needed to transfer accounts, services, data or other elements of the business.

SEE: What you need to know about multicloud adoption (TechRepublic)

What is a multicloud migration?

A multicloud migration is the process of migrating 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.

Steps of a multicloud migration integration

The Faction article referenced contains many interesting observations and statistics regarding multicloud operations with some good details about the growth and capabilities of certain vendors. The purpose of this article is not to promote or reference a specific vendor but rather to lay out the steps involved with a multicloud migration which will apply to any vendor.

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 including multicloud technology

The first order of business is to determine exactly what you want out of a multicloud platform; 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

The next step is to determine what sort of funding you have to work with and match this against the estimated costs of the new platform based on your expectations as to what it will provide you. 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 utilize to help provide finance and management a baseline as to what they should expect to allocate for this new environment, 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 utilize or make decisions regarding the proposed multicloud platform.

Each individual should be assigned a role which reflects upon the multicloud migration, 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 to plan to migrate only active accounts so as to save time and headaches.

Ensure data is valid

Also, assuming the intent is to migrate data to multicloud environments, make sure only valid, actively used data is to be migrated. Migrating 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 transfer to a multicloud environment. Don’t waste time fixating on a web server no longer being utilized or a tertiary Domain Name System (DNS) server which was unnecessarily implemented. Most likely, your focus will be on messaging and communication, collaboration, company portals, data and infrastructural services.

Take inventory of what you need to migrate

For most companies this would likely entail users; data; and certain services such as email, file storage and collaboration functions. If you’re planning to utilize platform as a service (PaaS), you’ll have to factor in your development environment.

For infrastructure as a service (IaaS), include infrastructural components like VPNs, DNS, DHCP (Dynamic Host Configuration Protocol) and other back-end structures. For software as a service (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, but determine which is the most important versus less important resources to move in order to establish the migration priority. 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 to multicloud.

Ideally, the accounts and permissions can remain intact, but if these need to be created anew, gather reports of your existing layout—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 (SLA) 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 selected in the prior step 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—anything you intend to migrate. For instance, if you were looking at Microsoft, users might end up in Office 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 multicloud 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 (MFA) 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 test and 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 during migration and after

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 thirty 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 data.

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, or 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. For example, for a user population of 1,000 employees, 100 employees may be moved over across 10 days.

The documentation should be laid out in a frequently asked questions (FAQ) format and include a migration timeline as well as contacts for internal and external support. A checklist for users to follow to confirm full access and functionality is also preferable. Live tutorials are also 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, as it were, 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 multicloud 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 or 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 as a resource 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, but 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 for company resources; 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 multicloud migration depending on circumstances.