A 40-year-old insurer runs COBOL policy admin on a mainframe with VSAM files and nightly batch windows, facing retiring operators and a mandate to add web APIs and move off the data center in 14 months. Which migration strategy best modernizes this legacy mainframe and database workload?

The correct strategy succeeds because automated refactoring with AWS Transform for mainframe (the current AWS path; AWS Mainframe Modernization is closed to new customers) converts COBOL to Java services that can expose web APIs and run on managed compute without mainframe operations, while converting hierarchical VSAM data sets into Aurora PostgreSQL tables preserves transactional integrity and removes the nightly batch and data-center dependencies within the 14-month window. Rehosting with Micro Focus on EC2 fails by concept of operating model because it preserves the COBOL runtime and scarce operator skills and only moves infrastructure without delivering cloud-native APIs or reducing skill risk. Manual rewriting to Java microservices on EKS fails by concept of delivery timeline because hand recoding and testing parity for 40 years of policy rules plus VSAM layout conversion cannot reliably complete and validate in 14 months compared to automated refactoring. Refactoring to Java but landing VSAM in S3 lakes for Athena access fails by concept of workload fit because object storage plus query engines serve analytics, not the ACID transactions, locking, and low-latency reads and writes that policy administration requires. Exam caveat is to map legacy keywords to strategy: retiring skills plus API mandate plus fixed deadline points to automated refactoring, not lift-and-shift, manual rewrite, or an analytics lake. Practical check is to inventory COBOL copybooks, VSAM key sequences and batch job dependencies, run a pilot conversion and test data load, and validate API latency and batch-window performance on Aurora before full cutover.