Originally published on Towards AI.

Should we move to AWS, Azure, or GCP? Do we need a hybrid architecture? Is multicloud the right long-term strategy? How quickly can we modernize legacy workloads?

These are important questions. Yet they often overshadow a decision that can have just as much impact on the outcome of a migration: choosing the partner who will help execute it.

When organizations look back on migrations that exceeded budgets or missed deadlines, the story is rarely about a lack of cloud capability. More often, it’s about whether the people leading the migration understood the environment they were moving into, the business they were supporting, and the operational realities waiting on the other side of go-live.

That’s a risky imbalance.

A cloud migration partner does more than move workloads from one environment to another. Their decisions influence migration timelines, governance models, cost visibility, operational readiness, and the experience of the teams that inherit the environment after launch.

If you’re evaluating partners for an upcoming migration, there are a few signals worth paying attention to long before a contract is signed.

Why Cloud Migrations Go Wrong Before Migration Begins

The cloud platforms themselves are mature, proven, and used at massive scale. But if you’ll ask a room full of IT leaders about failed cloud migrations, you’ll hear familiar explanations.

• The timeline was too aggressive.
• Dependencies surfaced late.
• The application architecture was more complex than expected.
• Compliance requirements appeared halfway through the project.
• Teams discovered that critical applications are more interconnected than anyone realized.

They are often symptoms rather than root causes. Problems usually emerge in the gaps between planning and execution.

Many migration challenges can be traced back to decisions made. Specifically, decisions about how the migration is planned, who is responsible for it, and how success is defined.

• The first and most common mistake is evaluating a partner primarily through certifications. Cloud certifications matter, as they demonstrate expertise with a platform’s services, tools, and best practices. What they don’t reveal is whether a team has experience migrating an environment that resembles yours. For example, a manufacturing company moving an ERP platform faces a very different set of challenges than a software company migrating customer-facing applications.
• Another mistake emerges when migration planning focuses almost exclusively on infrastructure. The conversation becomes centered on servers, storage, networking, and timelines, while business processes receive less attention. Unfortunately, business processes are often where the most expensive surprises are hiding.

An application exchanges data with other systems, supports multiple departments, and often serves workflows that have evolved over many years. When those relationships aren’t fully understood, migration teams discover them in the middle of execution, usually when changes become significantly more expensive.

Three Signals You’re Evaluating the Wrong Things

Over the years, a few patterns tend to show up when organizations focus on the wrong evaluation criteria.

Signal #1: Every conversation revolves around tools and technologies

They should absolutely be part of the discussion. The problem arises when it’s the only discussion. If every meeting centers on cloud services, migration tools, and platform capabilities, you’re only seeing part of the picture. A migration is ultimately a business initiative supported by technology, not the other way around.

A partner should be asking questions about operational dependencies, critical business processes, reporting requirements, regulatory obligations, and acceptable downtime windows. Those conversations often reveal more about migration complexity than the technical architecture diagram.

Signal #2: Nobody discusses operational ownership

Many migration projects are planned around a finish line. The workloads are migrated, and the project is officially complete; nobody talks about what happens after go-live.

The first few months after a migration are often when organizations discover optimization opportunities, integration issues, user adoption challenges, and operational adjustments that weren’t visible during planning. A partner’s role during that period can be just as important as their role during the migration itself.

If post-migration ownership remains vague throughout the evaluation process, it’s worth digging deeper before moving forward.

Signal #3: Compliance appears late in the discussion

Not all cloud environments are built for the same purpose. A company adopting a hybrid architecture faces different operational considerations than one pursuing a multicloud strategy.

Governance models, networking requirements, security controls, and workload placement decisions can vary significantly depending on the environment being built. Yet many evaluation discussions treat cloud migration as though every destination follows the same blueprint. Understanding the target environment should shape the migration strategy from the beginning.

Questions to Ask Every Cloud Migration Partner

Once the conversation moves beyond certifications, case studies, and platform expertise, the quality of the evaluation often depends on the questions being asked.

The goal isn’t to put a potential partner under pressure. It’s to understand how they think when complexity appears, priorities conflict, and decisions have to be made with incomplete information. Here are a few questions worth bringing into the discussion.

Q1. Have You Migrated Workloads Similar to Ours?

Experience is most valuable when it is relevant. A partner may have completed dozens of migrations and still have limited experience with the specific challenges your organization faces.

Ask for examples that resemble your environment, not just your industry. Pay attention to how they describe the challenges they encountered and how those challenges were resolved. Specific answers tend to reveal genuine experience.

Q2. How Do You Identify and Manage Dependencies?

Dependencies are responsible for a surprising number of migration delays.

Applications exchange data with other systems, rely on shared services, support business processes, and interact with users across multiple departments. The more interconnected the environment, the more important dependency mapping becomes.

A strong partner should be able to explain how they discover, document, validate, and monitor dependencies before migration work begins. The methodology matters as much as the final architecture.

Q3. What Happens if Something Doesn’t Go According to Plan?

Every migration plan includes assumptions. Some of those assumptions will prove accurate. Others won’t. What creates risk is the absence of a structured response when unexpected issues emerge.

Ask how rollback decisions are made. Ask how incidents are escalated. Ask how communication is handled when timelines shift or technical challenges appear. The answers often reveal how prepared a team is for real-world execution rather than ideal scenarios.

Q4. How Do You Approach Governance and Compliance?

Security and compliance discussions should begin early, not after the migration is underway. This is particularly important for organizations operating in regulated industries or managing sensitive customer, financial, or operational data.

The most useful conversations are about how governance requirements influence architecture decisions, access controls, monitoring strategies, and operational processes throughout the migration lifecycle.

Q5. What Does Success Look Like Ninety Days After Go-Live?

This question often produces some of the most revealing answers.

A partner focused solely on delivery milestones may define success as getting workloads operational in the cloud. A partner focused on long-term outcomes is more likely to discuss adoption, performance, operational stability, cost optimization, governance, and knowledge transfer.

The difference may not seem significant during procurement. It becomes very significant once internal teams begin operating the environment on their own.

Conclusion

Cloud migration projects generate a lot of discussion around platforms, architectures, timelines, and budgets. Hybrid architectures, multicloud strategies, governance requirements, cost management initiatives, and ongoing optimization efforts all place demands on the teams responsible for operating the environment long after the migration is complete.

For that reason, evaluating a migration partner should never be reduced to certifications, service catalogs, or pricing discussions alone. For organizations building a more structured evaluation approach, we’ve also put together a detailed framework that explores cloud migration types, common failure points, and the criteria that help distinguish a migration vendor from a long-term cloud partner.

Published via Towards AI

Towards AI Academy

We Build Enterprise-Grade AI. We'll Teach You to Master It Too.

15 engineers. 100,000+ students. Towards AI Academy teaches what actually survives production.

Start free — no commitment:

→ 6-Day Agentic AI Engineering Email Guide — one practical lesson per day

→ Agents Architecture Cheatsheet — 3 years of architecture decisions in 6 pages

Our courses:

→ AI Engineering Certification — 90+ lessons from project selection to deployed product. The most comprehensive practical LLM course out there.

→ Agent Engineering Course — Hands on with production agent architectures, memory, routing, and eval frameworks — built from real enterprise engagements.

→ AI for Work — Understand, evaluate, and apply AI for complex work tasks.

Note: Article content contains the views of the contributing authors and not Towards AI.