A pragmatic cloud-readiness engagement for a manufacturing group that needed to modernise without ever stopping the line.

The client was a multi-site manufacturing group with operations across three Australian states. Their technology estate was a patchwork: ERP on legacy on-premise infrastructure, plant-floor systems on standalone servers, an aging SCADA environment, and a sales-and-distribution stack that was running in a hyperscale cloud but had never been properly architected for that environment. The board had asked the CIO to develop a five-year technology plan. The CIO wanted to push a meaningful proportion of the estate into the cloud but was unsure how much was genuinely eligible to move and how the OT environments would be governed in a cloud-first world.
We were engaged specifically to produce an honest cloud-readiness assessment — not a vendor-led migration proposal — and to define a security architecture that would satisfy both the CIO and the group's audit and risk committee.
Three things. First, a cloud eligibility assessment for every business application and every supporting infrastructure component. Second, a target cloud architecture with explicit treatment of the OT environment and the boundary between information technology and operational technology. Third, a sequenced migration plan that the CIO could take to the board, with realistic costs, risks and dependencies.
We worked alongside the CIO's team rather than replacing them. We did not replace their internal architects; we provided an independent pair of eyes and a structured framework. We classified every system against six dimensions of cloud suitability: technical fit, security posture, regulatory constraints, cost model, operational impact and skill availability. Each classification was evidence-based and traceable to a documented source.
We deliberately did not produce a single "migrate everything" recommendation. The honest answer for a manufacturing business is that a great deal of the OT estate should never move to public cloud, and that some corporate applications — particularly those tied to plant operations — are best run in a hybrid pattern with critical workloads on private infrastructure and edge connectivity to plant systems.
They told us what we could not move before they told us what we could. That is the order in which this conversation needs to happen, and it is the order in which every other advisor had got it wrong. — Chief Information Officer
The security architecture work was the part the audit and risk committee cared most about. We designed a network segmentation model that created explicit zones for corporate IT, plant OT, and cloud-hosted business systems. We defined an identity and access management approach using modern federation, with privileged access management for plant-floor systems that did not lend themselves to direct cloud identity integration. The result was an architecture that the committee approved without modification on the first review.
The migration plan sequenced workloads over thirty-six months in eight releases. Each release was scoped to a single business capability and priced as a discrete unit. The first release was the decommissioning of two legacy file servers that nobody had been using for months but which had never been formally retired. It was deliberately small and deliberately easy, because the first release of any migration programme sets the tone for everything that follows.


Twelve months into the migration programme the client has delivered the first three releases without an unplanned outage. The CFO's most recent technology finance review shows a 22% reduction in data-centre operating cost against the baseline established at the start of the engagement, ahead of the plan. The full five-year case projects a 60% reduction in total cost of ownership for the cloud-eligible estate when compared with continuing on the legacy infrastructure. We are retained for periodic architecture reviews through the remainder of the migration.
Cloud readiness is rarely a binary question. The interesting work is in the grey zone — applications that could move but probably should not, applications that cannot move today but might in two years, and infrastructure that genuinely benefits from a hybrid pattern. A good cloud strategy respects those distinctions. A bad one treats cloud as a destination rather than a design choice.
If you are weighing whether and how to move workloads into a hyperscale cloud — particularly in a regulated or operationally sensitive environment — we are happy to discuss an honest assessment. We do not accept commissions from cloud providers.