Stop Moving the Plumbing: From Cloud Migration to Data Intelligence

Most organisations reach the end of a cloud migration and run into an uncomfortable question: the infrastructure is new, the invoices have moved from capital to operating expenditure, the servers are someone else's problem — so why does the reporting still feel a quarter behind?

It is a common plateau, and it is worth naming plainly. For most of the last decade the transformation playbook has read the same way: pick a hyperscaler — Azure, AWS or GCP — decommission the on-premise estate, and migrate. That work is necessary. But it is a change of location, not a change of capability. If nothing has changed about how quickly data turns into a decision, the organisation is still steering from the rear-view mirror: delayed dashboards, siloed SaaS exports, and manual CSV extracts describing what happened last quarter rather than what is happening now.

The organisations that break through this plateau are rarely the ones that chose the "best" cloud provider. They are the ones that treated the platform as the beginning of an intelligence strategy rather than the end of an infrastructure project.

The cloud is a location. The platform is the engine.

Choosing a hyperscaler answers the question of where data lives. It does not resolve the architectural compromise most businesses have lived with for years — the trade-off between two systems designed for different jobs:

• Data lakes — inexpensive, scalable storage that holds everything, but is difficult to query reliably for day-to-day business reporting.
• Data warehouses — fast and structured for dashboards, but expensive to scale and poorly suited to advanced AI and machine-learning workloads.

The lakehouse architecture — the model popularised by Databricks and now echoed across the industry — is designed to close that divide by combining the economics of a data lake with query performance closer to a warehouse. For a business running a genuine data estate, three benefits matter most.

Storage-layer portability. Data is held in the organisation's own cloud account in open formats such as Delta Lake and Apache Iceberg. That does not eliminate every form of platform dependency — compute, cataloguing and tooling still involve choices — but it dramatically reduces lock-in at the layer that matters most: the data asset itself remains yours, in an open format, without a costly re-migration if strategy changes.

A disciplined data pipeline (the Medallion model). Data is structured through progressive layers of refinement — a Bronze layer that preserves raw source records exactly as received, a Silver layer of cleaned, conformed and enriched data, and a Gold layer that serves as the governed single source of truth for every business metric. Reporting and AI models draw from the same Gold layer, so the numbers reconcile across every team and every tool. In practice this is where the "why don't these two reports agree?" problem quietly disappears.

Consistent governance across clouds. With a unified governance layer such as Unity Catalog, the same access, lineage and audit controls apply whether the estate sits entirely in Azure, spans AWS, or extends to GCP — without re-architecting each time the strategy evolves.

Where this is heading: fewer pipelines, more autonomy

The reason to care about platform choice is not this quarter's reporting backlog. It is positioning for two shifts that will shape the next several years of competitive advantage.

From brittle pipelines toward unified processing. Traditional data engineering carries a structural fragility. Applications write live data to transactional databases; analytics teams then copy that data — often hours or days later — into warehouses through complex ETL pipelines. Every link is a point of latency, failure and cost. Databricks' newer architecture, which it terms LTAP (Lake Transactional/Analytical Processing) and builds on its Lakebase operational database, aims to collapse that separation by unifying transactional and analytical data at the storage layer. Databricks characterises this as operating on a single governed copy of data; independent commentators have noted the underlying mechanics are more nuanced. The pragmatic point for a business leader is simpler and less contested: the goal is to remove the fragile, lagging sync between the systems that run the business and the systems that analyse it.

From passive dashboards toward agentic assistance. The model of staring at a static dashboard and manually hunting for the cause of an anomaly is beginning to give way. Emerging agentic tools — Databricks' Genie One is one example — are designed to sit on top of a governed data estate, grounded in an organisation's own terminology, KPIs and thresholds rather than a generic knowledge base. The ambition is for these agents not only to surface insight but to act on it: monitoring operations continuously, flagging anomalies, and pushing alerts into everyday tools such as email, Slack or Teams. These capabilities are new and maturing, and enterprise-grade adoption is still early — but the direction is clear, and it rewards organisations whose data foundations are already in order.

What to get right

A capable platform is necessary but not sufficient. In our experience, three considerations separate a durable intelligence capability from an expensive one.

Governance is a design decision, not an afterthought. Unified cataloguing, lineage and role-based access should be built in from the Bronze layer up — not retrofitted once the executive team starts relying on the numbers. This matters increasingly for Australian organisations: automated decision-making transparency obligations under the amended Privacy Act commence in December 2026, and data residency and sovereignty expectations continue to tighten across regulated sectors.

Ownership should be explicit. There is a meaningful difference between an intelligence asset the organisation owns outright — the data, the models and the business logic, held in open formats in its own environment — and a dependency on a black-box service it cannot inspect or move. Managed delivery and genuine ownership are not in tension: the right model is expert hands running an asset the business fully controls.

Sequence matters. The first move is rarely a wholesale migration. It is an honest assessment of where decisions are slow, where numbers disagree, and where the highest-value use cases sit — followed by a targeted build against those, not a re-platforming exercise for its own sake.

The Firehawk view

Whether the business is managing complex logistics in food and distribution, tracking patient allocations in allied health, or reconciling multi-entity ledgers that have outgrown standard accounting software, the objective is the same: frictionless operations, and data that makes a decision rather than merely records one.

The architecture that delivers it is coherent rather than complicated. Siloed applications — accounting platforms such as Sage and Xero, CRMs, HR systems and operational databases — feed a governed lakehouse. Raw data lands in Bronze, is refined through Silver, and resolves into a Gold layer that becomes the single source of truth. From there, two outputs follow: predictive micro-applications for live matching, scheduling and forecasting; and, increasingly, agentic assistants that handle routine data work under human oversight.

The competitive question has moved on. It is no longer "Where is our data hosted?" It is "How quickly can our data make an intelligent decision — and can we trust the answer?"

At Firehawk Analytics, our role is not to help you finish a migration. It is to make sure that once the plumbing is in place, you have the engine — and the governance — to turn it into an advantage.

Considering where your organisation sits on this curve? A short data-intelligence assessment — mapping where decisions are slow, where numbers diverge, and where the highest-value first build lies — is usually the most useful next step. It costs a fraction of a migration and tells you whether you need one.