LARGE ENTERPRISE
How global enterprise created a repeatable migration factory to cut cloud migration time from a year to under 90 days and save millions
Cloud infrastructure was reverse-engineered into modular, policy-governed infrastructure as code. Case study · September 2026 · Aiden for InfraOps - Cloud-to-Code, M&A cloud integration
Background
A global enterprise that acquires several companies a year used Aiden for InfraOps with Cloud-to-Code to build a migration factory: a repeatable production line that turns an acquired company's undocumented cloud estate into modular, policy-governed Terraform. In a two-week proof of concept, Aiden discovered and codified more than 500 live cloud resources across four environments and two regions, covering 100% of the resources in scope. Work that a team of two would normally take four weeks on was completed by one engineer in about a day, roughly 90% less time. The company expects M&A cloud integration to fall from six to nine months per acquisition to one to two months.
"Sometimes they're like, 'let me get my cousin Kenny on the phone. He has the datacenter in the closet."
"The ROI for acquisitions is not fast enough for our business. We acquire [a] company, we expect to be generating value faster than what we've been doing- where you'll see an ROI in two or three years. I don't think that's good enough"
The problem: cloud migration that takes a year
This customer is a global enterprise that grows partly by acquisition, several companies a year, each arriving with its own cloud footprint. On paper the deal closes and the technology integration begins. In practice the integration is where the value of the deal is fully realized.The estates arrive with documentation that follows different standards. Diagrams are hard to follow, the people who built the infrastructure transition roles, and what is actually running has to be rediscovered from the cloud accounts themselves. Handover, where it happens at all, can be improvised. Nothing can move until the estate has been mapped and turned into code, and until recently that mapping was manual work. Engineers read consoles, ran terraform import a resource at a time, hand-wrote the HCL, and reconciled state against what the applications actually needed.That made every integration a bespoke project rather than a process. A large, complicated estate could absorb a year or more. The platform team could realistically run one integration at a time against a steady acquisition pipeline, so work queued. External systems integrators filled the gap, with costs even reaching up to seven figures per acquisition. Meanwhile, the acquired company was expected to keep operating on infrastructure that had to be lifted & shifted onto the parent's preferred clouds, under internal cloud-usage mandates.
"The AI-assisted infrastructure engineer works for me, because we're not increasing headcount."
"I looked at several different tools, and I kept coming back to StackGen [Aiden] as the one that can give me what I need from a holistic standpoint."
The solution: a migration factory
Rather than staff up for each acquisition, the customer built a migration factory with StackGen: a standing production line that any inbound cloud estate can be fed into, with Aiden for InfraOps - Cloud-to-Code doing the discovery and codification and the customer's own governance framework validating everything before it deploys. Aiden classifies the cloud resources and provides the most logical set of terraform projects and generates the corresponding terraform IaC for them. So what comes out is application-specific rather than one undifferentiated blob. The generated code is not a throwaway prototype. It is a modular IaC ready to be deployed immediately.Underneath, the work is carried out by agents coordinated against the stated goal rather than by a single tool run. Discovery, codification, cutover and validation are handled by different specialised agents drawing on a shared model of the customer's cloud inventory, dependencies, change events, ownership and cost, with approvals, guardrails and an audit trail applied in line rather than bolted on. That shared context is what allows the same platform to keep working the estate after migration instead of handing back a pile of code and stopping. Governance is not a later step. Misconfiguration and compliance policies are applied to imported resources and act as hard deployment gates, so non-compliant infrastructure has to be remediated before anything proceeds. Policies validate against benchmarks including CIS, NIST, FedRAMP and HIPAA alongside the enterprise's own frameworks, which is what lets an acquired company inherit the parent's compliance posture during the integration rather than through a separate remediation programme afterwards. The same policy layer covers drift prevention once the estate is live.
Looking ahead: the factory runs again
The migration factory's value is its repeatability for all future acquisitions / cloud standardization projects. Work is already under way on the company's next major acquisition, which is the first real test of that claim. The team's own expectation has shifted accordingly, from a one to two year project for a large, complicated acquisition to a 30, 60 or 90 day timeline scaled to the estate's complexity.That is where the time freed by the migration work is going. Instead of a decade of integration backlog, the operations team's capacity moves to executing their internal roadmap to grow the business. Extending the platform, and working alongside an agentic assistant that deploys new infrastructure and updates existing code within the policy envelope. The next acquisition, on this model, is another run of the same migration factory, and the developers inside the acquired company get self-service infrastructure sooner than the parent's own teams did.
Results: weeks of migration work done in days
The approach was validated in a two-week proof of concept against a live estate, and it cleared every objective set for it. Aiden discovered and converted more than 500 cloud resources into infrastructure as code, covering 100% of the resources in scope against a target of 90%, spanning four deployment environments for development, QA, staging and production, across two cloud regions. Those resources were across - EKS/EC2/VPC with multiple subnets for AWS cloud accounts. And across AKS/VMSS/VNet for Azure cloud accounts. These layers of resources were then refactored into 30+ application-specific IaC projects, which is what makes independent, parallel deployments possible and moves the estate onto a modern continuous-delivery model rather than reproducing the monolith it arrived at.The headline number is speed. A service reverse-engineering and carve-out that the team would typically give two to four weeks was completed in one day, roughly an 90% reduction in elapsed time. The comparison is starker in effort than in calendar time. The manual version of that task occupies a team of four for one to two weeks; the assisted version took one engineer about a day.Compliance held as a gate throughout. Misconfiguration policies for SOC 2 and GDPR were enforced on every imported resource, and non-compliant resources had to be remediated before deployment could continue, clearing the bar of automated enforcement on at least two of three defined policies. Terraform plans executed successfully. Full pipeline integration was validated manually during the evaluation to keep it fast, and lifts into the customer's CI/CD without rework.
.png)
Ready to standardize your Infrastructure?
If you are carrying an undocumented cloud estate, whether from an acquisition, a datacentre exit, or a move between cloud providers, move between cloud accounts, Aiden for InfraOps - Cloud-to-Code will discover it and codify it into governed Terraform / OpenTofu. Book a technical walkthrough.
