How Does a Production-First Cloud Migration to AWS Work?

Key takeaways

• Progress is a workload live in production with its legacy version switched off. Servers assessed and waves planned are inputs, and the lender in this guide wouldn't count anything as done until its old system was retired.
• Assessment is rarely where a migration stalls. Discovery that eats the budget, a shared database nobody mapped, and parallel runs with no exit criteria account for most of the delays we're asked to fix.
• The strategy is picked workload by workload, using AWS's 7 Rs. For a company like the lender, that usually means rehosting whatever has to leave the data center by a lease date and replatforming the databases with a renewal coming up.
• A good share of the budget is often already in your spend. AWS MAP, license renewals you can avoid, and AWS Transform's free assessment and migration agents all shrink what you have to ask the board for.
• Auditors will ask about the migration path. That covers the replication pipelines, the staging copies, and any test environment that ever held real data, on top of the production account.

Most enterprise teams don't need another explainer on why the cloud matters. You already have AWS spend on the books, a migration program sitting somewhere between "approved" and "stuck," and a board asking when the legacy data center bill finally goes away. The real question is narrower and harder: how do you run a cloud migration to AWS so it reaches production on the date you committed to, without blowing the budget or tripping an audit?

We have been shipping workloads on AWS since 2008 for financial services, healthcare, manufacturing, and software companies, many of them carrying regulated data and AI systems that auditors read line by line. We see the same thing again and again. Assessment goes fine. Then the plan meets production, the scope starts drifting, parallel runs drag on for quarters, and the legacy estate never quite gets switched off.

To keep this concrete, we'll follow a made-up but typical company through the guide. It's a mid-market lender with about 400 servers in a colocation facility, and the lease runs out next June. The lender runs roughly 160 applications, an Oracle Exadata system whose support renewal is due in March, and a VMware estate with a contract that's up in September. Card payments put part of it in PCI DSS scope, and a small payments subsidiary in Amsterdam, licensed as an EU payment institution, brings DORA in.

We'll use the lender to walk through the production-first approach we use on enterprise AWS migrations: how to pick a strategy for each workload, what the money looks like, how to keep HIPAA, PCI DSS, SOC 2, GDPR, and DORA obligations intact, and how to tell whether a migration partner will put a ship date in writing.

What does a production-first cloud migration to AWS actually mean?

A production-first AWS cloud migration counts a workload as done when it's running in production and its legacy version has been retired, and not before. Discovery reports, landing zones, and pilot environments are useful along the way, but they're not the finish line. Until real users and real data have moved, nothing has shipped.

It sounds obvious. Yet most programs report activity instead: servers assessed, waves planned, accounts provisioned. Those numbers look fine on a steering committee slide until the quarter the CFO asks what has actually shipped and what has been turned off. The figure below shows where the two approaches part ways.

Look at the last row, AI readiness. Whatever data foundation you migrate onto is the one your AI programs will run on, and McKinsey found that eight in ten companies cite data limitations as a roadblock to scaling agentic AI. Haul the old schema and its technical debt into AWS unchanged and you've moved that roadblock to a more expensive address.

Why do so many AWS migration projects stall before production?

Even the analysts expect a lot of these to miss. Gartner predicts that more than 70% of mainframe exit projects initiated in 2026 will fail to produce the intended benefits, mostly because teams expect generative AI tools to do more than they can. The tools do speed up analysis. Deciding what moves in which order, what the data contracts say, and when to cut over is still a job for engineers who've done it before.

When we're asked to rescue a stalled program, we usually find it stuck at one or more of these five points:

Say the lender had tried this once already, three years ago. Discovery ran on interviews and spreadsheets and burned through most of the budget before a single server moved. Nobody noticed that ten applications shared one Oracle schema, so none of them could move until all of them could. The first wave did go live, but the parallel run had no exit criteria, and eight months later the lender was still paying for both environments. Since nobody had written down what "accepted" meant, the cutover turned into a negotiation, and with no decommission date in the plan, the Exadata support contract renewed anyway.

Which AWS migration strategy fits each of your workloads?

AWS boils the choices down to seven, the 7 Rs of cloud migration: retire, retain, rehost, relocate, repurchase, replatform, and refactor. You pick one for each workload during assessment. Workloads that lean on each other go into the same migration wave, since moving one without the other tends to break both. Expect to change some of those calls once the dependency map is finished. It happens more often than teams plan for.

Our rule of thumb is simple. Rehost what you need to get out of a building, replatform whatever you're paying license tax on, and save refactoring for the systems the business is betting the next three years on.

At the lender, that would mean rehosting most of the colocation estate so it's out before the lease ends, which turns the move into a data center exit with a date that can't slip. The VMware clusters would be relocated before September, Exadata would be replatformed to Aurora PostgreSQL ahead of the March renewal, and only the loan-origination system, which the business plans to build on, would be refactored. A handful of reporting apps nobody has opened in a year would simply be retired.

The tools have changed too, and plenty of guides haven't caught up. AWS Application Migration Service is now AWS Transform MGN. Migration Hub stopped taking new customers in November 2025, and AWS points people to AWS Transform instead. AWS DMS now uses generative AI to help with schema conversion. If a partner's runbook still lists the old stack, ask when it was last updated.

Give the databases their own line in the plan. If Oracle or SQL Server licensing is your biggest line item, an Oracle to AWS migration that replatforms to Amazon Aurora or RDS ahead of the renewal date often pays for a meaningful share of the migration. This is bread-and-butter work for our application and database modernization team. It's how Synaptics moved from Oracle to Amazon RDS and freed up the budget it had set aside for license renewal.

