Cloud Readiness Assessment: What a Discovery Sprint Finds

Most AWS migrations we've seen run over budget had the overrun built in before the first workload moved. The estimate rested on an inventory nobody finished, and the missing pieces were small and dull: a stored procedure nobody owned, a batch job the finance close depended on, a database license that renewed in the middle of cutover.

Take a made-up but typical case that we'll follow through this guide. A hotel group with about 110 properties, most of them in the US and 14 in Spain and Portugal, has to leave a colocation facility whose lease ends next October. Its first assessment came from a large consultancy that ran an infrastructure scan and interviewed the IT leads. It counted 520 virtual machines, recommended rehosting nearly all of them and put the program at 12 months, and the board approved the budget on that basis. Nobody had opened the reservation database, which is where much of the business actually ran.

A cloud readiness assessment exists to catch that kind of thing while it's still cheap to fix. We've been shipping production systems on AWS for 18 years, including HIPAA-audited and PCI-aligned ones, and we think an assessment has earned its fee only if it ends in a scope, a ship date and a fee that someone is willing to sign. Anything less is a report that sits in a shared drive until the program slips.

What is a cloud readiness assessment, and what should it decide?

It's a structured look at your applications, data, infrastructure, security controls and operating model, done to decide three things: which workloads move to the cloud, which path each one takes and what the program will cost. The commit-grade version, which is the one we'd ask for, goes a step further and puts a scope, a ship date and a fee on paper for you to sign.

Kaja Hussain, a Sr. FDE in Database and Application Modernization at Mactores, makes the point in a guide to application modernization: "Application modernization estimates slip in discovery, not the build." Engineers estimate a build well because they can see it. What they can't estimate is the part of the estate nobody has opened yet, which at the hotel group was the reservation database.

So a cloud migration readiness assessment should answer three questions with evidence a finance team could audit, and the hotel group's two assessments answered them very differently.

How is it different from an AWS Migration Readiness Assessment?

The two cover different halves of the problem. AWS describes its migration readiness assessment as "a process of gaining insights into how far along an organization is in their cloud journey," scored against the six perspectives of the AWS Cloud Adoption Framework: business, people, governance, platform, security and operations. AWS uses it as the model for the assessment phase of large migrations, and it's good at organizational gaps, like an operations team that has never run anything in the cloud, which was true at the hotel group. It isn't built to open the reservation database and count what's inside, so we'd treat it as the organizational half and discovery as the estate half.

Why do so many cloud readiness assessments miss the real risk?

Because most of them measure infrastructure and stop at the database boundary. Server counts, CPU utilization and a readiness questionnaire are quick to collect. The business logic sitting in stored procedures, scheduled jobs and integration code takes longer to find, and that's usually where the budget breaks, as it would have at the hotel group.

We've inherited enough stalled programs to recognize the pattern: a thorough-looking deck, a reasonable rehost estimate and then a few hundred stored procedures nobody had counted. Ammar Nizami, a Senior Forward-Deployed Engineer in our Data Engineering practice, sets the bar in a piece on Amazon Redshift as an enterprise data warehouse, saying "we wouldn't accept a date from anyone who hasn't inventoried every object first." We hold our own assessments to the same rule.

If your last assessment looked like the left column, you're in good company. It's the industry default, and it goes a long way toward explaining why so many programs go back to the board for a second budget halfway through.

What does Mactores' Discovery Sprint actually surface?

Six layers of findings, shown in the second figure below, and each one changes a decision in the plan. The sprint ends when you sign the scope, the ship date and the fixed fee that those findings support.

It's phase 01, "Scope and commit," of the five-phase model on our how we work page, which is blunt about what closes it: "You sign the scope, the date and the fee before any build work begins." Aedeon, the agent platform we deliver with, runs source discovery, schema and dependency mapping and code analysis, and it absorbs 60–70% of the engagement work. Our forward-deployed engineers spend their time on the calls software shouldn't make by itself, like the target architecture, which workloads to retire and where the riskiest assumption sits.

Why does the data layer hold the biggest surprises?

Because business rules drift into it for decades without anyone writing them down. At the hotel group, about 600 of the 1,900 stored procedures turned out to hold rate rules, package pricing and the loyalty-point math, and none of the current engineers had written them. Kaja's guide describes the same thing in most legacy estates, where "the data layer holds more business logic than the application code does."

That finding drove the most expensive decision in the program. The loyalty database was mostly storage, so it could move to Amazon Aurora PostgreSQL with conversion tooling and a validation pass. The reservation database was another matter, and it needed refactoring judgment, a regression harness and a cutover plan with the old and new systems running in parallel. That's how our application and database modernization practice handles Oracle and SQL Server estates, and the dependency graph from discovery is what tells us which database takes which path.

How does the sprint check whether your data is ready for AI agents?

With three checks our data engineering team runs on every estate: could an agent find the right table, read fresh data under its own identity and leave a trail an auditor could follow? The hotel group wanted a revenue-management copilot to suggest room rates once it was on AWS, and its data failed all three. There were three tables called some version of "rate" with no record of which one was current, the rates refreshed once a night, and every report read them through one shared service account. While the target architecture is still a drawing, those are design decisions, and a year after cutover they'd mean rebuilding part of the new platform.

