Armakuni Contact us
← All case studies

Their last database migration took weeks of rewrites.
This one kept the application exactly as it was.

A U.S. customer-feedback platform for banks and credit unions was split across Azure and AWS, with an aging SQL Server whose license nobody could find and backups kept on local drives. After a previous database change had turned into weeks of rework, it needed a move that changed nothing it didn't have to. We scoped a like-for-like migration around its real dependencies and moved two application servers and a database server from Azure to AWS in four weeks.

Before

Two clouds, an old database and a migration that had gone badly.

After
3×faster deployment, as reported
1 dayrecovery point, with AWS Backup
  • No more 30 to 40 days of backups kept on local drives.

Two clouds, an old database and a migration that had gone badly

The company helps banks and credit unions understand feedback from their customers across web, phone and email. Its web and voice-response applications ran on Azure, beside other parts already on AWS. Underneath was an outdated SQL Server 2008 with unclear licensing. As the customer put it: "I don't even know if I have the license key." Configuration was hardcoded, Windows services had to survive the move, and backups were manual, kept for 30 to 40 days on local drives.

A previous change from one database to another had needed more than three weeks of code rewrites and left query performance worse. So the company was wary of migrating again, and it had a quarter-end deadline.

A like-for-like move, replacing only the parts that were a risk

The answer was deliberately narrow: a like-for-like migration. Move the servers and the database as they are, replace the parts that were themselves a risk (the hosting, the license, the backups and the edge security) and leave the application rewrite out of scope, on a budget that couldn't reach five figures.

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. Scope the dependencies before the move
  2. Windows and SQL Server, moved intact
  3. Test copies first, and a way back

Scope the dependencies before the move

What depends on what Applications1SQL Server2Edge controls3Network4 the order of the move
The engineering

Within a week of the first discovery call, the company had a migration plan and a budget estimate. The scoping mapped the real dependencies, from server configuration to the order the servers had to move in, and set out the target architecture and the cutover and rollback scenarios.

Why: the company had been through a migration that hurt, and a plan that changed as little as possible was the one its people could agree to.

Windows and SQL Server, moved intact

Built withEC2WAFKMSAWS BackupS3
AzureAWS Windows appsWindows appsSQL ServerSQL ServerEdge controlsEdge controls the application kept exactly as it was

“I've been involved in many migrations over the years, and there's usually at least a few hiccups along the way. This was, by far, the smoothest I've experienced.”

CTO, a financial services feedback platform
The engineering
  • The Windows application workloads moved to EC2, keeping the application and service behavior they needed. Each Azure service had a direct counterpart: the VMs became EC2 instances, Front Door became WAF with load balancers, and the VNet became a VPC, so nothing about how the application worked had to change.
  • The destination uses an AWS-licensed SQL Server environment, which ended the uncertainty about the old database's license.
  • WAF and load-balancer configuration replaced the source environment's edge controls.
  • KMS-backed EBS encryption protects stored data, and automated backups, through AWS Backup with a one-day recovery point and to S3, replaced the local-drive arrangement.
  • Network and access configuration connected the migrated applications to the company's existing AWS environment.

Test copies first, and a way back

A test copy moved firstCheckedA way back kept
The engineering

The migration plan used test instances, data validation and a rollback sequence before cutover, with the move done through migration agents and AWS's migration services, so the business could always return to the old environment. A wider application rewrite stayed outside the scope, on purpose. A rollback route planned before the cutover is what makes a short deadline safe.

What we'd tell another CTO

1After a painful migration, change as little as possible, because like for like rebuilds trust, and replace only what is itself a risk: the license, the backups and the edge. Keep the rewrite out of the migration, since two big changes at once is how the last one went wrong.
2Plan the rollback before the cutover, and give a dated plan fast. A week to a plan and budget is what made a quarter-end deadline possible.

What else changed

  • Two application servers and one database server moved from Azure to AWS in four weeks, like for like, from mid-March to mid-April 2025.
  • A licensed SQL Server, where the old one's license was unknown.
  • A plan and budget in a week, delivered within the company's four-to-five-week window, and under budget.

What comes next

With the platform on AWS, any application modernization can be its own project, on its own timeline.

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, and ours would read what the network can't show, such as hardcoded addresses and connection strings in config files and scheduled jobs, so those are changed before the night. Licenses would be settled, the company's own or included, with each workload priced on AWS from measured use.

Servers would copy across while the old ones keep running, a test copy would run on AWS before the cutover, and the old server would be kept, switched off, until the new one has run a month-end. Afterwards, AK Run's AI agents would take the first look at every alert, for a named engineer to confirm and ship the fix with a test.

Modernize with AI AI-Native Managed Services

More work like this

  1. Modernization5 monthsA global software-delivery platformto cost neutrality, where 36 had been expected, as reportedThree partners proposed a migration. Two years later, nothing had moved.66% less than the proposed migration cost, about $300,0005 weeks ahead of scheduleOn AWS EC2 · SNS · CloudWatch · CloudTrail
  2. Modernization~30 minutesA U.S. fulfillment providerplanned final cutoverThe storefront was already in the cloud. The warehouse that ships every order wasn't.30% faster order processing at peak, targeted25% lower infrastructure cost, targetedOn AWS EC2 · WAF · RDS · CloudWatch
  3. Modernization40%A U.S. K–12 staffing providerless manual payroll processing, as reportedA substitute teacher worked the day. Getting paid ran through three separate systems.30% lower cloud costs5× faster deployment cyclesOn AWS Fargate · RDS · Lambda · 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