A failed lift-and-shift rarely sends a warning. It shows up as a cloud bill that climbs every quarter and business units that stopped believing the migration would pay off. Before a CIO refactors, repatriates, or renegotiates a contract, the estate needs an honest audit of what actually moved. That audit is the diagnostic a disciplined managed IT service provider runs before touching architecture, and Resolve Tech Solutions treats it as the mandatory first step. The rule is short: you cannot rationalize what you have not inventoried.

Quick Answer

To audit a failed lift-and-shift, work through five ordered steps. Set scope and pull a cost baseline, run automated discovery across on-prem, AWS, and Azure, build a complete workload inventory, classify each workload as cloud-ready or just-moved, then score cost against utilization. The audit is diagnostic only. No right-sizing, repatriation, or refactoring happens until every workload is accounted for.

Table of Contents

• How do you audit a failed lift-and-shift to find what went wrong?
• How do you inventory workloads when the documentation is incomplete?
• What is the difference between a cloud-ready workload and one that was just moved?
• What metrics reveal a hybrid cloud is underperforming relative to its cost?
• When a managed IT service provider should run the audit with you
• How Resolve Tech Solutions helps
• FAQ

How do you audit a failed lift-and-shift to find what went wrong?

Audit the estate in five ordered steps, and resist fixing anything until the last one is done. The usual failure mode is a team that jumps to right-sizing or repatriation, breaks an undocumented dependency, and ends up worse off than before.

• Step 0, set scope and baseline: Name one audit owner and pull three to six months of billing from AWS Cost Explorer and Azure Cost Management as your spend baseline.
• Step 1, run discovery: Use native tooling to enumerate every running resource across on-prem, AWS, and Azure. Machines, not memory, show what is really there.
• Step 2, build the inventory: Turn discovery output into one canonical record per workload: owner, environment, dependencies, tags, cost, and criticality.
• Step 3, classify: Judge each workload as cloud-ready or just-moved so you know what inherited on-prem habits.
• Step 4, score cost against utilization: Rank workloads by spend and by how little of that spend does real work.

Involve the people who hold the context machines cannot: cloud ops, FinOps, application owners, security, and the business-unit sponsors who signed off on the migration. A finished audit produces three things a decision can rest on. A scored workload register. A dependency map. A short list of remediation candidates. Everything downstream, including any enterprise cloud migration rework, depends on getting this inventory right first.

How do you inventory workloads when the documentation is incomplete?

After a rushed migration, the CMDB is usually fiction. Owners changed, resources were spun up by hand, and shadow IT never made it into any record. Stop trusting inherited docs and let the platforms report the truth.

• On AWS: Run AWS Application Discovery Service, AWS Config, and AWS Systems Manager to catalog instances, configurations, and running processes.
• On Azure: Use Azure Migrate, Azure Resource Graph, and Azure Monitor to enumerate resources and their state.
• For hidden dependencies: Turn on VPC and VNet flow logs. Traffic between machines exposes the undocumented connections and shadow workloads a config scan alone will miss.
• For on-prem: Machines see less here, so pair agent-based discovery with short interviews of the app owners who remember why a server exists.

Reconcile every discovered resource against the billing export. Anything you pay for that discovery did not surface is orphaned or untagged, and that is where money leaks. Close the gap with a minimum tag schema, owner, environment, cost-center, and application, so the inventory stays true after the audit ends. It is also the moment to introduce basic FinOps discipline if the first migration skipped it. Spend you cannot attribute is spend you cannot govern.

What is the difference between a cloud-ready workload and one that was just moved?

A cloud-ready workload was refactored to use the cloud the way it was meant to be used. A just-moved workload is the same on-prem virtual machine, running around the clock, now paying premium cloud prices for on-prem inefficiency. Most of the cost and reliability trouble in a stalled migration lives in that second group. This maps onto the 6 Rs of migration in AWS guidance, from rehosting at one end to refactoring at the other.

• Signs a workload was just moved: fixed-size, always-on VMs; self-managed databases on those VMs; no autoscaling; legacy dependencies lifted intact; sizing copied from the old data center.
• Signs a workload is cloud-ready: managed and elastic services such as managed databases and object storage; autoscaling tied to demand; decoupled components; infrastructure defined in Terraform or Bicep; consumption cost that falls when usage falls.