What does a cloud migration to AWS cost, and how do you fund it?

Two things set the size of the bill: how big your estate is and which mix of strategies you pick. What ends up on it is easier to predict. When budgets overrun, it's rarely the AWS invoice. It's discovery labor, months of running two environments, and the license nobody remembered to cancel.

At the lender, the bill would break into six parts: assessment and discovery, migration labor, the months of dual running, AWS run costs, licensing, and getting its own team ready to operate what's built. The first three are where overruns hide. Discovery that drags past six weeks, a parallel run nobody is allowed to end, and a VMware renewal signed out of habit are what usually blow the budget.

Spending can also drift after cutover. In Flexera's latest State of the Cloud report, estimated wasted cloud spend went up to 29%. That's the first rise in five years, and AI workloads account for a lot of it. So we build FinOps into the landing zone on day one. Tagging, budgets, and anomaly alerts are running before the first workload shows up.

Where does the money for an AWS migration come from?

Before asking the board for new money, most teams planning an on-premises to AWS migration have three places to look:

1. AWS Migration Acceleration Program (MAP). MAP follows three phases, Assess, Mobilize, and Migrate & Modernize, and for migrations that qualify, AWS puts in its own investment to help offset the early costs. The amount differs from deal to deal. Ask your partner to model it in the business case, not quote you a flat percentage.
2. License reallocation. The Oracle renewal, the VMware contract, and the premium support tier on an aging warehouse are all budgets you already spend. Moving before the renewal date turns that line into migration funding.
3. No-cost AWS tooling. AWS Transform currently lists its assessment, its VMware migration agent, and its Windows and mainframe modernization agents as free, which trims the discovery bill.

Then ask every partner on your shortlist the same question: whose money pays for the delay? With us, the ship date is named in the contract, the fee is fixed before the build starts, and overage on delays inside our control is absorbed by us. Our delivery commitment spells out those terms, and 94% of our engagements have landed on or ahead of the committed date.

How do you keep compliance intact during a cloud migration to AWS?

Audits rarely fail on the production account. They fail on the things around it. The usual culprits are a staging copy nobody deleted, a replication pipeline left unencrypted to save a day, and a test environment full of real customer records. Logging often doesn't go live until a week after cutover. AWS looks after the infrastructure under the shared responsibility model. What you build and move on top of it is yours to control, path included. We treat the migration path as an in-scope system, with the same controls and evidence as production.

A breach during the move is expensive. IBM's latest Cost of a Data Breach study put the global average at $4.99 million, the highest it has recorded, and it lists cloud misconfigurations around AI workloads as a common cause of breaches aimed at AI.

In Europe, where the data lives is now an architecture question, not a clause for the lawyers to sort out later. The AWS European Sovereign Cloud opened in January 2026 with a region in Brandenburg, Germany, and Gartner expects sovereign cloud IaaS spending in Europe to grow 83% in 2026. Regulators haven't gone quiet either. Data protection authorities handed out about €1.2 billion in GDPR fines in 2025, so pick the region and the transfer mechanism with the same care you'd give the cutover plan.

Two rows of that figure would shape the lender's landing zone. Card data can't move until the cardholder data environment has its own segmented accounts, and we'd check the PCI DSS scope again right before cutover. On the DORA side, AWS has to be added to the Amsterdam subsidiary's register of information. Processing payments is almost certainly a critical function there, so the exit strategy needs to be written down and tested before anything moves.

This is where working production-first pays off most, because the audit evidence is captured when each decision gets made, not pieced together after go-live. Before KlearTrust brought us in, two of its automation pilots had stalled at the PHI and audit handoff. The production platform we shipped in 12 weeks replaced a six-month manual claims-review cycle and passed HIPAA and internal audit on the first review.

What does a production-first AWS migration plan look like, phase by phase?

We run a production-first plan in five phases, each ending at a gate someone has to sign. A status update alone never moves work forward, and that's what keeps the date honest. It's also the most dependable way we know to set an AWS migration timeline, one wave at a time.

At the lender, the first gate would be a signed statement of work with the date and fee for wave one. The second would prove the riskiest assumption, which here is the shared Oracle schema, before any build starts. After that comes a slice the business can see working end to end, then a parallel run that reconciles field by field on live data, and finally signed acceptance along with the date Exadata gets switched off.

The same structure is why our engagements reach production in a median of 12 weeks. A forward-deployed engineer from our side makes the calls at each gate, and the customer signs every exit.

What should your AWS migration checklist include before cutover?

We don't cut anything over to production until every one of these is green:

• Row counts and checksums match the legacy system, and field-level comparisons come back clean
• Performance within the agreed baseline under peak-like load
• Rollback rehearsed, timed against the agreed RPO and RTO, and owned by one named person who can call it
• Monitoring and alerting live in the target account, cost anomaly detection included
• Security controls and audit logging verified by whoever owns compliance
• Business owner's signed acceptance on file
• Hypercare window and on-call coverage agreed for the first weeks after go-live
• Legacy decommission date booked, with license and contract end dates confirmed

How should you evaluate an AWS migration partner?

Don't spend long on partner tiers and competencies. Any serious firm selling AWS migration services has them, and they say almost nothing about whether your workload will reach production on time. These seven questions do a better job of separating partners who carry delivery risk from those who bill around it.

Pay most attention to the first two. If a partner pauses on either, you've learned who'll be paying when the schedule slips. The ones with real skin in the game answer both before the first meeting is over.