Engagement 04 · Migration
Move your existing Azure environment from portal clicks and ad-hoc scripts into Terraform — without downtime, without rebuilds, and without leaving your team in the dark on day one.
Why this exists
Most teams know they should be using infrastructure-as-code, but the existing environment feels too tangled to touch. Rebuilding from scratch is a multi-month project nobody can justify. The Brownfield Migration takes the practical path: phased imports, careful validation, and a working Terraform repo at the end — with the live environment untouched throughout.
What's included
Full mapping of what exists across subscriptions: compute, networking, identity, data, services. We catalog everything before importing anything.
What to import as-is, what to refactor, what to leave alone. Order of operations, risk callouts, and a clear go/no-go for each resource group.
Codebase organised the way your team will actually use it — not a flat dump of imports. Reusable modules where it makes sense, imports kept lean.
Resources imported in waves. Each wave is plan-clean (no drift) before we move to the next. Live infrastructure stays unchanged.
Remote state with locking, state separation by environment, secrets handling, and a clear pattern for going forward.
Walkthrough of the codebase, how to make changes safely, and a starter set of changes done together. Your team owns it from day one.
Deliverables
Timeline
Inventory, dependencies, risk assessment, import plan. Agreed before any code is written.
Phased imports, drift checks, module refactoring. Live environment unchanged. Plan-clean at every checkpoint.
Walkthrough, training session, and a real change made together. Your team owns the codebase.
FAQ
Will the migration cause downtime?
No. Terraform import doesn't change the resource itself — it just brings it under management. We validate plan-clean at every step before moving on. If we ever need to recreate a resource, we'll flag it explicitly and agree the approach before it happens.
Should we audit first or migrate first?
An Azure Audit & Drift Control first is often the right call — it surfaces what you have, what's risky, and whether migration order should be informed by other priorities. For straightforward environments we can skip ahead.
What about resources we want to redesign?
We import them as-is during this engagement, then tag them for redesign in a follow-up. Migration first, refactor second — it keeps risk contained and progress visible.
Do you import everything?
Not always. Some resources (managed identities, ephemeral resources, third-party integrations) are better handled outside Terraform. We agree the boundary up front.
After this, what's next?
Two common paths: CI/CD & Release Engineering Setup to wire up safe pipelines, or Terraform Standardisation Framework if you have multiple teams about to touch the new codebase.
Next step
Book a 30-minute discovery call. We'll talk through scope, scale, and timing, and confirm pricing before any commitment.
Related engagements