Armakuni Contact us
← All case studies

Its platform lived in someone else's AWS account.
Then the landlord gave notice.

A North American home-inspection company ran its whole production platform inside a reseller's shared AWS environment, built by hand, with no infrastructure as code and no tested recovery. When that support was withdrawn, and another partner had stalled, we signed in two days and had a senior engineering pod working inside two weeks. The pod mapped every dependency, set out a migration plan the CTO signed off, established the company's own AWS operations and stayed on beside its developers.

Before

A shop in someone else's mall.

Then the support ended, and the first plan stalled.

After
8–10 weeksmigration plan, signed off by the CTO
  • The company's own EC2 production environment, with Terraform, managed secrets, WAF and CloudWatch monitoring.

A shop in someone else's mall

The company's franchise application, a Django system, ran on six EC2 instances with about 600 GB in PostgreSQL, plus RabbitMQ, Redis and S3. All of it sat inside a reseller's shared AWS environment, in a VPC it shared with other products.

It had been configured by hand over the years. Deployments were manual, resource naming was inconsistent, backups were manual snapshots with no tested recovery, and the company couldn't see its own cloud bill or security posture end to end.

Then the support ended, and the first plan stalled

The reseller's support was withdrawn on a short timeline. The company had already brought in another partner, which didn't have the DevOps depth for the job, and weeks went by without a workable plan. The company had no in-house DevOps team to do it itself.

Senior engineers first, on day one

What the company needed most was speed with judgment: people senior enough to map the estate live on the first call, decide how to move it, and start the same week. Our solutions architects joined the first calls, mapped the reseller environment with the company's team in the room, because it had been built by hand, its original architect was away, and the exact S3 usage and parts of the network configuration were uncertain, and had the engagement signed within two days.

How we built it

3 decisions, in the order we made them. Each one says what we did and why, with what it did drawn beside it.

  1. Discovery found what the move really involved
  2. Operations on EC2 first, containers after
  3. A pod that works with the developers, not instead of them

Discovery found what the move really involved

Built withDjangoEC2PostgreSQLRedisRabbitMQWAF
Ours, shared, the landlord's Six EC2 instances1PostgreSQL 142ALB and WAF3Certificates4 test cutovers, then the move
The engineering

Moving the Django application meant separating a working business system from infrastructure it shared with other products. The team had to establish which resources belonged to the company, how to move them and who would run the new environment:

  • Application and data: the six EC2 instances on Ubuntu 22.04, PostgreSQL 14 with about 600 GB of data, a three-node Redis 7 cluster and the RabbitMQ dependency, all identified before finalizing the scope.
  • Shared infrastructure: ALB routing, ACM certificates, WAF rules and network access, all of which had to be accounted for in the destination environment.
  • Transfer options: the scoping compared AWS Application Migration Service with account-to-account snapshot sharing. The source team favored snapshots over a VPN or VPC-peering connection, so the shared environment was less exposed.
  • Cutover planning: parallel running and test cutovers before the final maintenance window, with Route 53 cutover and failback designed as an explicit, reversible step.

That produced an eight-to-ten-week migration plan the company's CTO signed off.

Why: in an emergency move, the dangerous resource is the one nobody listed, and mapping it live with the people who know is how you find it.

Operations on EC2 first, containers after

Built withEC2ECSTerraformIAMSecrets ManagerWAF
Moved as it is, onto EC2Terraform, secrets, WAF, logsContainers after
The engineering

The tempting move was to modernize on the way out, onto containers. Delivery notes describe an EC2 production environment established in December instead, with containerization deferred at the application developers' request. That kept the ECS migration out of the immediate infrastructure transition, which was the right order under a deadline.

The engineering work included:

  • Terraform for the infrastructure, so every resource, security group and IAM boundary is in code rather than hand-configured.
  • Secrets Manager and IAM roles to improve how credentials are handled.
  • WAF configuration for application protection.
  • CloudWatch logs, dashboards and custom EC2 CPU and memory metrics, so nobody has to log into individual servers to read production logs.

Moving the platform and re-platforming it in the same window would have doubled what could go wrong, so it moved as it was.

