Case Study: Significant Saving from Discovering a Cloud-Unsuitable Legacy Workload

Overview

The customer didn’t have clarity around cloud costs, the internal engineers performed fundamental platform driven cost optimisation activities and vendor engagements. One among many large enterprises who migrated their on-premises workloads into the cloud without taking into consideration the advantages of variable cloud model, treating it as another hosting data center.

Among other wins we discovered a traditional VM worker hammering cloud file system, constantly walking through folders, checking files, and reading metadata.

The application generated millions of storage operations. This increased the direct storage transaction cost, but it also pushed up the cost of other services around it.

The main affected areas were:

• Storage transactions
• Defender for Storage
• Bandwidth
• Log Analytics

The customer was effectively paying several times for the same inefficient pattern: once for the storage activity itself, then again for security monitoring, logging, and related cloud operations.

Why it was missed

Nothing looked obviously broken.

The application was still doing what the business needed. The storage accounts were active. Defender was working. Storage logs were being collected, nothing suspicious but metrics pointed us in the right direction.

Because the cost was spread across several services, it blended into the normal cloud baseline years ago.

This is common in enterprise cloud environments. A legacy workload gets moved into the cloud, the requirement is met, and the cost becomes accepted and absorbed over time. People may optimise around the edges with reservations, but the original workload pattern is rarely challenged.

In this case, the customer was paying for real consumption.

The problem was that a large part of that consumption did not need to exist in that form.

What CloudQbit did

We reviewed the affected services together instead of treating them as separate cost issues.

The investigation connected the storage, Defender, bandwidth, and logging cost back to the same source: excessive file share activity from the legacy application.

From there, we identified a more suitable technical approach using existing technology already available to the customer. The aim was obviously not to remove the process. The aim was to deliver the same outcome without generating unnecessary cloud operations = cost.

Then we helped the internal team take the recommendation through architecture review, technical validation, change control, and execution.

This mattered because the value was not in simply finding the issue. The value came from helping the internal team make the change safely and actually reduce the cost.

Result

The current operating pattern was converted into an optimisation opportunity to reduce 90% of the cost for that workload.

The customer could keep the business outcome, maintain visibility, and avoid continuing to pay for excessive storage operations and the related unnecessary costs.

We are sharing this example to show an example of what your native platform recommendations or even advanced AI cost dashboards can’t do for you. It required tracing cloud spend back to workload behaviour, understanding why the cost existed, and helping the team deliver significant cost reduction without losing anything.