AWS Migration Readiness Assessment: What the Checklist Doesn't Tell You

The AWS Migration Readiness Assessment is one of the most widely referenced frameworks in enterprise cloud migration. AWS Professional Services built it. Thousands of organizations have used it. And thousands of those organizations still ran over budget, over schedule, or both.

Not because the framework is wrong. Because it stops at the organizational layer — and migrations break in the database.

The AWS MRA evaluates cloud operating model maturity, security posture, business case alignment, team readiness. What it doesn't enumerate is the 3,800 stored procedures sitting in the Oracle instance, the COBOL batch job that reconciles the general ledger every night through Embedded SQL, or the cross-database view that nine downstream applications depend on and nobody thought to document. Those objects determine whether the migration takes five months or twenty. None of them appear in the MRA output.

A rigorous database-layer assessment is what converts the MRA's organizational picture into a complete one.

What AWS MRA Was Designed to Do — and Where It Stops

AWS formalized the Migration Readiness Assessment as a structured evaluation framework used by AWS Professional Services before any large-scale cloud engagement. It covers six domains: business drivers, migration planning, people and organizational structure, operating model and governance, platform and technical capabilities, and security and compliance.

The framework is legitimate and necessary. It surfaces organizational blockers — teams without cloud experience, unclear ownership of migration decisions, security controls that aren't cloud-compatible — before they become mid-project crises.

What it was not designed to do is audit the database layer at object resolution. Stored procedure complexity, Embedded SQL in application code, undocumented schema dependencies, projected automation rates for converting Oracle PL/SQL to Aurora PostgreSQL — none of that is in scope. That level of analysis requires a different instrument. And without it, the timeline and budget figures that come out of even a well-executed AWS MRA rest on incomplete technical data.

The consequences are well-documented. Oracle reports that over 80% of data migration projects either fail or exceed their budgets and schedules. McKinsey puts the average large-scale IT project at 45% over budget and 56% short of predicted value. The root cause is almost never poor execution. It is scope that was underestimated at the point of commitment.

AWS Target Services Are Not All the Same Conversion Problem

AWS is not a single migration destination. It is a catalog of managed database services with materially different compatibility profiles, and picking the right one is a technical decision that requires real data.

Amazon Aurora PostgreSQL — The primary destination for Oracle, Sybase ASE, Informix, and DB2 migrations. High performance, PostgreSQL-compatible, fully managed. Also the most technically demanding migration path available on AWS. Oracle packages, PL/SQL procedural logic, and Sybase-specific syntax require systematic conversion analysis to determine what automates and what requires manual rework. This is where Oracle-to-AWS projects most commonly double their original timelines.

Amazon RDS for SQL Server — The natural landing zone for SQL Server workloads. Compatibility looks high until the assessment surfaces SQL Server Agent job dependencies, linked server references, or cross-database queries that require architectural adjustment under RDS's managed model.

Amazon RDS for PostgreSQL — Similar migration profile to Aurora PostgreSQL without the Aurora-specific performance and availability features. The assessment output determines whether Aurora's additional cost is justified by the workload's requirements.

Amazon Redshift — For data warehouse migrations from Teradata, Netezza, or on-premises SQL Server warehouses. The assessment here is schema and query pattern analysis: how aggregate functions, window functions, distribution keys, and sort keys behave in Redshift's columnar architecture compared to the source.

Amazon DynamoDB — For NoSQL migration paths. There is no direct structural mapping from a relational schema to DynamoDB's key-value model. Access patterns drive schema design in DynamoDB; this is a redesign exercise, and the assessment scopes how much of the source data model survives the transition intact.

Choosing the wrong target service isn't corrected with configuration. It triggers rework after commitments have been made, contracts signed, and engineering hours spent. The assessment tells you which service the source environment is actually compatible with — at object resolution, not at the category level.

Six Dimensions a Complete AWS Assessment Must Cover

Table counts and storage volumes are a starting point. A credible AWS migration readiness assessment at the database layer covers six dimensions. Skip any one of them and the scope the project plan is built on has a hole in it.

Database Object Inventory 

Every table, view, stored procedure, trigger, index, sequence, package, function, and the full dependency graph that connects them. For Oracle-to-Aurora PostgreSQL migrations — currently the highest-volume enterprise migration path, accelerated by Oracle licensing costs that compound under standard support renewal terms — this means enumerating two decades of accumulated PL/SQL logic, not sampling it. 

