Armakuni Contact us
← All case studies

The storefront was already in the cloud.
The warehouse that ships every order wasn't.

A U.S. fulfillment provider for online brands and creators had its customer storefront on AWS, while 85–90% of what actually fulfills an order (warehouse and order-management systems, queues, scheduled jobs and shared files) ran on VMware in its own building. We mapped those systems as dependency groups and planned a move to AWS around the holiday peak, cutting over one whole group at a time. The plan is built to process orders 30% faster at peak, with recovery in under five minutes.

Before

An order online, a building full of servers behind it.

You can't move half an order.

After
~30 minutesplanned final cutover

An order online, a building full of servers behind it

The company fulfills orders for smaller commerce brands and creators. An order placed online, through a storefront or a commerce integration, still had to reach the warehouse management system, the order management system, scheduled jobs and shared files before a box could leave the building. Those ran on VMware on-premises, while the front end ran on AWS, joined by a VPN.

The holiday season, from Thanksgiving to New Year, is when all of that has to work hardest, and when nobody wants to touch it.

You can't move half an order

The risk in a move like this is splitting things that talk to each other. Orders arrive through APIs and queues (RabbitMQ, Hangfire and MSMQ between the warehouse and order systems), .NET middleware coordinates the cloud and on-premises applications, and SQL Server databases sit behind each system. Move the warehouse system without its queue, or a database without the job that reads it at 2 a.m., and orders stop.

Follow the order, then move it in groups

So we assessed the systems the way an order travels through them, grouped everything that depends on each other, and planned to move one whole group at a time, starting with the smallest.

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. Mapping the path an order takes
  2. Monitoring, backup and recovery designed in
  3. Cutover one dependency group at a time

Mapping the path an order takes

Built with.NETEC2DMSWAF
One order, traced Integrations1APIs2Queues3.NET apps4SQL Server5Shared files6 move it in dependency groups
The engineering

Orders come in through commerce integrations and pass into the internal platform through APIs and queues. The assessment covered the .NET applications, SQL Server databases, scheduled jobs, messaging, shared files and the network linking cloud and on-premises, and the target design:

  • A landing zone that separates management, test and production.
  • EC2 for the Windows application workloads, with version upgrades considered before migration and a bring-your-own-license approach for Windows and SQL Server.
  • DMS for database replication and FSx for Windows for shared files, replacing the legacy file servers.
  • Managed Microsoft AD for the directory the Windows applications need.
  • VPC, VPN, load-balancer and firewall designs for how traffic reaches each component during and after the move, including a Network Load Balancer for the phone system's SIP and VoIP traffic, because it runs over UDP as well as TCP and an Application Load Balancer only carries HTTP, and WAF on the API load balancer.

Why: a dependency map drawn from the path an order takes shows what has to move together, which a list of servers doesn't.

Monitoring, backup and recovery designed in

Built withCloudWatchCloudTrailAWS BackupElastic Disaster Recovery
in the planDesigned in before anything movesMonitoringBackupRecovery

“I am grateful for Armakuni's hard work in assessing [our] current architecture and drawing the blueprint for an existence in AWS. I trust your team's understanding of how to execute a lift and shift. And the study revealed the areas that need our attention, like a doctor examining a patient in need of some lifestyle changes; changes that might save the life of the patient. Armakuni was able to show me what I couldn't see for myself.”

CEO, an e-commerce fulfillment company
The engineering

The plan replaces the existing monitoring and backup arrangements with CloudWatch, CloudTrail, AWS Backup and Elastic Disaster Recovery patterns, with Multi-AZ availability, automated notifications and deployment integration for running the new environment. Recovery and availability objectives are still to be proved by rehearsal and workload testing during implementation.

Cutover one dependency group at a time

plannedOn-premisesAWS Group 1Group 2Group 3 a final window of about 30 minutes
The engineering

The plan starts with the smallest dependency group and applies successive checks:

  1. Validate individual servers and database replication.
  2. Exercise the applications with their databases, messaging and shared files.
  3. Complete user acceptance testing across the whole group before scheduling its cutover.
  4. Pause external order integrations and queue incoming data during the planned maintenance window.
  5. Keep a defined rollback sequence and a support team on hand for the cutover.

The proposed final cutover window is about 30 minutes. Rehearsal still has to confirm that, along with the recovery and availability targets. Pausing the integrations and queueing incoming orders means a cutover never loses one, even if it runs long.

One order, end to end (planned)

  1. A shopper buys from a creator's store. The commerce integration sends the order to the company's API.
  2. The API, on EC2 behind WAF, writes it to SQL Server on RDS.
  3. The queue hands it to the order management system, and then to the warehouse system.
  4. The warehouse system prints the label from files on FSx.
  5. During a cutover, incoming orders queue rather than fail, and are processed when the group comes back.
  6. If the cutover misbehaves, the rollback sequence returns the group to on-premises.

What we'd tell another CTO

1Map the path an order takes instead of the server list, because it shows what has to move together, and move whole dependency groups, since half a system is worse than none. Start with the smallest group, where the method is cheap to learn.
2During cutover, pause the integrations and queue incoming orders, so no order depends on the window going well, and rehearse before promising a window. Thirty minutes is a target until it's been done.

What else changed

  • A dependency map of the order path across the .NET applications, SQL Server, queues, scheduled jobs, files and network.
  • A target design on AWS for every component, with monitoring, backup and disaster recovery built in.
  • Targets the plan is built to hit, from the company's business case: 30% faster order processing during peak season, 25% lower infrastructure cost, 99.95% uptime, and near-zero data loss with recovery in under five minutes for critical systems. These are targets, still to be measured.

What comes next

Implementation, with each group rehearsed before its cutover, and the recovery and availability targets proved on real workloads.

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 and group what depends on each other into waves, 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, because the job nobody listed is the one that breaks on the night. Each workload would be decided in the company's own numbers, switched off, kept, moved as it is, moved with small changes or rebuilt, and priced on AWS from measured use, never from the old server's size.

The holiday peak and the hardware and license dates would set the last day, and the first wave would be small, with few dependencies and a clear owner. Servers would copy across continuously while the old ones keep running, and each old server would be kept, switched off, until the new one has run a month-end.

Modernize with AI AI-Native Managed Services

More work like this

  1. ModernizationMinutesA U.S. heavy-equipment dealer's platformto set up a tenant, where it took daysThe dealer had built software other dealers wanted. It wasn't yet a product anyone else could buy.+60% engineering hours a month, 250 to 400150+ database tables per tenantOn AWS WAF · Cognito · Aurora · Bedrock
  2. Modernization30%An event sign-up platformless engineering time on legacy systems, as reportedA year of modernization, and nothing had shipped. We started with the parts every module reuses.700+ dashboards moved20 components refactored, 3 builtOn AWS Redshift · EC2 · QuickSight · Aurora PostgreSQL
  3. Modernization3×A U.S. feedback platform for banksfaster deployment, as reportedTheir last database migration took weeks of rewrites. This one kept the application exactly as it was.4 weeks to move from Azure to AWS1 day recovery point, with AWS BackupOn AWS WAF · EC2 · AWS Backup · S3

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