What cutover risks does discovery expose?

The calendar ones, mostly, along with the people who carry knowledge nobody wrote down. The hotel group's summer freeze runs from June through mid-September, which took three and a half months out of a 12-month plan before anyone had moved a server. Its Oracle support renews on June 30, and the night audit job that feeds the general ledger had been written by a contractor who left in 2019. We'd much rather find all three in the first week of discovery than in the tenth week of the build, when the only choices left are a slipped date or a rushed weekend.

How does a cloud readiness assessment handle compliance in the US and EU?

By tracing every regulated data flow to the controls it needs before anyone draws the target architecture. What comes out is an evidence plan that says which controls carry over, which get rebuilt in the AWS landing zone and what auditors will want to see at each phase gate.

IBM's 2026 Cost of a Data Breach study puts the global average cost of a breach at $4.99 million, and a migration is one of the few times regulated data lives in two environments at once, so the cutover plan doubles as a security plan. At the hotel group, discovery found unmasked card numbers in a log table of the group-sales app and a nightly job copying European guest profiles to a marketing database in the US. Neither would have shown up in a server scan.

For the hotels in Spain and Portugal, the practical calls came down to which EU Region to use, whether to hold its own encryption keys and how to stop that nightly copy of guest profiles to the US. We settle those during discovery, because changing them after the data has moved is slow and expensive, and hard to explain to a regulator. The AI Act's rules for the high-risk systems in Annex III, which would cover something like an AI tool screening job applicants for the Spanish hotels, now apply from December 2, 2027.

Regulated work runs on the same delivery model with stricter settings. When KlearTrust came to us, two earlier claims-automation pilots had stalled at the PHI and audit handoff. We designed PHI handling, lineage capture and decision-time audit logging in from the start, and the KlearTrust agentic claims platform reached production in 12 weeks and passed HIPAA and internal audit on first review.

What does a cloud readiness assessment cost, and what does skipping one cost?

It scales with the estate: how many applications, databases and database objects are in scope, how much regulated data there is and how many integrations connect it all. Automated discovery keeps the analyst-hours line small. The larger number is what an incomplete assessment costs later, in change orders, extra months of parallel running and licenses that keep billing.

Cloud waste is the slow version of that bill. Flexera's 2026 State of the Cloud report found that 29% of cloud spend is wasted, the first increase in five years. Some of it starts during migration, when workloads get sized from estimates and nobody comes back to them.

Where does the money for modernization actually come from?

For most mid-market and enterprise teams, a good share of it is already in the run rate. It sits in database license renewals, a reporting server nobody builds on anymore and an integration tier that bills hours to keep itself alive. Ammar's guide to Oracle and SQL Server modernization on Amazon Aurora makes the same point, that "a good part of the AI budget most enterprises think they need is already sitting inside existing IT spend."

Discovery puts a number on that trapped spend, line by line, so the CFO can see which renewals can be exited and when. For the hotel group, that meant timing the reservation cutover for May, so the Oracle support it would no longer need didn't renew on June 30. Synaptics went through the same exercise when it moved Oracle-bound design analytics to Amazon RDS, and the case study sums up the outcome: "The license renewal that was inevitable became the budget that funded the next initiative." For eligible workloads, AWS's Migration Acceleration Program (MAP) can help offset part of the migration cost as well, and your account team will know whether yours qualify.

How long does a Discovery Sprint take, and what do you walk away with?

A few weeks, sized to your estate on a scoping call, so moving a single warehouse and moving a portfolio of a hundred applications get different timelines. Across our engagements, the median from kickoff to production is 12 weeks, and discovery is what makes a date like that believable.

The sprint ends at a phase gate where you sign the scope, the ship date and the fee before build begins. Under our delivery commitment, the fee is fixed against the scope confirmed at the end of phase 01, and Mactores carries the cost of the additional work if a delay inside our control moves the date. Delays caused on your side convert to time and materials at a rate disclosed upfront.

You keep every artifact. Even if you decide to run the build with another team, the inventory and dependency graph remain useful to whoever does the work.

How do you choose the right cloud readiness assessment partner?

Choose the cloud readiness assessment partner that will sign the estimate its own assessment produces. A firm that commits to a date and a fixed fee has every reason to make discovery thorough. A firm paid by the hour for the build has less reason to find the hard parts early.

Before you sign any statement of work for an AWS migration assessment, put these questions on the table:

1. Will the engineer who runs discovery also sign the delivery date?
2. Does the assessment inventory database objects, jobs, and reports, or only servers and storage?
3. Who pays if the date slips for a reason inside the provider's control?
4. Do you own the artifacts, including the object inventory and dependency graph?
5. How is the riskiest assumption tested before the full build starts?
6. How will old and new systems be reconciled before cutover?
7. Is retiring the legacy estate, including its licenses, part of the scope?

The answers usually sort providers into three engagement models.

The reconciliation question deserves extra weight. Our delivery model runs a generated harness that compares old and new systems on real data, object by object and field by field, before anyone flips traffic. In Poshmark's consolidation onto one AWS-native platform, a migration the team had called impossible, a validation harness ran in parallel against the live platform at each stage, and the cutover landed with zero product disruption.