The same discipline applies to SQL Server, Sybase ASE, DB2, Informix, and MySQL environments where business rules have embedded in the database layer for years without systematic documentation.

Complexity Classification 

Every object carries a conversion cost, and those costs are not uniform. A mature assessment classifies each object: simple (high automation coverage), medium (automatable with minor adjustment), complex (requires configuration or customization), manual (requires direct human intervention). Strip out this classification and every downstream budget figure becomes a guess dressed up as an estimate.

Embedded SQL in Application Code 

COBOL batch jobs, PowerBuilder applications, Progress 4GL systems, Delphi clients, and C++ services frequently reach into the database through Embedded SQL blocks that exist entirely outside the schema. An assessment that scopes only the database produces a number that is wrong by a factor of two or three. In financial services, insurance, and government environments where COBOL-driven batch processing handles the most critical workloads, the application layer routinely represents more total migration complexity than the database itself.

Dependency Mapping 

Linked server queries, cross-database references, ETL pipelines, API consumers, reporting tools, and third-party integrations. Every broken dependency that surfaces after cutover is one that could have been mapped during assessment. Finding it post-migration — in downtime, emergency engineering hours, and credibility with stakeholders — costs orders of magnitude more than finding it beforehand.

Cloud Readiness of the Source Environment 

Moving a database to AWS changes the infrastructure around it, not just the schema inside it. Latency characteristics shift when the workload moves into a VPC. Connection pooling behavior changes under RDS and Aurora's managed connection model. Data residency requirements may constrain which AWS region is available. Compliance frameworks — SOC 2, HIPAA, PCI DSS — impose controls that must be validated against AWS's shared responsibility model before the migration architecture is finalized. These belong in the assessment, not in an implementation-phase discovery call.

Risk Register and Identified Gaps 

The assessment closes with an explicit enumeration of blockers: objects that cannot be automatically converted, deprecated syntax with no direct AWS equivalent, missing schema elements, broken references, database-specific features with no clean migration path. This is where all project cost uncertainty lives. If the assessment doesn't name it, the project plan doesn't account for it — and the budget absorbs it instead.

7 R's Require Data You Don't Have Without the Assessment

AWS extends the standard 5 R's migration framework to 7 R's: Rehost, Replatform, Refactor, Repurchase, Retire, Retain, and Relocate. The right organizing structure for migration decisions. The problem is that most teams assign a strategy to each workload before they have the technical data to justify it.

Rehost is defensible when the assessment shows high structural compatibility, minimal proprietary syntax, and a schema that maps cleanly without conversion work. Many SQL Server-to-RDS-for-SQL-Server migrations land here. The assessment confirms it rather than assumes it.

Replatform fits when the schema is portable but stored procedures require moderate rework, or when source platform licensing costs justify the conversion effort to a more economical AWS service. The assessment quantifies the rework and validates the economics.

Refactor — the most expensive, highest-risk path — is indicated when the assessment surfaces deep proprietary dependencies: Oracle packages, Sybase row-level security, Informix SPL logic, architectural patterns built for an on-premises transaction model that have no managed-cloud equivalent. Teams that pick Refactor without assessment data routinely underestimate scope by 40 to 60 percent.

When the project runs six months over schedule, "We didn't understand the source environment before we committed." is a failure of process. The assessment is the process.

Why Manual Audits Break Down at Enterprise Scale

The traditional pre-migration audit — consultants reviewing source code by hand for weeks, sampling stored procedures, delivering a report that's already partially outdated — has a structural problem that has nothing to do with consultant quality. Sampling is not enumeration.

Human reviewers miss ESQL blocks embedded in COBOL copybooks that only execute during month-end close. They miss stored procedures that fire under specific transaction conditions and never appear in standard query logs. They miss deprecated syntax that becomes a hard blocker during user acceptance testing — the most expensive possible moment to discover it. The report reflects what was reviewed, not what exists.

Automated assessment tools eliminate this by connecting with read-only access, walking every object in the schema, and producing a structured report in minutes. For an enterprise running Oracle, SQL Server, DB2, and Informix across dozens of source databases — a common AWS migration profile — manual review at that scale doesn't fit inside a planning phase. It barely fits inside a quarter.

