From colocation to cloud: The migration starts before the migration

For many organizations, the conversation around moving from colocation to cloud starts with a fairly simple question:

“What would it cost to move our environment to the cloud?”

It’s a reasonable question, but it may not be the right place to start.

A successful cloud migration is not simply about moving servers from one location to another. Before making a decision on where workloads should live, organizations need to understand what they have today, how those workloads operate, what the business actually needs, and what the economics look like over time.

In other words, the migration itself should be one of the last steps in the process—not the first.

This is particularly important today as organizations evaluate multiple options. Staying in colocation may still make sense for some workloads. Others may be better suited for public cloud, while private cloud—either multi-tenant or dedicated—can provide another path.

The right answer is often not “move everything to the cloud.” The right answer is finding the right home for each workload.

Start with discovery

The first step is understanding the environment that exists today.

That sounds straightforward, but many organizations don’t have a complete picture of their infrastructure. They may know how many servers they have, but not necessarily how those servers are being utilized. They may know how much storage they own, but not which applications are driving the highest performance requirements.

A meaningful discovery process should look at the entire environment, including:

• Servers and virtual machines
• CPU and memory utilization
• Storage capacity and performance
• IOPS and application requirements
• Network utilization and connectivity
• Applications and databases
• Production and non-production workloads
• Backup and disaster recovery
• Security and compliance requirements
• Hardware and software lifecycle
• Licensing and upcoming renewals
• Application dependencies

The dependency piece is particularly important.

It’s one thing to know that you have 300 VMs. It’s another to understand which VMs support the ERP system, which databases those applications depend on, and what has to happen first when those systems are brought back online.

That information becomes critical when it’s time to build a migration plan.

Not every workload should be treated the same

Once the environment is understood, the next question becomes: What should actually move?

This is where workload assessment becomes important.

Some applications may be ready to move with little or no modification. Others may require remediation or modernization. And there may be workloads that simply make more sense staying where they are.

For example, a VMware-based application with established dependencies may be a good candidate for a private cloud migration without fundamentally changing how the application operates.

A legacy application tied to specialized hardware may be a very different story.

Likewise, an application that could benefit from cloud-native capabilities may be better suited for a public cloud platform rather than simply being moved from one virtual infrastructure to another.

The goal should be to categorize workloads based on their requirements rather than trying to force the entire environment into one destination.

This is one of the areas where data-driven workload observability can be extremely valuable. Instead of making decisions based on assumptions or a snapshot of the environment, organizations can use actual utilization and performance data to determine what they really need.

A cloud assessment should answer questions like:

What do we have? What are we actually using? What does the business need? And what is the best place for each workload to operate?

Then determine the right destination

Once the workloads have been assessed, it’s time to evaluate the different cloud options.

And this is where the migration methodology can change significantly depending on the destination.

Public Cloud

Moving to a hyperscaler such as AWS, Azure, or Google Cloud can provide tremendous flexibility and access to a broad range of cloud-native services.

But organizations need to understand that moving to public cloud may involve more than simply moving VMs.

Depending on the application, there may be opportunities—or requirements—to re-platform or refactor workloads. Networking, identity, security, governance, cloud management and data transfer costs all need to be considered.

The IT organization’s operational model also matters. Does the team have the skills and resources required to manage a hyperscale environment? Does the organization want to operate that infrastructure itself?

Public cloud can be a great destination, but it should be selected because it aligns with the workload and business requirements—not simply because it is considered the default definition of “cloud.”

Multi-Tenant Private Cloud

For organizations looking for a more straightforward transition from colocation to cloud, multi-tenant private cloud can be an attractive option.

This can be particularly relevant for VMware environments where the organization wants to move away from owning and maintaining physical infrastructure without introducing a completely different operating model.

The infrastructure is shared, but customers can retain familiar virtualization and management concepts.

The assessment still needs to focus on sizing, performance, security, connectivity and workload requirements. The difference is that the organization may be able to move to a cloud operating model without requiring significant application changes.

Dedicated Private Cloud

There are also environments where dedicated infrastructure makes more sense.

Organizations with specific compliance requirements, specialized configurations, predictable performance requirements or a desire for greater control may benefit from a single-tenant private cloud model.

This can also be compelling for organizations approaching a major hardware refresh.

Instead of making another significant capital investment in servers, storage and infrastructure, the organization can consider moving those workloads to dedicated cloud infrastructure and shifting more of the responsibility for the underlying infrastructure to the provider.

The applications may not need to fundamentally change. The operating model does.

Don’t forget the business case

Technology is only part of the decision.

A proper analysis should compare the cost of staying in colocation with the alternatives, and it should go well beyond the monthly cloud bill.

Consider hardware refreshes, colocation space and power, VMware and other software licensing, support and maintenance, backup and disaster recovery, network connectivity, IT administration, security, migration costs and expected growth.

Looking at a three- or five-year total cost of ownership can provide a much different picture than simply comparing today’s infrastructure bill with a monthly cloud estimate.

There is also value in eliminating future hardware refresh cycles and moving from a model that requires periodic capital investments toward a more predictable operating expense model.

The objective isn’t necessarily to find the lowest monthly number.

It’s to understand the total cost and value of each option.

Build the migration plan

Only after discovery, workload assessment and destination selection should the actual migration plan begin.

Rather than treating the project as one massive event, workloads should be organized into logical migration waves.

Start with the appropriate workloads. Establish dependencies. Define the migration method. Build in validation and rollback procedures. Determine what success looks like before the first production workload moves.

This approach reduces risk and provides an opportunity to learn from each migration wave before moving on to the next.

And perhaps most importantly, it gives the organization a plan.

The first step doesn’t have to be a commitment

One of the challenges organizations face is knowing where to start without immediately committing to a particular cloud platform or migration strategy.

A structured workshop or assessment can help.

For example, the Flexential Fast-Track Cloud Assessment is designed to provide a data-driven look at an organization’s IT environment and develop recommendations based on its specific workloads. The workshop is designed to support organizations whether they ultimately remain on-premises, move to private or public cloud, or pursue a hybrid strategy.

The deliverable is intended to provide a better understanding of the current environment, workload recommendations and actionable guidance around what should be retained or migrated.

That’s really the point.

Cloud migration shouldn’t start with a cloud. It should start with understanding the business and the workloads.

Once you know what you have, what you’re actually using, what the business requires and where each workload belongs, the migration becomes much more than a technology project.

It becomes a business decision backed by data.

And that is where the foundation for a successful colo-to-cloud migration really begins.

Find the right cloud for your workloads

Your business needs—not a predetermined destination—should guide your next move. Explore our cloud services to see what’s possible for your workloads, or accelerate your cloud journey with a Fast-Track Cloud Assessment.