Score each workload on a simple readiness scale so classification feeds later decisions. Just-moved is not always wrong. A compliance freeze, an end-of-life application, or a workload already slated for repatriation can each justify leaving it alone. Make that a decision, not an accident. For teams weighing the fix, the trade-offs in cloud modernization versus lift-and-shift are worth reviewing before committing budget.

What metrics reveal a hybrid cloud is underperforming relative to its cost?

The clearest tell of a failing hybrid estate is low utilization at high cost. Rehosted VMs frequently idle at low single-digit or low double-digit CPU utilization while the invoice keeps climbing. Track the numbers below and the worst offenders name themselves.

• Efficiency: average CPU and memory utilization, count of idle instances, and orphaned volumes, IPs, and snapshots. Red flag: utilization well under a third with spend flat or rising.
• Cost attribution: percentage of untagged or unallocated spend, cost per workload, and cost per business unit. Red flag: a large share of the bill that cannot be tied to an owner.
• Commitment and pricing: on-demand versus reserved instances and savings plans, plus the right-sizing opportunity across oversized instances. Red flag: heavy on-demand usage on steady, predictable workloads.
• Hybrid-specific costs: data egress and inter-cloud transfer charges, and capacity duplicated across on-prem and cloud. Red flag: egress line items nobody can explain.

Sort by biggest cost and lowest utilization first, and you have a prioritized remediation shortlist instead of a guess. These signals also bury a thin cloud ops team in noise. If your engineers already feel like they are drowning in alerts, the metrics usually explain why.

When a managed IT service provider should run the audit with you

Most in-house teams can define these steps. Fewer have the bandwidth to run them across a fragmented AWS and Azure estate while keeping the lights on. That gap, not raw skill, is where a managed IT service provider earns its place, and the right one does not park extra bodies next to your team and call it help. Co-managed cloud is a division of responsibility with owned outcomes and SLAs, where the provider owns the audit and the operations that follow. That is the opposite of the traditional model of managed cloud that keeps failing mid-market enterprises, which fails through activity without accountability.

How Resolve Tech Solutions helps

Resolve Tech Solutions runs this audit as the front end of its Resolve Tech Solutions cloud managed services, a rationalization-first practice spanning co-managed, hybrid, and fully managed models across AWS, Azure, and Google Cloud. The team inventories and scores workloads first, then handles migration rework and ongoing operations, with exit terms and runbook and infrastructure-as-code handover written into the engagement so you are never locked in. With 25-plus years in enterprise IT and large virtualized estates under management for regulated industries, the model sits alongside a thin ops team rather than replacing it.

Want to know which workloads are quietly costing you the most?

Talk to an expert

FAQ

What is the first step in auditing a failed cloud migration?

Set scope and pull a spend baseline before anything else. Name one audit owner and export three to six months of billing from AWS Cost Explorer and Azure Cost Management. That baseline is what every later finding, from idle capacity to untagged spend, gets measured against.

How do you find undocumented workloads in a hybrid cloud?

Turn on VPC and VNet flow logs and run native discovery tools like AWS Application Discovery Service and Azure Migrate. Traffic between machines and platform-level enumeration expose the shadow workloads and orphaned resources an outdated CMDB will never show you.

What does cloud-ready mean versus lifted and shifted?

Cloud-ready means a workload was refactored to use elastic, managed, consumption-based services and defined in code. Lifted and shifted, or just-moved, means the same always-on VM was rehosted without change. Just-moved workloads carry most of the overspend in a stalled migration.

How do you know if your cloud spend is being wasted?

Look for low utilization at high cost. Idle instances, oversized VMs, orphaned volumes and IPs, unexplained data egress, and a large share of untagged spend all signal waste. When CPU utilization sits well under a third and the bill still climbs, the estate is paying cloud prices for on-prem habits.

Should you fix workloads during the audit?

No. The audit is diagnostic only. Right-sizing or repatriating before the inventory is complete is how teams break undocumented dependencies. Finish the scored register, the dependency map, and the cost-versus-utilization ranking first, then remediate in priority order.