Cloud, done properly.

We’re platform-agnostic. The right answer depends on the workload, the in-house skill base, the licensing position, and where the data sits. Azure is the most common destination for our clients because the majority are anchored in Microsoft 365 and the identity + licensing economics line up. But AWS remains the right call for many workloads, and we run engagements there with Microsoft-certified and AWS-certified architects on both sides. GCP we use less often, but we’ll work in it where a client already has a footprint or where a specific service (BigQuery, Vertex) is the deciding factor. The honest limitation: we don’t try to be everything to everyone. If your stack is heavily AWS-native and complex, we’ll tell you up-front whether we’re the right fit.

By default, yes. We deploy to Australian regions (Azure Australia East/Southeast, AWS Sydney) unless there’s a specific reason to do otherwise. For clients with Privacy Act, APRA, or contractual sovereignty obligations, that’s the only sensible starting point. Where a particular workload genuinely benefits from a non-AU region — say, a global SaaS integration or a service that’s only offered in US regions — we route that workload separately and document it, so your sovereignty posture is explicit rather than accidental. The limitation worth naming: a few Microsoft and AWS services don’t have AU regional parity yet. If your shortlist depends on one of them, we’ll flag it in the design phase, not after migration.

It gets decommissioned on a documented schedule, not turned off in a panic. Every migration plan includes a per-workload cutover and a per-asset decommissioning timeline: when the workload moves, when the on-prem service stays live as a fallback, when it’s switched off, and when the hardware is physically retired. Servers, storage, hypervisors, and the supporting network kit are tracked through to either redeployment, resale, or secure disposal with data-destruction certificates. Licensing — Windows Server, SQL, VMware, backup — is reviewed at the same time so you’re not paying for shelfware after cutover. The honest part: decommissioning takes longer than people expect. We plan for a 60–90 day stabilisation window after the last workload moves before final shutdown.

It depends entirely on scope. A single server or a small file-share migration is usually 4–8 weeks end-to-end, including the assessment, build, cutover, and stabilisation. A full IT-estate migration — multiple servers, identity, file services, line-of-business apps, dependency mapping, user training — typically lands in the 6–18 month range depending on how much refactoring you want done versus a straight lift-and-shift. We’d rather quote a realistic timeline than a fast one: most migrations that go sideways do so because the discovery phase was rushed. Every engagement starts with a 1–2 week assessment that produces a phased plan with named workloads, dependencies, and cutover dates before any cloud spend begins.