A bank is migrating a self-managed Oracle database that backs a core ledger to Amazon Aurora PostgreSQL in a dedicated migration account. The schema contains hundreds of PL/SQL packages, triggers and proprietary data types, and discovery shows a fraction of these objects cannot be translated to PostgreSQL automatically. Leadership must see, before any migration work starts, a quantified estimate of the manual conversion effort so it can size the project, and the application team needs the translated schema applied to the Aurora target. The business will tolerate only a brief cutover and wants the engine objects converted with the least bespoke tooling. Which TWO uses of the AWS Schema Conversion Tool meet these needs? (Select TWO.)
- ARun the AWS Schema Conversion Tool assessment report against the Oracle source to classify each schema object as automatically convertible or needing manual action, giving leadership a quantified estimate of the residual conversion effort before work begins. Correct
- BUse the AWS Schema Conversion Tool to convert the Oracle schema and code objects to PostgreSQL and apply the converted data definition language to the Aurora PostgreSQL target so the structures exist before data is loaded. Correct
- CRely on AWS Database Migration Service alone to translate the PL/SQL packages, triggers and proprietary data types into PostgreSQL equivalents as part of the data migration task, removing any need for a separate schema conversion step.
- DTake a native Oracle Data Pump export of the full schema and import it directly into Aurora PostgreSQL, since the Data Pump dump already contains portable definitions that the PostgreSQL engine can read without conversion.
- EManually rewrite every PL/SQL package and trigger in PostgreSQL by hand from the Oracle source, treating bespoke re-authoring of all code objects as the way to keep tooling to a minimum for the conversion.
Why A is correct: The Schema Conversion Tool assessment report inventories every source object and flags which convert automatically and which need manual rework with effort indicators, so it gives leadership the quantified pre-migration estimate of manual effort the business case requires.
Why B is correct: Converting the schema and code objects to the PostgreSQL dialect and applying the generated data definition language to the target is the core job of the Schema Conversion Tool, so the translated structures are in place on Aurora before any data movement starts.
Why C is wrong: Database Migration Service moves data and can do a basic table and primary-key structure copy, but it does not translate stored procedures, triggers or proprietary types, so it cannot replace the Schema Conversion Tool for this heterogeneous code conversion.
Why D is wrong: An Oracle Data Pump dump is in a proprietary Oracle format that the PostgreSQL engine cannot read or interpret, so importing it directly fails and it performs none of the dialect translation the migration needs.
Why E is wrong: Hand-rewriting every code object is the maximum bespoke effort, not the least, and it ignores the automatic conversion the Schema Conversion Tool performs, so it directly contradicts the requirement to convert objects with the least custom tooling.