Writing

Westpac's Adapt is a controlled migration pattern, not a destination

When a bank consolidates 285 source systems into a single governed data platform, it's worth paying attention. Westpac's Adapt, built on Azure, migrated a petabyte of data and consolidated 14,000 pipelines. The scale alone tells you this was not a small experiment. It was a deliberate bet on a unified way of managing data, and that bet deserves a closer look.

That's not a lift-and-shift; it's an operational redesign.

I keep coming back to that phrase because it captures what most consolidation projects miss. The goal is not to move data from one place to another. The goal is to change how the organisation works with data day to day. Adapt's pairing with a Snowflake intelligence layer to run advanced AI models on data at rest, without moving data, is exactly the kind of architecture enterprises need to make AI practical at scale. That design choice removes a whole class of problems around copying data between systems.

The case for Adapt

The most compelling part of Adapt is not the technology stack itself but what committing to one platform forces an organisation to do. Consolidating 285 sources and 14,000 pipelines means you stop treating data integration as a series of ad hoc projects and start treating it as a governed product. That shift in mindset is what makes advanced AI practical. When your data lives in one place, with consistent controls and lineage, model teams can spend less time hunting for data and more time building. Running inference where the data already sits, on Snowflake, avoids egress and re-copy costs. In regulated industries, that matters a lot.

The risks at this scale

But scale cuts both ways. Fourteen thousand pipelines is a lot of moving parts. The more you centralise, the more you risk creating a bottleneck that slows down teams who need to ship quickly. Governance, done poorly, becomes a gate rather than a guardrail. Developer autonomy suffers, and consolidation efforts stall. There's also a cost question. Snowflake as an intelligence layer isn't free, and without clear model ownership, organisations can end up paying for compute that no one is accountable for using well. Not every AI workload belongs inside the same environment. Some are better off outside, closer to the team that owns the outcome.

Where I'd land

I'd treat Adapt less as a destination and more as a controlled migration pattern. The Snowflake layer is smart because it lets you run inference on data at rest and avoid egress and re-copy costs. But I'd push for a thin, event-driven abstraction between the Azure platform and the intelligence layer. Model teams need room to iterate without coupling their work to pipeline schedules. If a model needs to react to a new batch of data, it should be able to do so through events, not by waiting for a nightly job or by asking a central team for access.

There's a counterexample worth keeping in mind. In heavily regulated insurance data estates, a separate feature store often persists even after a unified platform is in place. That's because unified governance doesn't automatically satisfy model-specific lineage and consent rules. Feature stores carry their own audit trails and policy controls that a general platform might not express. So I'd keep a policy-driven split instead of forcing every workload into one pipe. Some things belong in the platform; some things belong beside it. The trick is knowing which is which, and building the interface between them so that neither side has to compromise on how it operates.

The lesson I'd take from Adapt is not that one platform is the answer. It's that the pattern of controlled migration, with a deliberate split between governed data and model-specific compute, is what lets large organisations get value from AI without freezing in place. That's a more useful target than any single vendor stack.

Originally covered at itnews.com.au ↗