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.
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.
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.
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.
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.
Before asking the board for new money, most teams planning an on-premises to AWS migration have three places to look:
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.
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.
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.
We don't cut anything over to production until every one of these is green:
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.
|
Question to ask |
Strong answer |
Red flag |
|---|---|---|
|
Will you commit to a go-live date in the contract? |
One date per wave, written into the SOW |
A range, or a "target quarter" |
|
Who pays when you cause a delay? |
The partner absorbs overage on its own delays |
Change orders by default |
|
How much of discovery is automated? |
Agents handle inventory, mapping, and test generation |
Weeks of interviews billed by the hour |
|
Who actually does the work? |
Named engineers who have shipped production AI on AWS, embedded with your team |
Senior people at the pitch, junior staff at delivery |
|
How do you validate before cutover? |
Parallel run with field-level reconciliation on real data |
User acceptance testing in spreadsheets |
|
What happens to the legacy system? |
Decommissioning is a contracted deliverable |
"Out of scope" |
|
Can we speak to a regulated production reference? |
A named customer with an audit outcome |
Logos with no outcomes attached |
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.