Cloud Migration Service Providers: How to Pick One 

Key Takeaways

• The proposal that skips discovery is the one that produces the surprise, because discovery is where the dependencies live.
• A migration priced per workload without an assessment is a guess that gets corrected later at your expense.
• Ask who owns the run cost after cutover. Migration success and run-cost success are different outcomes.
• Right-sizing after a month of real usage is where the economics are decided, and it is routinely out of scope.

What separates a good migration proposal from a fast one?

When comparing cloud migration service providers, the fastest proposal is not necessarily the best proposal.

The fastest proposals can be the ones that have compressed or skipped discovery, shifting dependency work into the migration itself. That is not diligence; it is a decision to find the dependencies during the migration instead of before it.

A strong proposal should include:

• A dependency map per application, including scheduled jobs and integrations
• An approach chosen per workload rather than one approach applied to the estate
• Licensing checked for transferability before it becomes a surprise
• A named rollback path with a defined abort point per wave
• Right-sizing after cutover explicitly in or out of scope, stated either way
• Who owns run cost once the project closes

If a proposal contains none of those, the price is not comparable to one that does, however similar the headline figures look.

Which migration approach should they be proposing?

There are four, and a provider proposing one approach for the whole estate has not looked at the estate.

Good cloud migration consulting should result in a different approach for different workloads.

Retirement deserves particular attention. In many estates, some workloads are unused, duplicated or replaceable, and moving them is pure waste.

Definition: Cloud sprawl. Where a lift-and-shift inherits on-premise sizing, so machines provisioned for a peak that occurs twice a year run at that size continuously and are billed by the hour.

The right cloud migration solutions depend on workload criticality, change tolerance and the economics of the destination.

What are the commercial traps?

Migration engagements have a structural incentive problem worth naming: the provider is paid to complete a migration, and run cost afterwards is frequently somebody else’s problem.

None of these makes a provider dishonest. They make the proposals non-comparable, which is why normalising scope before comparing price matters more than the price itself.

What should happen after cutover?

A migration that finishes at cutover has delivered half the outcome. The other half is what it costs and how it behaves in production.

1. Run for a month and collect real usage data rather than projected usage.
2. Right-size against that data, because on-premise sizing may not match actual cloud usage patterns.
3. Restore-test in the new environment. A backup configuration that worked on-premise proves nothing here.
4. Review identity and access, since permissions can be widened during a migration and may not be narrowed afterwards.
5. Decommission the old environment properly, including secure data destruction.
6. Set an ongoing cost review cadence, because cloud spend can drift upward without an ongoing review cadence.

This is where a migration specialist and a managed provider differ. One is optimised to finish; the other has to live with the result.

Our <a href=”/services/managed-hosting-and-cloud/”>Managed Hosting and Cloud</a> covers the operate-and-optimise phase, <a href=”/managed-it-360-services/”>Managed IT 360</a> covers the wider estate the migrated workloads sit within, and <a href=”/security-as-a-service-secaas/”>Security as a Service</a> covers the posture review that should follow any migration.

How should you compare two providers?

Normalise before comparing. Two proposals for the same estate routinely cover different scope, and the cheaper one is frequently the smaller one.

• Put both on the same workload list, including anything one proposes to retire
• Confirm whether discovery is included or billed
• Confirm whether right-sizing is included or a later engagement
• Confirm what documentation you receive and whether you could switch afterwards
• Ask each to name what they would retire rather than move, which tests whether they looked
• Ask who owns run cost at month six

The retirement question is the most diagnostic. A provider who has genuinely assessed your estate can name workloads that should not move. One who has not will propose moving everything.

A good cloud migration partner should be able to explain not only what will move, but what should not move.

Client Case Card

Client environment: A global energy group, 10,000 employees across 36 countries.

Problem: Inconsistent asset visibility and patch state across a highly distributed estate.

Solution: Asset discovery, patch management and remote software deployment standardised.

Result: Cycle-time reduction on downtime events and consistency across all 36 countries.

This evidences large-estate discovery and standardisation capability, which is the foundation of migration planning. It is not presented as a completed cloud migration engagement.

Frequently Asked Questions

1. How long does a cloud migration take?

It is driven by dependency complexity rather than data volume, which is what most people assume. An estate with clean documentation moves far faster than a larger one without it, at the same workload count.

2. Will moving to cloud reduce our costs?

Not automatically, and any provider promising a percentage before seeing your estate is guessing. Cloud makes capacity elastic, and elastic only becomes cheaper if something actively scales it back down. Steady workloads on hardware you already own can sometimes cost more in cloud, depending on utilization, licensing and the full operating cost.

3. Should we move everything?

No, and treating that as the goal is expensive. Some workloads are cheaper and simpler where they are, and retiring unused systems is usually the highest-value part of the whole exercise.

4. What happens to our old hardware?

Decommissioning should be in the plan, including secure data destruction. It is routinely forgotten, and depending on the environment and applicable requirements, it can also have compliance and data-protection implications.