AWS Database Blog

The New York Times cut Oracle migration time from 18 to 5 months

The New York Times (NYT) operates PLATO, the subscription revenue engine that processes payments for millions of digital subscribers. This post describes how NYT partnered with AWS and Mactores, an AWS Partner, to migrate PLATO from Oracle to Amazon Aurora PostgreSQL-Compatible Edition using an AI-agent-native approach built on Amazon Bedrock. According to NYT, the team completed the migration in approximately 5 months with zero revenue impact at cutover and full production throughput sustained at go-live.

An initial AWS Schema Conversion Tool scan identified approximately 110,000 conversion items across three schemas and more than 8,000 analyzed application files containing nearly 6 million lines of code, including deeply embedded Oracle SQL. The pre-migration assessment estimated roughly 200 CPUs of Oracle licensing, and early rule-based estimates placed the migration effort at up to 18 months. The team compressed that 18-month effort into about 5 months with zero revenue impact at cutover and full production throughput sustained at go-live with no degradation.

Results at a glance

The team migrated PLATO, NYT’s digital subscription revenue engine, from Oracle to Amazon Aurora PostgreSQL. The migration eliminated the downtime and scalability risks by removing ongoing Oracle licensing and other operating costs. It also positions PLATO for multi-Region deployment and creates a repeatable pattern for future migrations.

This post details the tools, configuration, and cutover checklist that made this success possible, whether you are planning a similar migration or evaluating AI-powered database tools. You will learn what AWS Database Migration Service (AWS DMS) Schema Conversion and Amazon Bedrock with Claude each handled that traditional tools could not, and the operational readiness practices that earned business clearance for a zero-downtime cutover.

Challenge

The PLATO system presented several compounding challenges that had defeated prior migration attempts:

Scale and complexity – The Oracle environment comprised approximately 110,000 conversion items across three schemas, with Oracle-specific constructs deeply woven into the application layer. Embedded Oracle SQL appeared across Java, Gradle/Groovy DSL, Python, Go, and shell scripts, far beyond what any single rules-based tool could address.

Revenue criticality – PLATO processes subscription revenue for millions of NYT readers. Any migration disruption could result in immediate, measurable revenue loss, so the margin for downtime was effectively zero.

Licensing pressure – Roughly 200 CPUs of Oracle licensing, on a per-CPU cost model, and an upcoming renewal created urgency to move, even as the compressed timeline increased risk for a revenue-critical system.

Solution overview

The AWS team partnered with Mactores to deploy their Aedeon Agent, an AI-native migration agent built on Amazon Bedrock (Claude Opus 4.6) alongside AWS DMS and Schema Conversion services. The approach combined automated schema conversion at scale with application code remediation.

The following diagram shows how three components worked together to migrate from Oracle to Aurora PostgreSQL: AWS DMS Schema Conversion, Amazon Bedrock (through the Mactores Aedeon Agent), and AWS DMS continuous replication. AWS DMS Schema Conversion handled database-object transformation. The Mactores Aedeon Agent, running on Amazon Bedrock with Claude Opus 4.6, ran a five-stage code-conversion pipeline (database schema analysis, embedded-SQL remediation in application code, parity-test generation, and validation) orchestrated by AWS Step Functions to remediate multi-language application code. Finally, AWS DMS managed continuous data replication from Oracle to Aurora PostgreSQL, with a reverse-replication (rollback) path to Oracle for a zero-risk cutover.

Architecture diagram of the Oracle to Amazon Aurora PostgreSQL migration using AWS DMS Schema Conversion, the Mactores Aedeon Agent on Amazon Bedrock, and AWS Step Functions

Figure 1: Oracle to Amazon Aurora PostgreSQL migration architecture using AWS DMS, the Mactores Aedeon Agent on Amazon Bedrock, and AWS Step Functions

Prerequisites

You must have the following prerequisites:

Division of responsibilities

NYT Engineering and Operations – NYT owned the PLATO application and environments, used generative AI to understand the legacy system, and led the migration end-to-end. The NYT team designed the migration approach, set up and tuned AWS DMS, built the rollback plan that made cutover safe, provisioned and hardened the target Aurora infrastructure, and owned quality assurance and validation of schema, data, and application behavior. NYT engineers supplied subject-matter expertise, test coverage, DevOps automation, and final production sign-off.

AWS team – The AWS team performed the initial level-of-effort assessment on the PLATO database and Java application, provided Database Migration Accelerator (DMA) specialists and PostgreSQL expertise, and partnered on staging cutover rehearsals and performance tuning. AWS also helped unblock data replication issues and tuned AWS DMS configuration as the migration progressed.

Mactores team – Mactores ran schema conversion and embedded SQL remediation across approximately 6 million lines of code using the AI-powered Aedeon Agent on Amazon Bedrock (Claude) and Amazon Bedrock AgentCore. The Mactores accelerator handled large-scale code conversion and validation, working from NYT’s direction and test feedback to iterate toward a fully PostgreSQL-compatible code base.

