5 Lessons From Migrating a Legacy Data Platform to AWS

The hardest part of moving a legacy data platform onto AWS is not the move itself. On a planning slide, there is a before box, an arrow, and an after box. The arrow is where most of the real work hides.

The demand is not slowing down anytime soon. Gartner put worldwide public cloud spending at around $723 billion in 2025, up roughly 21% on the year, and it expects most organizations to be running some form of hybrid cloud through 2027. A good share of that money is going toward retiring an aging warehouse or an on-prem data estate that nobody quite trusts anymore but everyone quietly depends on.

Spend Real Time on Discovery

People take this discovery step as something that can be done with a few meetings, but I believe that this is where you find out the real task. I have come to see it as the project itself. A legacy platform is rarely documented in any reliable way. You find tables nobody can name an owner for, a nightly job that three reports secretly rely on, and a stored procedure that was last touched by someone who left the company years ago.

What I try to walk away with from this phase is a clear picture of data lineage: where each important field comes from, what changes it along the way, and who reads it at the end. Most of the projects I have worked on never had this written down anywhere, and if you ask me, that is usually why a small change in one place ends up breaking something three steps away.

You no longer have to do all of this by hand. A lot of the dependency mapping that used to take months is now handled by tooling, and I have started leaning on AI-assisted analysis to flag the coupling between systems that humans tend to overlook. I would not take its output as gospel, but it gives me a sensible place to start digging.

Decide the Approach Workload by Workload

AWS describes migration in terms of the seven Rs: rehost, replatform, repurchase, refactor, retire, retain, and relocate. The mistake I made early on was picking one of them for the whole estate because it was easier to explain to leadership.

A data warehouse migration to AWS almost never wants a straight lift and shift. If you drop a tired on-prem warehouse onto an EC2 instance, you keep every limitation you were trying to escape and add a transfer bill on top of it. These days I look at each workload on its own terms, and the split usually looks something like this:

The option people forget is retiring things outright. On every estate I have looked at, a meaningful chunk of the data is simply never read by anyone. Deleting it before you migrate is the easiest way I know to shrink both the timeline and the eventual invoice.

Prove the Numbers, Do Not Assume Them

Do not assume the migration is finished once the data has copied across. In my experience, it is finished only when someone can stand up and demonstrate that the numbers still match.

The tooling here is genuinely good. AWS Database Migration Service and the Schema Conversion Tool will move and reshape data reliably, including keeping the source and target in step during a phased cut-over. What they cannot do is decide what “correct” means for your business, and that responsibility stays firmly with you. I build reconciliation in from the start, and I keep it to three things:

• Row counts, so nothing silently went missing in transit
• Checksums, so the data that arrived is actually the data that left
• A few business-level checks, the kind an analyst would notice straight away if they broke

Something as simple as last quarter’s revenue totalling the same on both platforms reassures people far more than any green tick on a dashboard.

Treat Cost as Part of the Design

This is the lesson that cost me the most to learn. You can run a technically flawless migration and still have it judged a failure because the monthly bill turns up looking absurd.

On-prem hardware used to enforce a kind of discipline without anyone really noticing. When capacity meant a purchase order, nobody spun up a cluster to test an idea and then forgot about it for a quarter. On AWS that forgetting shows up directly as money. I now treat right-sizing, storage tiering, and shutting down idle resources as design questions that belong in the architecture review, well before anything goes live.

If you want a concrete sense of how this plays out in practice, this AWS cloud cost optimization and DevOps audit case study is a useful read, because it walks through the kind of waste that accumulates after a migration: over-provisioned instances, storage nobody ever cleaned up, and environments left running out of habit. Among the AWS data migration best practices I now insist on, the most reliable one is to give the project a named cost owner before go-live, rather than waiting for finance to come asking questions.

The Work Continues After Go-Live

Go-live feels like the finish line because everyone planned toward it, but I have learned it is closer to the moment you find out whether the move was worth doing. The old platform carried years of operational knowledge that mostly lived in people’s heads, things like which alert is safe to ignore and which job always drags on a Monday. None of that copies across on its own. I try to capture it while the people who hold it are still around, often by running the old and new systems alongside each other for a short period so the team can learn the new behavior against something they already understand.

Governance deserves the same care. The rules around data residency, retention, and access control are a good deal stricter than they were when most of these systems were first built, so I would much rather bake those controls into the target design than bolt them on later when an auditor starts asking. Retrofitting always costs more and never sits as cleanly.

Why the Best Migrations Are the Dull Ones

The most successful legacy data platform migrations are almost never the dramatic ones. They are the projects where discovery has been thorough, where we deliberately leave the dead data behind, where the numbers reconcile, where the bill stays unremarkable, and where the on-call team barely notices the first week. AWS gives you a far better place to run a data platform, but it does not hand you a better platform for nothing. The difference is all the work that never makes it onto the slide, and in my experience, that is exactly where the lessons are.