A $1.2M Cloud Migration in 14 Months

In 2019, TNGOC's core appraisal engine ran on aging on-premise hardware with maintenance contracts that cost more every year. The business case for cloud was obvious on a spreadsheet. The execution was 14 months of my life.

We moved 6 core services to AWS, cut annual operating costs by $1.2M, and improved platform uptime from 99.2% to 99.85%. This is how we did it, and what I'd change if I had to do it again.

Getting buy-in was the first project

Leadership approved the migration but didn't fully trust it. Every quarter I had to re-justify the timeline and the spend. I learned early that the financial argument alone wasn't enough. What actually moved the conversation was framing the migration in terms of risk: what happens when this hardware fails and we don't have a vendor who can replace it in 48 hours?

I built a dashboard that showed migration progress by service, not by sprint. Leadership didn't care about story points. They cared about which services were still on-prem and what the blast radius was if that hardware went down. Speaking their language saved the project from getting deprioritized at least twice.

The order we moved things

We started with the service that had the least downstream dependencies and the best test coverage. Not the most important service, not the one leadership wanted moved first, but the one where we could learn the most with the least risk. That first migration took six weeks, which felt slow. But it established the patterns, the runbooks, and the confidence we needed to move faster on the rest.

Services two through four moved in parallel over the next five months. By then the team had a rhythm. The last two services were the hardest because they had the most legacy dependencies and the least documentation. We spent almost as much time reverse-engineering the existing behavior as we did building the new infrastructure.

Keeping the team together through month 11

Long migrations are exhausting. Around month 8, I could see energy dropping. The initial excitement was gone, the remaining services were the hardest, and the team could see the finish line but it kept moving. Two engineers started looking at other jobs.

I made a few changes. I rotated people between migration work and feature work so nobody was stuck doing infrastructure for months straight. I started celebrating smaller milestones publicly, not just at the team level but in front of leadership. And I had honest conversations with the engineers who were burning out about what they needed. One wanted more ownership on the technical decisions. The other wanted to know they'd get to work on something new after the migration. Both stayed.

The results and what I'd change

$1.2M in annual savings. Uptime from 99.2% to 99.85%. Zero major incidents during the migration. Nobody quit. Those are the numbers I put on my resume, and they're real.

What I'd do differently: I'd push harder for a dedicated migration team from the start instead of splitting people between migration and feature work. The context-switching cost was real. I'd also invest in better observability earlier. We added Datadog in month 4, and the first three months of flying blind on the new infrastructure were unnecessarily stressful.

Cloud migrations are a management problem disguised as a technical one. The tech is well-understood. The hard part is sustaining momentum, managing stakeholder expectations, and keeping your engineers engaged through a project that's important but not exciting for most of its duration.