Cloud Migration Tools That Earn Their Place

A migration team meets its first real fork at the moment the first tool is bought. One course is to make the receiving cloud's own migration hub the spine of the work. Another is to fund an independent discovery and telemetry layer first, and settle the platform question afterwards. A third opens when one application suite dominates the workload and its vendor ships a mover built for that suite alone. The first is cheap to start and shaped by a single provider. The second costs money from the first month and keeps watching after go-live. The third is narrow, decisive, and close to useless away from its own product. Putting the three side by side is the work of this page, and the question it settles is which of them deserves money in a migration that cannot absorb a surprise.

Three entrants, each a different kind of instrument

The vendor's own migration hub comes first. Azure Migrate is the instance most teams meet first: Microsoft presents it as discovery, assessment and orchestration across agents and tools, with 6R treatment choices and a dependency map. Google Cloud's Migration Center documents a comparable family, including Migrate to Virtual Machines for lift and shift, Migrate to Containers for replatforming, and Datastream and Database Migration Service for data movement. A tool of this kind knows the platform it was built for. It gives most when the platform is already settled and the workload fits within its supported matrix.

The telemetry layer comes next. Datadog is the worked example. Its cloud migration page reports unified visibility across public cloud, on-premises and hybrid environments, with service maps, network maps and host maps used to trace data flow between components. Nothing moves because of it. It tells you what is running, what depends on what, and whether the migrated service still meets its performance target while the old one is still carrying production traffic.

The suite migrator comes last, and it is the narrowest. Atlassian's Cloud Transformation Guide is the instance: Portfolio Insights assesses the Atlassian footprint, and the Cloud Migration Assistants move Jira, Jira Service Management, Confluence and Bitbucket data. A tool of this kind exists because one product family has enough internal structure that general infrastructure tooling misses what matters: app compatibility, custom fields, workflows, user counts and data residency. It is excellent within that boundary and irrelevant outside it.

What each can see before a platform is picked

Discovery reach is the first separator, because a tool that cannot see a dependency will not protect it. Azure Migrate discovers infrastructure, applications and data, and its application awareness groups tagged resources that depend on each other so they can be placed together for cost and performance. Google Cloud's tooling is explicit in the same way: lift and shift, replatform and refactor each get specified tools and stated source-and-target pairings.

Datadog's contribution here is different. It can instrument the old environment and the new one at the same time, which matters when cutover is not a single afternoon. The Datadog cloud migration page reports that it retains performance metrics at full granularity for 15 months, so a before-and-after picture rests on more than a fortnight's sample. Atlassian's Portfolio Insights gives one view across Cloud and Data Center, but that view ends at the Atlassian footprint. On discovery reach the vendor hub leads within its own cloud, the telemetry layer leads across mixed environments, and the suite migrator leads only where the suite is the whole job.

Whether the tool can support a refusal

A tooling choice for a regulated migration turns on whether the tool can stand behind a decision to leave a workload where it is. ANS lists workload suitability among its service outputs, identifying which workloads should move to cloud and which are better kept on-premises or in a hybrid arrangement. The NHS cloud migration guidance says much the same from the other direction: cloud-first does not mean the whole data centre has to move, because on-premises kit can be the right answer where cloud cannot meet a regulatory or latency requirement. Akita adds that not every application fits the cloud and some need redeveloping before they do. Those are judgements, and they need one responsible engineer to approve them.

Azure Migrate can yield readiness and cost insights and line workloads up against 6R treatments, but it cannot decide whether business value justifies the transformation or whether a regulator will accept the chosen platform. Datadog can prove what a workload actually does, which is strong evidence when someone claims a dependency is trivial, but it makes no placement recommendation. Atlassian's assessment can show which Data Center instances are ready and which apps need attention, but it cannot refuse a non-Atlassian workload. On refusal the vendor hub supplies options, the telemetry layer supplies evidence, and the suite migrator supplies a narrow compatibility verdict.

Cost shape across the dual-run window

The cost of a migration tool is its list price multiplied by the time both environments run together, plus the engineering hours spent feeding it and reading it. The Cortex guide reported that an Informatica study found 84% of cloud migrations exceed their budgets or timelines, which is reason enough to model the dual-run window before tooling is chosen. The vendor hub is usually free at the point of use, but it consumes platform resources and engineering attention. The telemetry layer is a recurring metered charge that grows with hosts, containers and custom metrics, and it must be budgeted until the old environment is switched off. The suite migrator is free as an app, but the cloud licence it serves is not.

Assessment services belong beside these tools rather than among them. ANS presents its Cloud Navigator as a four-to-six-week engagement delivering a readiness view, an application migration roadmap, ROI and TCO analysis, a target architecture and board-ready recommendations. Akita frames the same commercial risk around cost management, data security management and continued operation, and commits to keeping disruption to a minimum. Neither is a migration tool in the narrow sense. Both are ways of buying the judgement a tool cannot supply.

Cutover, and the first three months after go-live

At cutover the three instruments do different jobs. Azure Migrate orchestrates across agents and tools with less manual intervention, so it belongs on the execution path. Datadog watches both sides. Its cloud migration page cites a six-month stretch at Neto when legacy and cloud infrastructure ran side by side while customer assets moved from MySQL to hosted Amazon Aurora databases, with metrics from both environments collected on one platform. Atlassian's assistants move suite data and run their checks, but general cutover orchestration is outside their remit.

After go-live, the vendor hub moves on to optimisation: Azure Migrate's Copilot agents are presented as continuously tuning cost, performance and reliability. Datadog shifts to baselines, alerting and right-sizing, with cost management and performance monitoring in the same platform. Atlassian moves to adoption, administration and app review. The value on this separator is plain: the hub owns the receiving platform's operating model, the telemetry layer owns the evidence of service health, and the suite migrator owns the suite's adoption curve.

The three scored against the same tests

The table below holds each instrument to the same four tests. The metric retention figure in the Datadog column comes from its cloud migration page.

Test	Azure Migrate (vendor hub)	Datadog (independent telemetry)	Atlassian Cloud Migration Assistants (suite mover)
Discovery reach before a platform is picked	Infrastructure, applications and data across the supported Microsoft matrix	Public cloud, on-premises and hybrid, including both sides of a cutover	The Atlassian footprint only, across Cloud and Data Center
Can it stand behind a refusal to move?	Readiness and cost insight, 6R treatment choice, no regulatory judgement	Evidence of live behaviour, no placement recommendation	Compatibility and readiness checks within the suite, no reach beyond it
Cost shape through the dual-run window	Free at the point of use, consumes platform resources and attention	Metered and recurring, scaled by hosts, containers and custom metrics	Free as an app, but tied to the cloud licence it serves
Job at cutover and after go-live	Orchestration on the execution path, then ongoing optimisation	Both sides monitored, then baselines, alerting and right-sizing	Suite data moved and checked, then adoption and administration

The page ends here on purpose. Which of the three you fund first depends on how much of the work sits in one suite, how regulated the workloads are, and whether the platform decision has already been taken. The pages beneath this one take each of those questions in turn: how a workload assessment yields placement rules, how a consultancy engagement differs from a tool purchase, and how the dual-run bill is built before anyone commits to a cutover night.

Sources

The routes open to you

Vendor migration hubs

Teams that have already settled on a platform and have workloads that fit the supported matrix.

Telemetry layers

Mixed environments where unified visibility and performance evidence are required across old and new sites.

Suite migrators

Projects where a specific product family, such as Atlassian, dominates the workload.