Once you have a clear picture of your current infrastructure, the next question is how to get from here to there without breaking anything along the way.
This is Part 2 in our series on legacy infrastructure modernization. In Part 1, we covered the audit phase: what AI agents surface when they analyze organically grown cloud environments. Here we get into the rebuild itself and the moments where our team’s guidance shaped what the AI produced.
Infrastructure-as-Code from the Ground Up
Rather than retrofitting security onto the existing environment, which introduces risk to live services, we used a blue/green deployment strategy: build the replacement alongside the old environment, validate it fully, then migrate. The AI agent generated a complete infrastructure-as-code definition for the new environment, incorporating modern architectural patterns across four areas.
Resource compartments gave each functional area its own administrative boundary. Networking, compute, storage, and security each carry their own access policies built on least-privilege principles, making permission management explicit and auditable.
Three-tier network segmentation placed web-facing instances in a public subnet, with private subnets for application and data tiers. Gateways handle controlled egress for internal services without exposing them to the internet.
Per-workload security groups replaced the shared rule set. Each service gets its own group scoped to exactly what it needs. A web server’s rules are completely separate from a database’s.
Reserved static IPs ensure that public-facing services keep the same address across instance restarts, replacements, and scaling events. DNS records never need to change when infrastructure does.
The AI agent produced the full definition, handling modules for compartments, networking, compute, and storage, then managed the provisioning sequence. What typically takes days of documentation and console configuration was completed in hours, with a version-controlled, fully auditable codebase as the result.
Where Our Team Shaped the Output
An AI agent working from best-practice defaults will produce a technically correct architecture. But technically correct and operationally right aren’t always the same thing. Several decisions in this project required our team’s input: the kind of context that comes from knowing the workload, the budget, and how the environment actually operates.
Cost-Based Network Architecture
The initial design placed all instances behind a managed load balancer, which is the conventional pattern for production web infrastructure. We evaluated the trade-off and determined that for this workload profile, a managed load balancer added cost and operational complexity that wasn’t justified. Traffic proxied through a CDN directly to reserved IPs on public-facing instances gave us the same resilience at a fraction of the cost.
The AI adapted immediately, restructuring the network module, updating security rules, and repositioning instances in the topology. The key was that we asked the question. Defaults exist for good reasons, but they’re not always the right fit.
Reserved vs. Ephemeral IP Addresses
Cloud providers assign public IPs dynamically by default, what’s known as an ephemeral IP. It works fine until an instance reboots and returns with a different address, at which point anything pointing at the old IP breaks until DNS propagates.
We specified that all public-facing instances needed reserved IPs, addresses that persist independently of the instance lifecycle. The fix was a single resource type in the IaC definition, but the instruction had to come from us. It’s the kind of operational detail that matters in production and gets decided by experience rather than defaults.
The Non-Destructive Principle
The most important directive we set was also the simplest: never delete or overwrite existing configurations. The live environment runs throughout the entire migration. Credentials, keys, network configurations — the AI was instructed to verify existence before touching anything and to treat the legacy environment as strictly read-only.
Migration happens one service at a time via DNS changes rather than infrastructure swaps. If something doesn’t behave as expected in the new environment, rolling back is a DNS record change, not a rebuild. The old environment stays intact until every service is validated and stable on the new infrastructure.
This principle isn’t about being cautious. It’s about being precise. Moving fast with infrastructure is fine when you have a clean rollback path. You build that path by not destroying things until you’re certain you don’t need them.
In Part 3, we cover the real-time data replication architecture we designed alongside the infrastructure rebuild and the full six-step methodology we use for legacy-to-modern migrations.