Armakuni Contact us
← All case studies

Every busy day needed an engineer to add servers.
Every quiet one needed an engineer to move customers back.

A global CRM and order-management provider ran more than 900 processing tasks in two rented data centers, where adding capacity and rebalancing customers were jobs done by hand, and production passwords sat in the code repository. After an AWS-funded discovery, we moved all of it to AWS in seven to eight weeks, with separate controls for queued work, cluster capacity and each customer's database.

Before

Growth kept pulling the people who should have been building the product onto other work.

Passwords were sitting in the repository, and some questions about the system had no answer.

After
80–90%less manual resource allocation
<5 minutesto scale database workloads
15–30%lower infrastructure cost

As the company reported.

Growth kept pulling the people who should have been building the product onto other work

The company runs a high-volume CRM and order-management platform for eCommerce and direct-marketing businesses worldwide. Its processing estate ran across two rented data centers. When the platform needed capacity, someone built it by hand. When demand outran them, servers hit their limits and every customer on them slowed.

There was no separation between customers either. One customer's heavy batch could slow everyone sharing the server. And customers were spread unevenly, so fixing an overloaded server meant moving customers by hand, which usually meant an outage. The team had to choose between slow performance and planned downtime.

Passwords were sitting in the repository, and some questions about the system had no answer

The production database passwords and application secrets had been committed to Bitbucket, unencrypted, readable by any developer with repository access. Enterprise clients were asking for documented access controls, credential rotation and audit trails, and every deal ran into the same gap.

Queued work, compute and data got pulled apart after being tangled together

The platform's problems came from three things sharing one control, how much work was queued, how much compute was running, and where each customer's data lived. The design gave each of them its own control, so each could scale or move without touching the others.

How we built it

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

  1. The team mapped everything before touching anything already running in production
  2. Queue depth decides how many tasks run, and node count adjusts to match demand
  3. Each customer on its own database cluster, routed automatically
  4. The team pulled credentials out of the code and kept them out
  5. The platform now has someone watching it overnight

The team mapped everything before touching anything already running in production

Everything traced, first Scheduled jobs1Web workloads2File transfer3Databases4 then the move, in order
The engineering

A two-to-three-week discovery, fully funded by AWS, assessed the dependencies across more than 900 tasks, five virtual machines and the network in both data centers. Migrating that many tasks without knowing how they connect is how migrations break production. The discovery found the exposed credentials and put fixing them into the migration plan, and produced the full AWS target architecture before any execution began.

Queue depth decides how many tasks run, and node count adjusts to match demand

Built withEKSFargateKubernetesEC2Transfer FamilyKEDA
Queue depthTasks and nodes
The engineering
  • Containerized processing tasks run through a queue-driven EKS execution pattern, with Fargate for task workloads.
  • Scheduled work becomes Kubernetes jobs, web workloads use EC2, and file transfer moves to Transfer Family.
  • KEDA adjusts workload replicas to queued demand, and Karpenter supplies node capacity for the EKS workloads that use EC2 nodes.
  • CloudWatch records task execution, service health and database performance, with alerts for the operating team.

Why: tasks and machines scale for different reasons, so using one control for both means paying for idle machines or queuing behind the busy ones.

Each customer on its own database cluster, routed automatically

Built withMariaDB GaleraProxySQLEKSDMS
Routed automatically CustomerCustomerCustomer each customer on its own cluster
The engineering

Per-customer MariaDB Galera clusters give each customer a separate database environment, so one customer's heavy workload can't slow anyone else. ProxySQL and a Network Load Balancer route database traffic, replacing the manual placement and rebalancing that used to cause outages. Self-hosted Galera on EKS gives full customer isolation for far less than a separate managed database per customer.

A separate regional move used DMS replication from the western to the eastern U.S. environment, with Multi-AZ availability in the destination, so the production database gained failover it never had.

The team pulled credentials out of the code and kept them out

Built withSecrets Manager
Credentials taken out of the codeKept in a secrets storeRotated and audited
The engineering

Secrets Manager replaced the credentials stored in the code repository, with encrypted storage, controlled retrieval, automatic rotation and an audit trail. The answer to an enterprise client's security questionnaire now comes from the system.

The platform now has someone watching it overnight

ServicesDatabasesOvernight alert On call 40 hours of night support a month
The engineering

A retained engineering pod provides 40 hours of nighttime support a month: monitoring, incident response, logging coverage, performance analysis and cost governance. Weekly and monthly health reports connect what operations found with the changes the company's own engineers should prioritize.

One demand spike, end to end

  1. Say a big customer submits a large batch of orders overnight.
  2. The queue grows, and KEDA adds task replicas to match it.
  3. The replicas need room, so Karpenter adds nodes, and removes them once the queue drains.
  4. The customer's queries go to its own Galera cluster through ProxySQL, so no other customer feels it.
  5. The application reads its database password from Secrets Manager instead of from the code.
  6. CloudWatch records all of it, and the night pod spots any anomaly before a customer does.

What we'd tell another CTO

1Queued work, compute and data each got their own controls, because tangled together they made every change risky. Customers are isolated at the database too, since a noisy neighbor is a design flaw rather than bad luck. Database traffic routes automatically, because manual rebalancing turns into an outage sooner or later.
2Fix the credentials in the same migration, or the move only relocates the exposure. And keep someone watching after go-live, because a new platform needs eyes at night most.

What else changed

As the company reported.

  • All 900+ tasks and all five servers migrated to AWS in seven to eight weeks, and both data centers were left behind.
  • Every credential sits in Secrets Manager, encrypted, rotated and audited.
  • Real-time observability runs across the platform, with a night pod sending regular health reports.

What comes next

Ongoing operations on the retained pod: the health reports, cost governance and performance tuning as customer volumes change.

How we'd do it today

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

AI agents would find the dependencies first: AWS Transform's AI agents map which servers talk to which from the network, and ours read what the network can't show, such as scheduled jobs, scripts and connection strings with an address written into them, so workloads that depend on each other move together in one wave. After a few weeks of real use, our AI agents would propose new sizes for our engineers to make, with discounts for committed use waiting until usage is measured.

Once it's live, AK Run, our AI-native managed service, takes on all four parts of running it as one team. Production means the 900+ tasks, KEDA and Karpenter, and the Galera clusters behind ProxySQL, watched day and night, with its AI agents taking the first look at every alert and a named engineer confirming the cause. The applications mean a failing task fixed in its code, with a test, through the company's own pipeline. Security means the secrets kept in Secrets Manager, patches and upgrades on a calendar, and each finding owned until a tested fix is live. Any AI agent added to the CRM later goes through Agent ControlPlane's one gate, with what it reached, did and cost on a trace. For the companies we run, the median AWS bill falls 40% in the first quarter.

Modernize with AI AI-Native Managed Services

More work like this

  1. AI MSP60 hoursA Canadian direct-to-consumer insurerto explain outages that had gone on for 6–10 monthsAn outage nobody could explain for months. Explained in 60 hours.~800 MySQL queries behind each request150 threads per server, the ceilingOn AWS RDS
  2. AI MSP40%A U.S. AI marketing platformlower latency, as reportedOne brand's biggest campaign could slow the platform for everyone else.99.99% uptime while it moved to AWS75% more capacityOn AWS EKS · Security Hub · Lambda · S3
  3. 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

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