There's also a business case dimension. A board presentation built on a consultant's sampling report rests on professional judgment. A presentation built on automated enumeration of 5,100 objects with object-level complexity ratings and projected automation rates is built on auditable data. These produce different conversations when it's time to approve the budget.

Read more:Best Cloud Migration Assessment Tools in 2026

What a Complete AWS Assessment Delivers

At the end of a rigorous assessment, the project team should have the following — derived from direct analysis of the actual source system, not from analogous project benchmarks:

• A complete object inventory by type with object-level complexity ratings and projected automation coverage for the target AWS service.
• Embedded SQL analysis across all relevant application code — COBOL, PowerBuilder, Progress 4GL, Delphi, C++ — with line counts and complexity classification for each code asset.
• A dependency map covering cross-database references, linked server usage, ETL integration points, and downstream system consumers.
• A risk register enumerating objects requiring manual conversion, deprecated syntax without AWS equivalents, missing schema elements, and broken references.
• A project timeline range and cost estimate derived from assessed complexity — not from industry benchmarks.
• A cloud readiness evaluation specific to the target AWS service: compatibility profile, architectural implications, and infrastructure prerequisites for the VPC, security group, and IAM model the workload will operate under.

Anything less is the start of a scoping conversation, not the end of one.

InsightWays: Database Assessment the AWS MRA Doesn't Cover

Ispirer InsightWays connects to Oracle, SQL Server, PostgreSQL, Sybase ASE, DB2, Informix, MySQL, MariaDB, and AlloyDB source environments with read-only credentials. No data leaves the environment. No modifications are made to the source system. The tool runs entirely offline.

The output covers 44+ analytical dimensions: 

• full object count by type with complexity classification; 
• projected automation rate using SQLWays for the assessed migration path — Oracle to Aurora PostgreSQL, SQL Server to Amazon RDS, MySQL to Amazon RDS for MySQL;
• manual adjustment requirements and tool customization recommendations that increase automation coverage before migration work begins; 
• embedded SQL analysis within COBOL, PowerBuilder, Delphi, Progress 4GL, Informix 4GL, and C++ application code; 
• time and effort estimates usable for project planning, budget approval, and AWS MAP program documentation.

The latest release added full ESQL support — application-embedded database code is now analyzed alongside the database schema. For AWS migrations involving COBOL batch processing or old application stacks, this closes the single largest blind spot in pre-migration scoping. Script analysis speed has also increased by up to 6x, so large codebases no longer require overnight runs.

InsightWays is free. No payment, no registration, no trial period. Download the tool, connect with read-only credentials, generate the report in under five minutes.

Run it before you finalize your AWS MRA. Run it before you engage AWS Professional Services or a migration partner. Run it before you present a timeline to leadership. The MRA tells you whether your organization is ready to migrate. InsightWays tells you what you're actually migrating.

Pre-Assessment Checklist for AWS Migrations

Before running your assessment, confirm the following:

1. Read-only access credentials to the source database environment. 
2. Application source code repository access for ESQL and embedded code analysis. 
3. Documentation of known integrations, ETL pipelines, and downstream system dependencies. 
4. Identified target AWS service and migration path. 
5. Network architecture documentation covering connectivity between source environment and target VPC. 
6. Compliance framework requirements — SOC 2, HIPAA, PCI DSS — that constrain the target region, service tier, or encryption configuration. 
7. Stakeholder alignment on acceptable downtime windows and data freeze requirements.

For migrations from Oracle or other old platforms to Aurora PostgreSQL, add a schema-level inventory of proprietary features — packages, sequences, object types, database-specific procedural syntax — before finalizing the conversion strategy.

Stop Estimating. Start Knowing.

The cost of skipping the database assessment shows up the same way every time. A budget that made sense in month one doesn't survive contact with the actual source environment in month three. An emergency freeze on a half-migrated production system. A compliance incident from data flows that crossed a boundary no one mapped.

It shows up as a project scoped at six months that finishes — if it finishes — in eighteen.

InsightWays gives you the complete picture in five minutes, for free. Object count. Complexity breakdown. Automation rate. Manual effort. Blockers. Timeline range.

Run the assessment. Know what you're moving. Then commit.

Download InsightWays — free forever, no registration required. Or book a 30-minute demo to walk through your AWS migration assessment report with an Ispirer expert.