Armakuni Contact us
← All case studies

Three partners proposed a migration.
Two years later, nothing had moved.

A global software-delivery platform had spent more than two years on proposals to leave an expensive hosting estate, and none had made the move practical. We mapped its dependencies, rebuilt the migration's economics with AWS funding, and completed the move without a major rewrite.

Before

Every earlier proposal stalled at the same point.

After
5 monthsto cost neutrality, where 36 had been expected
66%less than the proposed migration cost, about $300,000
5 weeksahead of schedule

As the company reported.

Every earlier proposal stalled at the same point

The company helps enterprises manage and secure software delivery. Its own infrastructure lived on a legacy hosting estate that no longer fitted its workloads, which kept changing, or its budget. Its engineers waited through long procurement cycles for every infrastructure change, and there was no integrated recovery strategy for critical workloads.

It had asked for migration plans. Three different partners sent statements of work, and none made the move practical. More than two years passed with no clear way forward.

The earlier plans failed on cost and risk

The earlier plans ran into trouble on cost and risk, because each one called for a big rewrite and a big bill, with no credible point at which the move would pay for itself. The plan that worked had to cost less and tell the business honestly when it would break even.

We sized the move on evidence and funded it through MAP, which let us leave the application code unchanged

We looked at the actual server configurations, dependencies and application code, sized the destination for what the workloads really needed, kept the Windows application behavior as it was rather than rewrite it during the migration, and built the business case around AWS Migration Acceleration Program (MAP) funding.

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. An assessment that changed the business case
  2. Windows workloads, moved with their file services
  3. Visibility from the first day

An assessment that changed the business case

Each workload measured Workload 11Workload 22Workload 33Workload 44 sized to what they use
The engineering

The assessment covered server configurations, dependencies and application code, so the destination was right-sized from measured need rather than copied from the old estate. Combined with MAP funding, it produced a migration plan the business could actually approve, where three earlier proposals hadn't.

Because a migration only gets approved on its business case, right-sizing and funding were what made this one add up.

Windows workloads, moved with their file services

Built withEC2FSx for NetApp ONTAP
Hypervisor estateEC2 Windows workloadsWindows workloadsFile servicesFile servicesLoad balancingLoad balancing no major application rewrite

“They allowed our internal team to remain focused on customer and technical needs while efficiently building our environments in Terraform. Additionally, they worked closely with our AWS team to optimize costs and minimize the financial impact of our migration.”

Director CloudOps, an enterprise software company
The engineering
  • The Windows hypervisor-based workloads moved to EC2, with no major application rewrite.
  • FSx for NetApp ONTAP provides the file storage the applications need.
  • Load balancing distributes traffic across the destination infrastructure.
  • Automated backup and failover add cross-region recovery, which the old estate had lacked.

Visibility from the first day

Built withCloudWatchManaged GrafanaCloudTrailSNS
CloudWatch, GrafanaCloudTrailAn alarm Team sent through SNS
The engineering

CloudWatch and Amazon Managed Grafana give the team operational metrics and visualizations. CloudTrail records infrastructure activity, and SNS sends notifications, so changes are visible and teams hear about problems early.

What we'd tell another CTO

1When a migration stalls it is usually because the business case has not been worked through, even though the servers are sitting ready. Right-sizing from measured use, along with MAP funding, changed what this plan cost, because simply replicating the old estate would have carried its cost over unchanged.
2The team kept the rewrite out of the move because that is the change that makes migrations fail, and treated the first move as the template so the next two could follow its sequence and its numbers.

What else changed

As the company reported.

  • Cross-region recovery, and monitoring the old estate never had.
  • A three-year roadmap with two further migrations, planned using the first move's sequence and economics.

What comes next

The two further migrations on the roadmap, following the first move's sequence and economics.

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 ours would read the config files, scheduled jobs and connection strings the network can't show. 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, and where a workload would cost more on AWS we'd say so and it would stay.

We'd prepare the MAP funding request with the company's team and take it to its AWS account team: AWS funds migrations in stages for workloads that qualify, and it decides what it funds. After a few weeks of real use, our AI agents would propose new sizes for our engineers to make, and then the company's team would run it, or AK Run would.

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