Reported operating use · Media and subscription-platform engineering
AI database migration: The New York Times example
An AWS account coauthored by a New York Times engineer describes migrating the PLATO subscription revenue platform from Oracle to Aurora PostgreSQL. A Mactores agent converted embedded SQL, while NYT engineers owned the design, quality assurance, rollback plan and final production sign-off.
Convert embedded database queries and verify a subscription-platform migration
The New York Times
Reported completed production migration of the PLATO subscription revenue platform.
A published third-party example, not a Nuvepro customer case or evidence of a partnership.
The workflow at a glance
Convert queries before a controlled cutover
Illustrative summary of the published account
Reported work components. Their arrangement does not imply a fixed execution order or simultaneous work.
- Conversion
Database objects and embedded SQL
Schema tools convert objects; the Mactores agent converts embedded application queries and iterates on test failures.
- Pre-cutover checks
Mirrored traffic and shadow queries
Feature-flagged comparisons run while Oracle remains the system of record.
- Engineering
Migration design and final sign-off
NYT engineers own infrastructure, QA, rollback and production approval.
What the source reports
An AWS account coauthored by a New York Times engineer describes migrating PLATO from Oracle to Aurora PostgreSQL. Schema-conversion tools handled database objects; the Mactores agent converted embedded SQL in application code and iterated against test failures. NYT engineers owned the migration design, infrastructure, quality assurance, rollback plan and final production sign-off. Before cutover, the team mirrored production traffic and ran shadow queries behind feature flags while Oracle remained the system of record.
Reported technology: AWS and Mactores; Aedeon Agent with Claude on Amazon Bedrock. Scope and outcomes are source-reported.
What the enterprise environment would need
The following is a proposed project design for an enterprise doing similar work. Published details are marked; the remaining systems, data and scenarios would be agreed for your project.
Proposed practice environment
Rehearse subscription database conversion
Illustrative project design to scope with your enterprise.
- 1 · Set up the environment
Isolated source and target databases
Use a fictional subscription application with versioned renewal, cancellation and refund transactions.
- 2 · Preparation and agent contributions
Agent proposes SQL conversions
Retain original queries, converted revisions and replayable fixtures.
- 3 · Independent checks
Independent behavior comparisons
Check decimals, dates, nulls, failures, duplicate charges and missing refunds against prepared outcomes.
- 4 · People decide acceptance
Engineer accepts a cutover rehearsal
Explain every mismatch and verify recovery preserves transaction identity and order.
A reviewable evidence package
A query-conversion package and reproducible source/target comparison report.
If a check fails → withhold acceptance.
A refund query passes syntax checks but changes rounding. Hold acceptance and correct the financial behavior.
Failure or owner rejection returns to review
- Hold
- → 2 · Revise work
- → 3 · Rerun independent checks
- → 4 · Owner review
Operating boundary. No live billing or production cutover; engineers retain separate deployment authority.
- Systems and evidence
- Proposed: provide isolated source and target databases, a small fictional subscription application and versioned renewal, cancellation and refund records.
- People and agents
- Proposed: an agent suggests query conversions and test cases. Engineers independently check behavior, investigate mismatches and retain cutover authority.
- State and permissions
- Proposed: preserve original queries, converted revisions and replayable transaction fixtures. Keep live billing and production deployment outside the practice environment.
A proposed simulation
An illustrative practice design derived from this work, not an executed assessment.
Proposed: convert a fictional subscription workflow to a new database and prepare a traceable behavior-comparison report for engineering review.
Review gate: An independent engineer can reproduce matching outcomes and explain every exception before separately approving a cutover rehearsal.
Challenge the result: A converted refund query passes syntax checks but changes decimal rounding. The review must detect the discrepancy and withhold acceptance.
What needs checking
- Proposed: compare source and target results with independently prepared expected outcomes, including decimals, dates, nulls and transaction failures.
- Proposed: detect duplicate charges, missing refunds and differences that a syntax-only check would miss.
- Proposed: rehearse a failed cutover in isolation and confirm that recovery preserves transaction identity and ordering.
Review environment fidelity, human capability and agent performance separately. The enterprise’s accountable owners decide acceptance of the shared workflow and any operating use.
How an enterprise could build similar work
A proposed build order for an enterprise doing similar work, written by Nuvepro from the published account and our interpretation of the environment and checks above. It is not how The New York Times built or operates this work.
- Build isolated source and targetThis is a proposed design for a similar project, not NYT's migration. Provide isolated source and target databases, a small fictional subscription application and versioned renewal, cancellation and refund records.
- Preserve queries and fixturesPreserve original queries, converted revisions and replayable transaction fixtures. Keep live billing and production deployment outside the practice environment, so every conversion can be traced, rerun and compared against the original query by a reviewer.
- Split agent and engineer dutiesAn agent suggests query conversions and test cases. Engineers independently check behaviour, investigate mismatches and retain cutover authority, so the agent's output is evidence to review and not a decision.
- Compare against expected outcomesCompare source and target results with independently prepared expected outcomes, including decimals, dates, nulls and transaction failures. Detect duplicate charges, missing refunds and differences that a syntax-only check would miss.
- Plant a rounding failureInclude a converted refund query that passes syntax checks but changes decimal rounding. The review must detect the discrepancy and withhold acceptance, which shows whether the checks test behaviour and not only valid SQL.
- Rehearse cutover and recoveryRehearse a failed cutover in isolation and confirm that recovery preserves transaction identity and ordering. An independent engineer reproduces matching outcomes and explains every exception before separately approving a cutover rehearsal.
Your systems, data, rules and accountable owners decide the real project. Agree acceptance criteria, escalation owners and operating responsibility with the people accountable for the work before anything runs on live records. Treat the first run as a rehearsal on test records: compare the draft output with an independently prepared answer, and record what the people reviewing it change.
Questions about this example
- What does The New York Times use AI for in this migration?
- Schema-conversion tools handled database objects, and the Mactores Aedeon Agent, using Claude on Amazon Bedrock, converted embedded SQL in application code and iterated against test failures. This was part of migrating PLATO from Oracle to Aurora PostgreSQL.
- Who checks the AI's work in the PLATO migration?
- NYT engineers owned the migration design, infrastructure, quality assurance, rollback plan and final production sign-off. Before cutover, the team mirrored production traffic and ran shadow queries behind feature flags while Oracle remained the system of record.
- How strong is the evidence for this New York Times example?
- The evidence class is reported use: a completed production migration described in an AWS account coauthored by an NYT engineer. It is not an independent outcome audit, and the reported schedule compares against an initial estimate, not a controlled measure of what AI contributed.
- What would an enterprise need to build something similar?
- This is Nuvepro's proposed design, not NYT's systems. It would use isolated source and target databases, a small fictional subscription application and replayable transaction fixtures, compare results against independently prepared expectations, and rehearse a failed cutover with live billing kept out of scope.
Shape this around your enterprise
Bring a similar workflow and the people responsible for it. Together, define the records and systems to use, the result your team will build or configure, and how its owners will check it. Nuvepro scopes the simulation, environment and preparation. Agree any existing-agent evaluation, implementation assistance and production responsibilities separately.
Sources and limitations
Curation review: . This is the date this source example was reviewed, separate from source publication dates.
- The account is published by AWS and coauthored by a customer engineer; it is not an independent outcome audit.
- The reported schedule compares completion with an initial estimate, not a controlled measure of the contribution of AI. No schedule reduction is adopted here as an acceptance target.
- The proposed environment and checks are illustrative designs, not an executed Nuvepro migration or a replica of NYT systems.
- The New York Times cut Oracle migration time from 18 to 5 monthsSource publication: 2026-10-26
More software engineering examples
- AI content platform migration: Wimbledon exampleAll England Lawn Tennis and Croquet Club (Wimbledon)
- AI chip verification workflows: OpenAI exampleUnnamed semiconductor company
- AI energy model customization: Exowatt exampleExowatt
- AI engineering agent coordination: Deel exampleDeel