Solution architecture: How DMS SC and Bedrock worked together

The migration architecture consisted of three distinct conversion and replication layers, each addressing a different facet of the Oracle-to-PostgreSQL transformation.

Layer 1: Schema conversion with AWS DMS Schema Conversion (SC)

AWS DMS Schema Conversion handled the bulk database schema transformation, converting database schema objects from Oracle to Aurora PostgreSQL-compatible data definition language (DDL). DMS SC performed well on the database-layer objects, automating most of the conversion of Oracle database schema objects with its built-in rules engine and flagging objects that required manual remediation.

Layer 2: Application code conversion – the multi-language challenge

NYT’s application code base spanned five languages (Java, Gradle/Groovy DSL, Python, Go, and shell scripts) with deeply embedded Oracle SQL throughout, which required a language-agnostic approach. Amazon Bedrock handles mixed-grammar files, such as Gradle build files that combine Groovy DSL and Java in a single file, by processing all languages in a single contextual pass.

Layer 3: Amazon Bedrock (Claude) – the AI-powered conversion engine

Amazon Bedrock addressed the multi-language challenge directly. By providing the target PostgreSQL schema as context, the AI models converted embedded Oracle SQL to PostgreSQL-compatible syntax across all file types and languages in the code base. The Mactores Aedeon Agent orchestrated this process. The agent:

  • Identified embedded Oracle SQL across every application file, regardless of host language.
  • Provided target schema context to Claude for accurate type mapping and function translation.
  • Ran iterative validation cycles: converting the code, testing it against Aurora PostgreSQL, collecting errors, and feeding them back to Claude for self-correction.
  • Scaled horizontally using Amazon Bedrock AgentCore to process more than 6 million lines of code in parallel.

This agent-native pattern proved essential. Where rule-based tools are constrained to specific languages, Amazon Bedrock offered contextual, language-agnostic understanding that could reason about Oracle constructs within any surrounding code.

Data migration architecture with AWS DMS

The data-migration layer used AWS DMS to continuously replicate Oracle to Aurora PostgreSQL. It also maintained a roll-forward path to a clone of the production Oracle database, which stayed current with every transaction from the Aurora primary after cutover, so a rollback to Oracle carried zero data-loss risk.

The following diagram shows the data migration and roll-forward architecture.

Diagram of AWS DMS replicating data from the source Oracle database to Aurora PostgreSQL, with roll-forward replication to a clone Oracle target

Figure 2: AWS DMS data migration and roll-forward architecture

Validating PostgreSQL with real production traffic

Synthetic load tests provided a baseline, but the team needed validation under real production conditions to be confident in a zero-revenue-loss cutover.

Before cutover, the team validated Aurora PostgreSQL against real production load rather than relying on synthetic tests alone. Using Apigee, they mirrored live PLATO traffic and ran shadow queries to PostgreSQL behind feature flags while Oracle remained the system of record. This surfaced query-plan and edge-case issues early and allowed fixes to roll out with zero client impact, which was critical to achieving a no-revenue-loss cutover. Shadow-traffic validation appears as a gate in the data validation and migration completeness section of the following cutover readiness checklist.

Cutover readiness checklist

The following checklist captures the key components required to obtain business clearance for go-live. We distilled this from a comprehensive operational checklist to the critical gates that directly determine cutover success.

Infrastructure and configuration readiness

  1. Application configured with correct Aurora endpoints (writer cluster endpoint for writes, reader endpoints for reads), with failover behavior validated.
  2. DB cluster and instance parameter groups aligned with production workload. Key parameters (for example, max_connections, work_mem, and autovacuum settings) tuned based on load testing.
  3. Infrastructure provisioned with Terraform or AWS CloudFormation with versioned, peer-reviewed templates and consistent configuration across dev, staging, and production.

High availability and disaster recovery (DR)

  1. Multi-AZ Aurora deployment enabled, with planned failover scenarios executed and validated.
  2. Failover priority and promotion order configured and verified for writer and reader instances.
  3. Disaster recovery strategy (cross-Region or cross-AZ), including recovery point objective and recovery time objective (RPO/RTO) targets, documented and tested in a production-like environment.

Security clearance

  1. Least-privilege database users and roles created for application, support, and database administrator (DBA) access, with auditing enabled.
  2. VPC subnets and security groups locked down (no public access), connectivity restricted to approved networks.
  3. Encryption at rest with AWS Key Management Service (AWS KMS) and in transit (TLS/SSL) enabled and validated end-to-end.
  4. Deletion protection enabled on the Aurora cluster.
  5. Database auditing (pgAudit) configured, with logs forwarded to centralized logging for review.
  6. External firewall rules updated to permit Aurora connectivity only from authorized application and admin networks.

