MLR Platform Migration — CloudFormation → Terraform
Project: February 2026 — April 2026
Executive Summary
The MLR platform faced increasing instability and operational overhead as ad-hoc console changes and manual hotfixes caused configuration drift. CloudOrbitAI executed a staged migration from CloudFormation to Terraform using a shadow-stack strategy to eliminate downtime, introduce Git-driven infrastructure, and provide repeatable deployment pipelines.
Key outcomes: 40% faster pipeline execution, zero-downtime migration of 120 infrastructure resources, and full IaC ownership with automated drift detection.
Background
The MLR platform is a customer-facing machine learning inference service hosted on AWS. It had grown organically with multiple CloudFormation stacks and bespoke console updates. As the product scaled, operational issues increased: unexpected configuration drift, slow CI pipelines, and no single source of truth for infra changes.
Challenges
- Significant configuration drift caused by manual console changes.
- Fragmented CloudFormation stacks with inconsistent tagging and naming.
- Deployment pipelines that required lengthy warmups and manual steps.
- Risk of downtime during cutover — the platform operates 24/7 for customers.
Approach
We used a low-risk, iterative "shadow-stack" approach:
- Inventory and mapping: automated discovery of resources and tags, producing a canonical inventory and drift report.
- Design: Terraform modules mirroring production, with remote state stored in S3/DR-backed DynamoDB locks.
- Parallel provisioning: deploy Terraform-managed resources in parallel (shadow) without switching traffic.
- Cutover: incrementally switch services to the Terraform-managed endpoints and remove the legacy CloudFormation resources once verified.
- Validation & handover: automated tests, runbooks, and a knowledge transfer session for the MLR operations team.
Technical Details
| Area | Before | After |
|---|---|---|
| State Management | CloudFormation stacks | Terraform with S3 remote state + DynamoDB locks |
| Drift Detection | Manual audits | terraform plan + infrastructure tests in CI |
| CI/CD | Manual steps, long warmups | Git-driven pipelines, automated testing, blue/green cutover |
| Secrets | Inline in templates | AWS Secrets Manager + KMS |
Timeline
- Week 1: Discovery, inventory, and drift report.
- Weeks 2–3: Module development and CI pipeline design.
- Week 4: Shadow-stack provisioning and smoke tests.
- Weeks 5–6: Incremental cutover, monitoring, and rollback testing.
- Week 7: Handover, runbooks, and project closeout.
Outcome & Metrics
- 40% reduction in CI pipeline execution time.
- 0 minutes of downtime during cutover (zero-impact migration).
- 120+ resources migrated to Terraform modules.
- All infrastructure changes now require a Git commit, improving auditability.
- Actionable drift alerts reduced noisy alerts by >80% through better IaC practices.
The platform is now easier to reason about, test, and scale — and the MLR team can reproduce environments reliably in staging and production.
Lessons & Best Practices
- Start with an accurate inventory: automated discovery uncovers hidden drift and undocumented resources.
- Use a shadow-stack for risk mitigation when migrating production infra.
- Store remote state and enforce locking to avoid concurrent apply conflicts.
- Automate validation: include smoke tests and integration checks in CI before cutover.
- Schedule cutovers during low-traffic windows and have clear rollback plans.
Customer Quote
“CloudOrbitAI migrated our infrastructure without any downtime and improved our deployment velocity significantly — their methodical approach gave us confidence at every stage.”
— VP Engineering, MLR Platform
Next Steps / Get Help
If your platform is showing signs of drift, slow deployments, or increasing operational cost, we can run a targeted assessment and propose a low-risk migration plan.