A pod that works with the developers, not instead of them

Built withTerraform
Our podTheir devs RunbooksWhat we learned80 hours a month, together
The engineering

The company chose a "do-with" approach: our engineers work beside its developers and pass on the patterns, runbooks and Terraform as they go. The flexible engineering pod provides 80 hours of engineering a month, drawing on application, CloudOps, DevOps, data and architecture skills week by week, with an extra block of on-call support during stabilization. It runs with weekly updates and milestone reviews, with the CTO as its primary stakeholder.

One cutover rehearsal, end to end

  1. The destination account is built in Terraform: VPC, ALB, WAF rules, ACM certificates and IAM boundaries in place before any data moves.
  2. The PostgreSQL data comes across through the agreed transfer route, while the source keeps running.
  3. RabbitMQ, Redis and S3 are rebuilt in the new account.
  4. The application runs in parallel, and the team checks it against the live system.
  5. A test cutover switches Route 53 to the new environment.
  6. If anything misbehaves, failback is one step, back to the source, and the team tries again before the final maintenance window.

What we'd tell another CTO

1If someone else owns your account, plan the exit before they plan it for you. When it's urgent, put senior engineers on the first call, because mapping the estate live saved weeks here.
2Move first and modernize second: EC2 as it was under the deadline, containers after it. Make the DNS cutover reversible, since failback in one step is what makes a cutover safe to try, and choose the transfer route with the people who own the source, because their appetite for risk is part of the design.

What else changed

  • A signed engagement in two days and a working pod in two weeks, after a stalled start with another partner.
  • An embedded pod, 80 hours a month plus on-call during stabilization, working alongside the company's developers.

What comes next

Preparing ECS and moving the application onto it, once the lead developer is back, to bring down compute cost and operational work. Then more Terraform coverage, and potentially a formal CI/CD pipeline, on the same retained pod.

How we'd do it today

This project came before our current offers. Here's how we'd approach the same work now.

AWS Transform's AI agents would map which servers talk to which from the network itself, and our AI agents would read what the network can't show: config files, scheduled jobs, scripts and connection strings with an address written into them, plus the tickets and documents that say who owns what. Our engineers would check every finding with the person who'd know, and the accounts, identity, logging, backup and network link would be built as code with AWS Control Tower and AWS Organizations before the first server moved.

Servers would copy across continuously while the old ones keep running, a test copy would run on AWS before each cutover, and the old server would be switched off but kept until the new one had run a month-end. After the cutover, the retained pod would become the full managed service, run by one team. Production would be watched by what inspectors and their customers feel, with AK Run's AI agents taking the first look at every alert for a named engineer to confirm. The developers' bugs would be fixed in the code, with a test, as a pull request their own approver ships through the company's pipeline. The upkeep this platform never had, patches, upgrades, certificate renewals and recovery checks, would run on a calendar with an owner for each, and we'd hold no standing admin access, only roles the company grants and can revoke, plus a break-glass role its on-call approves. If AI agents arrive later, they'd go on one register, with every model call through Agent ControlPlane.

Modernize with AI AI-Native Managed Services

More work like this

  1. Modernization0A U.S. clinical analytics providermissed pipeline runs while production moved, as reportedHospitals expected their data every week. The platform underneath it belonged to other people.8 weeks to AWS, MAP-funded25 ECS clusters moved between accountsOn AWS ECS · EC2 · RDS · CloudTrail
  2. ModernizationIn productionA North American insurance software providera pipeline that turns PDF forms into the product's schema, where a person rebuilt itEvery insurance form is also a set of instructions. We taught the product to read them.2 Nova Pro passes for each form1,200 customer databasesOn AWS Nova Pro · S3 · SQS · EC2
  3. Modernization99.9%A global white-label auction platformuptime at thousands of bids a minute, as reportedA ten-minute change took days to ship, because it had to reach 400 auction houses by hand.100+ deployments a week30% faster auction-house onboardingOn AWS S3 · ECS · Fargate · RDS

All case studies →

Have a problem like this one?

A free workshop: a few hours with the architects who'd do the work, on your own systems. No cost.

Book a free workshop