Monitoring and alerting

  • Performance Insights enabled (with encryption) and actively used for query and wait-state analysis.
  • Enhanced Monitoring enabled at an appropriate level of detail for OS-level visibility.
  • PostgreSQL logs streamed to Amazon CloudWatch with appropriate retention and filters for error patterns.
  • CloudWatch alarms configured for CPU, memory, storage, replication lag, connection count, and disk I/O.
  • Amazon Relational Database Service (Amazon RDS) event subscriptions set up for critical notifications (failovers, maintenance, and parameter changes).
  • Support teams trained on alert runbooks and escalation paths, including how to engage AWS Support.

Data validation and migration completeness

  • Row-level data validation scripts executed and passing within agreed thresholds.
  • AWS DMS replication lag at zero, with all in-scope tables in change data capture (CDC) state at cutover.
  • Critical and latency-sensitive query execution plans reviewed and tuned on Aurora PostgreSQL.
  • Sequences, constraints, triggers, and indexes validated and ready to be activated post-cutover (scripts prepared and tested).
  • Sample end-to-end record tests executed to confirm data flow through upstream and downstream systems.

Rollback readiness

  • Roll-forward (reverse) replication from Aurora PostgreSQL back to Oracle tested and validated.
  • Oracle rollback target pre-provisioned with all SQL baselines and fixed plans from production so that, in a rollback scenario, the roll-forward database performs like the previous production.
  • Rollback runbook documented, reviewed, and rehearsed in a non-production environment.
  • Network and firewall rules validated to support reverse replication and rollback paths.

Operational readiness

  • Support and on-call teams have access to all required environments and tooling.
  • Sample alerts exercised end-to-end to confirm routing to the correct support groups.
  • The configuration management database (CMDB) and internal records updated to reflect the new Aurora environment and dependencies.
  • No pending Aurora maintenance or planned changes overlapping the cutover window.
  • CloudWatch alarms in a clean state with no active alerts or abnormal resource consumption.
  • Performance Insights reviewed with no unexplained query or wait-state anomalies.
  • Recent Aurora events reviewed for warnings or errors that could affect cutover.

Results

The migration delivered on all three dimensions that had stalled prior attempts: speed, reliability, and cost. NYT completed the migration in approximately 5 months, a 72% reduction from the 18-month estimate, and sustained 18,500 requests per second at go-live with zero revenue impact at cutover and 100% row-level data accuracy.

Conclusion

The New York Times PLATO migration demonstrates that AI-powered tooling on Amazon Bedrock can compress enterprise-scale database migrations by more than 70 percent while maintaining production reliability. Three key takeaways stand out:

  1. AI agents handle complexity that rules engines cannot – Where rule-based tools are constrained to specific languages, Claude used contextual reasoning to convert embedded SQL across any file type and language, at scale.
  2. The pattern is replicable – The combination of AWS DMS Schema Conversion for schema conversion, Amazon Bedrock for application code, and AWS DMS for continuous replication creates a repeatable architecture. NYT is already applying it to three additional Oracle workloads.
  3. Cutover confidence comes from operational readiness – The technical migration is only half the equation. A comprehensive cutover checklist covering high availability and disaster recovery, security, monitoring, data validation, and rollback readiness is what earns business clearance for go-live.

The NYT PLATO migration shows that complex Oracle-to-PostgreSQL migrations, with large code bases, embedded SQL across multiple languages, and zero tolerance for downtime, no longer need to be 18-month projects. The AI-agent architecture described here is a proven path that compressed an 18-month estimate to 5 months.

To learn more about the services behind this migration, see AWS Database Migration Service, Amazon Aurora PostgreSQL-Compatible Edition, and Amazon Bedrock. To start your own migration, open the AWS DMS console and review the AWS DMS Schema Conversion documentation.

About the authors

Eli DOE

Eli DOE

Eli is a Senior Database Migration Solutions Architect at Amazon Web Services (AWS). He works with AWS customers, certified AWS partners offering expert guidance and technical support for cloud migration initiatives. His role centers on enabling organizations to efficiently transition and modernize their databases in the AWS Cloud.

Shashank Nigam

Shashank Nigam

Shashank is a Customer Solutions Manager in AWS covering media and entertainment customers and helping them re-invent their businesses. He led the implementation and deployment of the solution on the customer’s AWS environment.

Manoj Duvva

Manoj Duvva

Manoj is a Senior Technical Account Manager at Amazon Web Services. In his role, Manoj collaborates with enterprise customers to architect, implement, and scale cloud-based applications to meet their business objectives. He is a subject matter expert in Amazon RDS for Oracle. Manoj is passionate about cloud computing, databases, automation, and artificial intelligence.

Rohit Arora

Rohit Arora

Rohit is a Staff Engineer within the Subscription Platforms Group at The New York Times. He is responsible for driving the design, development, and delivery of scalable, high-performance solutions that power the company’s subscription business. He specializes in building resilient distributed systems, modernizing platforms, and leading high-performing engineering teams to deliver innovative solutions that enhance customer experience, improve operational efficiency, and drive business growth.