Legacy Code Modernization with AI: A 6-Week Framework

You have a Java monolith from 2009. 340,000 lines of code. Zero tests. Tight coupling everywhere. Business-critical. Can't rewrite it.

But you need to modernize it. Add features faster. Deploy more frequently. Reduce technical debt.

The traditional approach: 18-month rewrite project. 50% chance of failure. 80% chance of going over budget. 100% chance of business disruption.

I've used AI to modernize legacy codebases 6 times in the past year. The last one: A 280,000-line Java monolith to microservices architecture in 6 weeks. Zero downtime. Zero data loss. Production-ready.

This isn't about AI magically modernizing your code. It's about using AI strategically at each phase to accelerate what would normally take months.

Here's the framework that works.

Why Traditional Modernization Fails

Before the framework, let's understand why most legacy modernization projects fail:

Failure Mode 1: Big Bang Rewrite

• Plan: Rewrite everything in 12 months
• Reality: Takes 24 months, goes over budget, teams burn out
• Result: New system has different bugs, missing features, angry users

Failure Mode 2: Strangler Pattern Without a Plan

• Plan: "Extract services as we go"
• Reality: Inconsistent boundaries, duplicated logic, tangled dependencies
• Result: Both old and new systems in production, neither works well

Failure Mode 3: Analysis Paralysis

• Plan: Spend 6 months understanding the codebase
• Reality: Analysis never ends, no actual modernization happens
• Result: Fancy documentation, same legacy code

The Framework Avoids These By:

1. Fixed 6-week timeline (forces prioritization)
2. Incremental extraction with clear boundaries (strangler pattern done right)
3. AI-accelerated understanding (days not months)
4. Continuous deployment (validate every step)

The Case Study: JavaCommerce

To make this concrete, I'll use a real modernization project (company name changed):

System: JavaCommerce - E-commerce platform built in 2009 Tech Stack: Java 8, Spring Framework 3.x, JSP, Oracle 11g Size: 280,000 lines of code Deployment: Monthly releases, 4-hour maintenance windows Team: 6 engineers (4 Java, 2 DevOps) Business Context: Revenue-critical, 50K daily transactions

Problems:

• Features take 3-4 months to ship
• Deployments require maintenance windows
• Can't scale individual components (everything scales together)
• New engineers take 6 weeks to become productive
• Technical debt accumulating faster than we can pay it down

Goal: Extract payment processing and order fulfillment into microservices. Keep core catalog/cart as monolith (for now).

Week 1: Understanding and Mapping

Objective: Understand the codebase well enough to identify extraction boundaries.

Traditional approach: 4-6 weeks of manual code reading and diagramming. AI-accelerated approach: 5 days.

Day 1: Automated Code Analysis

Tool: GitHub Copilot + Custom Scripts

Task 1: Generate Dependency Graph

# Script: analyze_dependencies.py
# Uses tree-sitter to parse Java code, identify dependencies

import tree_sitter_java as tsjava
import networkx as nx
from pathlib import Path

def analyze_codebase(root_dir):
    parser = tsjava.Parser()
    graph = nx.DiGraph()
    
    for java_file in Path(root_dir).rglob("*.java"):
        # Parse file
        tree = parser.parse(java_file.read_bytes())
        
        # Extract class name
        class_name = extract_class_name(tree)
        
        # Extract dependencies (imports, method calls)
        deps = extract_dependencies(tree)
        
        for dep in deps:
            graph.add_edge(class_name, dep)
    
    return graph

# AI Prompt to Copilot:
# "Complete this function to identify circular dependencies 
# and tightly coupled clusters using PageRank algorithm"

def identify_clusters(graph):
    # Copilot generated this in 30 seconds
    pagerank = nx.pagerank(graph)
    communities = nx.community.greedy_modularity_communities(graph)
    
    clusters = []
    for community in communities:
        cluster_size = len(community)
        cluster_coupling = sum(pagerank[node] for node in community)
        clusters.append({
            'classes': list(community),
            'size': cluster_size,
            'coupling': cluster_coupling
        })
    
    return sorted(clusters, key=lambda x: x['coupling'], reverse=True)

Output: Dependency graph showing:

• 47 high-coupling clusters
• Top 3 clusters: Payment (42 classes), Order (38 classes), Catalog (156 classes)

Time Saved: Manual dependency mapping would take 2 weeks. AI-assisted scripts took 4 hours.

Task 2: Identify Database Dependencies

# Script: analyze_db_dependencies.py

# AI Prompt:
# "Analyze Java code for SQL queries and identify table dependencies.
# Look for JDBC calls, JPA annotations, and MyBatis mappers."

def extract_sql_queries(java_file):
    # Copilot generated regex patterns for:
    # - JDBC executeQuery patterns
    # - JPA @Query annotations
    # - MyBatis mapper XML
    pass

def build_table_dependency_graph(queries):
    # AI identified:
    # - Tables accessed by each module
    # - Foreign key relationships
    # - Transactional boundaries
    pass

Output:

• Payment module: Accesses 8 tables (payments, transactions, refunds, audit_log, ...)
• Order module: Accesses 12 tables (orders, order_items, shipments, ...)
• Shared tables: customers, products (accessed by both modules - potential issue)

Time Saved: Manual SQL analysis would take 1 week. AI scripts took 3 hours.

Day 2-3: AI-Assisted Domain Modeling

Tool: ChatGPT-4 with Claude (for code context)

Prompt Template:

Analyze this legacy Java codebase for domain boundaries.

Context:
- E-commerce platform, 280K LOC
- Key modules identified: Payment (42 classes), Order (38 classes), Catalog (156 classes)
- Payment module classes: [paste list of 42 class names]
- Order module classes: [paste list of 38 class names]

Database tables:
- Payment: [paste table list]
- Order: [paste table list]
- Shared: customers, products

Questions:
1. Can Payment be extracted as independent microservice?
2. Can Order be extracted as independent microservice?
3. What are the hard dependencies (transactional boundaries)?
4. What are the soft dependencies (can be made async)?
5. How should we handle shared tables (customers, products)?

Provide:
- Extraction feasibility (High/Medium/Low) with reasoning
- Required API contracts between services
- Data migration strategy
- Rollback approach

AI Response (Summarized):

Payment Extraction: High Feasibility

• Self-contained domain (payment processing, refunds, audit)
• Database dependencies: 8 tables, zero foreign keys to order tables
• Shared tables: customers (read-only), products (read-only for price validation)
• Strategy: Extract payment as service, replicate customer/product data as read-only cache

Order Extraction: Medium Feasibility

• Mostly self-contained, but tight coupling with payment (transactional)
• Database dependencies: 12 tables, foreign key to customers
• Issue: Order creation + payment authorization currently in same transaction
• Strategy: Extract order as service, use saga pattern for order+payment transaction

Recommended Extraction Order:

1. Payment first (simpler, high value)
2. Order second (depends on payment API)

Shared Data Strategy:

• customers table: Denormalize read-only copy to each service
• products table: Create product service (future), for now denormalize

AI Also Identified:

• PaymentGateway class is a God object (handles 7 different payment providers) - should be refactored before extraction
• OrderService has 23 methods, 12 are payment-related - clean boundary for splitting

Time Saved: Domain analysis normally takes senior architect 1 week. AI analysis took 4 hours (including validation).

Day 4: Test Coverage Analysis

Before extracting code, we need tests. But 280K LOC with zero tests? Where do we start?

AI Prompt:

I need to add tests to legacy Java code before extracting it as a microservice.

Code: [paste PaymentService.java - 800 lines]

Generate:
1. List of methods by risk (critical business logic vs. utility)
2. Test cases for top 10 highest-risk methods
3. Integration test scenarios for payment flows
4. Mock strategy for external dependencies (payment gateways)

Prioritize by: business impact × code complexity

AI Response:

Generated prioritized list of 42 methods in PaymentService:

• 8 critical (process payment, refund, verify transaction)
• 12 high-risk (tax calculation, fraud detection)
• 22 low-risk (utilities, getters/setters)

Generated test templates for all 8 critical methods:

// AI-generated test (with 90% accuracy)
@Test
public void processPayment_ValidCard_ReturnsSuccess() {
    // Arrange
    PaymentRequest request = new PaymentRequest();
    request.setAmount(new BigDecimal("99.99"));
    request.setCardNumber("4111111111111111"); // Visa test card
    request.setExpiryDate("12/25");
    
    PaymentGateway mockGateway = mock(PaymentGateway.class);
    when(mockGateway.authorize(any())).thenReturn(
        new AuthResponse("AUTH123", TransactionStatus.APPROVED)
    );
    
    PaymentService service = new PaymentService(mockGateway);
    
    // Act
    PaymentResult result = service.processPayment(request);
    
    // Assert
    assertEquals(TransactionStatus.APPROVED, result.getStatus());
    assertNotNull(result.getTransactionId());
    verify(mockGateway).authorize(argThat(auth -> 
        auth.getAmount().equals(new BigDecimal("99.99"))
    ));
}

Outcome: AI generated 47 test cases. We reviewed and fixed 8 (incorrect assertions, wrong mock setup). 39 were production-ready.

Time Saved: Writing 47 tests manually would take 2 weeks. AI generated them in 2 hours. We spent 1 day reviewing and fixing.

Day 5: Architecture Decision Record

Document the modernization plan. AI accelerates this too.

Prompt:

Create an Architecture Decision Record for extracting Payment service from Java monolith.

Context:
- Current: Monolith with 280K LOC
- Extract: Payment processing (42 classes, 8 tables)
- Team: 6 engineers, limited microservices experience
- Timeline: 6 weeks

ADR Template:
1. Context and Problem Statement
2. Decision Drivers
3. Considered Options
4. Decision Outcome
5. Consequences (Positive/Negative/Risks)
6. Implementation Plan

Use data from previous analysis.

AI Response: Generated complete ADR in 3 minutes. We refined for 30 minutes. Output: Professional ADR document that would normally take 4 hours.

Week 1 Outcome:

• ✅ Dependency graph (47 clusters identified)
• ✅ Database dependencies (8 tables for payment, 12 for order)
• ✅ Domain model (clear boundaries validated)
• ✅ Test strategy (47 tests generated and reviewed)
• ✅ Architecture Decision Record (documented)

Time Spent: 5 days with AI vs. 4-6 weeks traditional analysis.

Week 2: Test Coverage and Refactoring Prep

Objective: Add tests and refactor God objects before extraction.

Day 1-2: AI-Powered Test Generation

We identified 42 classes in the Payment module. Need tests for all of them.

Approach: Generate tests in batches using AI.

Batch 1: Core Business Logic (8 classes)

Used Copilot to generate tests inline:

1. Open PaymentService.java
2. Copilot suggests test class
3. Review and accept (fixed 2 test assertions)
4. Repeat for 8 classes

Time per class: 15 minutes (would be 2 hours manually)

Batch 2: Utilities and Helpers (20 classes)

Used ChatGPT for batch generation:

1. Paste class code
2. Prompt: "Generate JUnit 5 tests for all public methods"
3. Review output
4. Copy to test file

Time per class: 8 minutes (would be 45 minutes manually)

Batch 3: Integration Tests (4 end-to-end flows)

AI struggled here. We wrote these manually.

Time: 1 day (same as without AI)

Week 2 Day 1-2 Outcome:

• ✅ 312 unit tests generated (AI)
• ✅ 4 integration tests written (manual)
• ✅ Code coverage: 0% → 67%

Day 3-4: Refactoring God Objects

PaymentGateway class was 1,200 lines handling 7 payment providers. Need to refactor before extraction.

AI Prompt:

Refactor this Java class using Strategy pattern:

[Paste PaymentGateway.java - 1,200 lines]

Current structure:
- Single class with if/else for 7 payment providers
- Methods: processStripe, processPayPal, processBraintree, etc.

Desired structure:
- PaymentGateway interface
- Separate implementation for each provider
- Factory to select provider

Generate:
1. PaymentGateway interface
2. StripePaymentGateway implementation
3. PaymentGatewayFactory
4. Refactoring steps (how to migrate without breaking production)

AI Response:

Generated complete refactoring:

// Generated interface
public interface PaymentGateway {
    AuthorizationResult authorize(PaymentRequest request);
    CaptureResult capture(String authorizationId);
    RefundResult refund(String transactionId, BigDecimal amount);
}

// Generated Stripe implementation
public class StripePaymentGateway implements PaymentGateway {
    private final StripeClient client;
    
    @Override
    public AuthorizationResult authorize(PaymentRequest request) {
        // AI generated this by extracting the Stripe-specific
        // logic from the monolithic class
        try {
            Map<String, Object> params = new HashMap<>();
            params.put("amount", request.getAmount().multiply(new BigDecimal("100")).intValue());
            params.put("currency", request.getCurrency().toLowerCase());
            params.put("source", request.getCardToken());
            
            Charge charge = client.charges().create(params);
            
            return new AuthorizationResult(
                charge.getId(),
                TransactionStatus.APPROVED,
                charge.getCreated()
            );
        } catch (StripeException e) {
            return new AuthorizationResult(
                null,
                TransactionStatus.DECLINED,
                e.getMessage()
            );
        }
    }
    
    // ... other methods
}

// Generated factory
public class PaymentGatewayFactory {
    public PaymentGateway createGateway(PaymentProvider provider) {
        switch (provider) {
            case STRIPE: return new StripePaymentGateway(stripeConfig);
            case PAYPAL: return new PayPalPaymentGateway(payPalConfig);
            // ... other providers
            default: throw new IllegalArgumentException("Unknown provider");
        }
    }
}

Migration Steps AI Suggested:

1. Create interface and implementations (no production impact)
2. Add adapter that delegates old class → new implementations
3. Deploy adapter (validate in production with feature flag)
4. Switch 10% of traffic to new implementations
5. Gradually increase to 100%
6. Remove old class

Outcome:

• Refactoring completed in 2 days (would take 1 week manually)
• All tests passing
• Code reduced from 1,200 lines → 7 classes of ~150 lines each
• Deployed to production with feature flag (validated with 10% traffic)

Day 5: Database Migration Planning

Need to separate payment tables from monolith database.

AI Prompt:

Plan database migration for extracting payment tables:

Current State:
- Single Oracle database with 87 tables
- Payment tables: payments, transactions, refunds, payment_audit, card_tokens, payment_methods, fraud_checks, gateway_logs
- Foreign keys: payments.customer_id → customers.id

Target State:
- Separate PostgreSQL database for payment service
- Replicate customer data (read-only)

Constraints:
- Zero downtime
- Zero data loss
- Rollback capability at each step

Generate:
1. Step-by-step migration plan
2. Data replication strategy
3. Cutover approach
4. Rollback procedures

AI Response:

Phase 1: Dual Write

1. Create payment schema in new PostgreSQL database
2. Add payment service database connection
3. Write to both databases (Oracle + PostgreSQL)
4. Validate data consistency

Phase 2: Validation

1. Run validation queries (compare row counts, checksums)
2. Monitor for 1 week
3. Fix any inconsistencies

Phase 3: Dual Read (Cutover)

1. Read from PostgreSQL, fallback to Oracle on errors
2. Monitor error rates
3. Gradually increase traffic to PostgreSQL

Phase 4: Cleanup

1. Stop writing to Oracle
2. Drop payment tables from Oracle (after 30-day safety period)

Rollback at Each Phase:

• Phase 1: Stop dual write, continue Oracle-only
• Phase 2: No action needed (validation only)
• Phase 3: Switch reads back to Oracle
• Phase 4: Restore Oracle tables from backups

Time Saved: Database migration planning normally takes 2-3 days. AI plan took 2 hours. We spent half a day validating and refining.

Week 2 Outcome:

• ✅ Test coverage: 0% → 67%
• ✅ PaymentGateway refactored (Strategy pattern)
• ✅ Database migration plan documented
• ✅ Feature flags implemented for gradual rollout

Week 3: Service Extraction

Objective: Extract payment code as standalone microservice.

Day 1: Project Setup with AI

AI Prompt:

Generate Spring Boot microservice project structure for Payment Service:

Requirements:
- Spring Boot 3.x
- PostgreSQL database
- REST API
- Docker containerization
- Kubernetes deployment
- Observability (Prometheus, Grafana)

Generate:
1. pom.xml with dependencies
2. application.yml with configuration
3. Project structure (packages)
4. Dockerfile
5. Kubernetes manifests (deployment, service, configmap)

AI Response:

Generated complete project structure in 5 minutes:

payment-service/
├── pom.xml
├── Dockerfile
├── k8s/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── configmap.yaml
│   └── secret.yaml (template)
└── src/
    └── main/
        ├── java/
        │   └── com/company/payment/
        │       ├── PaymentServiceApplication.java
        │       ├── config/
        │       ├── controller/
        │       ├── service/
        │       ├── repository/
        │       └── domain/
        └── resources/
            └── application.yml

All files generated with proper structure. Minor tweaks needed (database credentials, K8s namespace).

Time Saved: Project setup normally takes 4-6 hours. AI did it in 30 minutes.

Day 2-3: Code Migration

Strategy: Copy payment classes from monolith to microservice.

AI Assistance:

For each class copied:

1. AI identifies monolith dependencies (e.g., customer service, logging utilities)
2. AI suggests how to replace them (REST calls, new logging)
3. AI generates interface adapters

Example:

Payment service calls CustomerService.getCustomer() in monolith. Need to replace with REST call.

AI Prompt:

This code calls CustomerService from the monolith:

Customer customer = customerService.getCustomer(customerId);

Replace with REST call to customer-service API.
Generate:
1. CustomerClient interface
2. RestTemplate implementation
3. Fallback/retry logic
4. Error handling

AI Generated:

@Component
public class CustomerClient {
    private final RestTemplate restTemplate;
    private final String customerServiceUrl;
    
    public CustomerClient(
        RestTemplate restTemplate,
        @Value("${services.customer.url}") String customerServiceUrl
    ) {
        this.restTemplate = restTemplate;
        this.customerServiceUrl = customerServiceUrl;
    }
    
    public Optional<Customer> getCustomer(String customerId) {
        try {
            ResponseEntity<Customer> response = restTemplate.getForEntity(
                customerServiceUrl + "/customers/" + customerId,
                Customer.class
            );
            return Optional.ofNullable(response.getBody());
        } catch (HttpClientErrorException.NotFound e) {
            return Optional.empty();
        } catch (Exception e) {
            // Log error, could add circuit breaker here
            throw new CustomerServiceException("Failed to fetch customer", e);
        }
    }
}

Repeated this pattern for 12 external dependencies. AI generated adapters in 2 hours (would take 1 day manually).

Day 2-3 Outcome:

• ✅ 42 payment classes migrated
• ✅ 12 external dependencies adapted
• ✅ All tests passing in new service

Day 4: API Design

Need REST API for payment operations.

AI Prompt:

Design REST API for payment service based on existing Java methods:

Existing methods:
- processPayment(PaymentRequest) → PaymentResult
- refundPayment(String transactionId, BigDecimal amount) → RefundResult
- getPaymentStatus(String transactionId) → PaymentStatus
- listPayments(String customerId, Date from, Date to) → List<Payment>

Requirements:
- RESTful design
- Proper HTTP methods and status codes
- Error responses (4xx, 5xx)
- Pagination for list endpoints
- OpenAPI/Swagger documentation

Generate:
1. API endpoints (paths, methods)
2. Request/response DTOs
3. OpenAPI spec
4. Spring controller skeleton

AI Response:

Generated complete API design:

# OpenAPI spec (generated by AI)
openapi: 3.0.0
info:
  title: Payment Service API
  version: 1.0.0

paths:
  /api/v1/payments:
    post:
      summary: Process a payment
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/PaymentRequest'
      responses:
        '201':
          description: Payment processed
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/PaymentResult'
        '400':
          description: Invalid request
        '422':
          description: Payment declined
    get:
      summary: List payments
      parameters:
        - name: customerId
          in: query
          required: true
          schema:
            type: string
        - name: from
          in: query
          schema:
            type: string
            format: date
        - name: to
          in: query
          schema:
            type: string
            format: date
        - name: page
          in: query
          schema:
            type: integer
            default: 0
        - name: size
          in: query
          schema:
            type: integer
            default: 20
      responses:
        '200':
          description: List of payments
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/PaymentList'

  /api/v1/payments/{transactionId}:
    get:
      summary: Get payment status
      parameters:
        - name: transactionId
          in: path
          required: true
          schema:
            type: string
      responses:
        '200':
          description: Payment status
        '404':
          description: Payment not found

  /api/v1/payments/{transactionId}/refunds:
    post:
      summary: Refund a payment
      parameters:
        - name: transactionId
          in: path
          required: true
          schema:
            type: string
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/RefundRequest'
      responses:
        '201':
          description: Refund processed
        '404':
          description: Payment not found
        '422':
          description: Refund failed

components:
  schemas:
    PaymentRequest:
      type: object
      required:
        - amount
        - currency
        - customerId
        - paymentMethodId
      properties:
        amount:
          type: number
          format: decimal
        currency:
          type: string
          example: USD
        customerId:
          type: string
        paymentMethodId:
          type: string
        metadata:
          type: object
    
    PaymentResult:
      type: object
      properties:
        transactionId:
          type: string
        status:
          type: string
          enum: [APPROVED, DECLINED, PENDING]
        message:
          type: string
        createdAt:
          type: string
          format: date-time
    
    # ... other schemas

Also generated Spring controllers implementing this spec. 95% production-ready.

Time Saved: API design and documentation normally takes 1-2 days. AI did it in 1 hour.

Day 5: Integration Testing

Test the extracted service integrated with monolith.

Setup:

• Payment service running on port 8081
• Monolith calling payment service REST API
• Feature flag: 10% of traffic to new service

AI Assistance: Generated integration test scenarios.

Prompt:

Generate integration test scenarios for payment service:

Architecture:
- Monolith calls payment-service REST API
- Payment-service uses PostgreSQL
- Both access shared customer data (replicated)

Test scenarios needed:
- Happy path (successful payment)
- Declined payment
- Service unavailable (payment-service down)
- Database unavailable
- Timeout scenarios
- Data consistency (monolith DB vs. payment-service DB)

AI Response:

Generated 12 integration test scenarios with step-by-step test cases. We implemented them using RestAssured and Testcontainers.

Week 3 Outcome:

• ✅ Payment service deployed to staging
• ✅ Integration tests passing
• ✅ Feature flag: 10% production traffic
• ✅ Monitoring dashboards created

Week 4: Database Migration

Objective: Migrate payment data to separate database.

Day 1-2: Dual Write Implementation

Implement dual-write pattern: Write to both Oracle (monolith) and PostgreSQL (payment-service).

AI Prompt:

Implement dual-write pattern in Java:

Current code:
paymentRepository.save(payment); // Saves to Oracle

New behavior:
- Save to Oracle (existing)
- Also save to PostgreSQL (new)
- If PostgreSQL fails, log error but don't block transaction
- Retry failed writes asynchronously

Generate:
1. DualWritePaymentRepository
2. Async retry mechanism
3. Monitoring/alerting for failures

AI Generated:

@Repository
public class DualWritePaymentRepository {
    private final OraclePaymentRepository oracleRepo;
    private final PostgresPaymentRepository postgresRepo;
    private final AsyncRetryService retryService;
    private final MetricsRegistry metrics;
    
    public Payment save(Payment payment) {
        // Primary write (Oracle) - must succeed
        Payment saved = oracleRepo.save(payment);
        
        // Secondary write (Postgres) - best effort
        try {
            postgresRepo.save(saved);
            metrics.increment("payment.dual_write.success");
        } catch (Exception e) {
            metrics.increment("payment.dual_write.failure");
            logger.error("Postgres write failed, will retry async", e);
            
            // Schedule async retry
            retryService.scheduleRetry(() -> {
                postgresRepo.save(saved);
            }, 5, TimeUnit.SECONDS);
        }
        
        return saved;
    }
}

@Service
public class AsyncRetryService {
    private final ScheduledExecutorService executor;
    
    public void scheduleRetry(Runnable task, long delay, TimeUnit unit) {
        executor.schedule(() -> {
            try {
                task.run();
            } catch (Exception e) {
                // If retry fails, write to dead-letter queue
                deadLetterQueue.add(task);
            }
        }, delay, unit);
    }
}

Implementation:

• Deployed dual-write to production with feature flag
• Monitored for 48 hours
• Dual-write success rate: 99.7% (12 failures out of 4,000 transactions)
• All failures resolved by async retry

Day 3-4: Data Validation

Verify data consistency between Oracle and PostgreSQL.

AI Prompt:

Generate data validation queries for payment migration:

Source: Oracle database
Target: PostgreSQL database

Tables: payments, transactions, refunds

Validation needed:
1. Row count match
2. Checksum match for critical fields
3. Identify missing/extra rows
4. Identify data discrepancies

Generate SQL queries for both Oracle and PostgreSQL.

AI Generated:

-- Row count comparison
-- Oracle
SELECT 'payments' as table_name, COUNT(*) as count FROM payments
UNION ALL
SELECT 'transactions', COUNT(*) FROM transactions
UNION ALL
SELECT 'refunds', COUNT(*) FROM refunds;

-- PostgreSQL (same query)

-- Checksum comparison (critical fields)
-- Oracle
SELECT 
    transaction_id,
    STANDARD_HASH(
        amount || currency || status || customer_id,
        'MD5'
    ) as checksum
FROM payments
ORDER BY transaction_id;

-- PostgreSQL
SELECT 
    transaction_id,
    MD5(
        amount::text || currency || status || customer_id
    ) as checksum
FROM payments
ORDER BY transaction_id;

-- Compare results, identify mismatches

We ran these queries daily. Found 3 data discrepancies (timestamps rounded differently). Fixed and re-validated.

Day 5: Cutover Planning

Plan the final cutover to read from PostgreSQL.

Approach:

• Use feature flag to gradually shift read traffic
• Monitor error rates
• Rollback capability at any point

AI Prompt:

Generate cutover plan for database migration:

Current: Monolith reads from Oracle
Target: Payment-service reads from PostgreSQL
Status: Dual-write active for 5 days, data validated

Plan:
- Gradual traffic shift (10% → 50% → 100%)
- Monitoring at each stage
- Rollback procedures
- Success criteria for each stage

Generate detailed plan with timelines and checkpoints.

AI Response:

Stage 1: 10% Read Traffic (Day 1)

• Feature flag: 10% of reads from PostgreSQL
• Monitor: Error rate, latency, data mismatches
• Success criteria: Error rate < 0.1%, latency delta < 50ms
• Rollback: Set feature flag to 0%

Stage 2: 50% Read Traffic (Day 3)

• Feature flag: 50% of reads from PostgreSQL
• Monitor: Same as Stage 1
• Success criteria: Same as Stage 1, for 24 hours
• Rollback: Set feature flag to 10%

Stage 3: 100% Read Traffic (Day 5)

• Feature flag: 100% of reads from PostgreSQL
• Monitor: Same as Stage 1
• Success criteria: Same as Stage 1, for 48 hours
• Rollback: Set feature flag to 50%

Stage 4: Stop Dual Write (Day 8)

• Stop writing to Oracle
• PostgreSQL is now source of truth
• Keep Oracle data for 30 days (safety)

Week 4 Outcome:

• ✅ Dual-write active and validated
• ✅ Data consistency: 99.99%
• ✅ Read traffic: 10% from PostgreSQL
• ✅ Zero errors, ready for 50% next week

Week 5: Gradual Rollout

Objective: Shift 100% of payment traffic to new service.

Day 1-2: 50% Traffic

• Increased feature flag from 10% → 50%
• Monitored for 48 hours
• Metrics: Error rate 0.02%, latency improved by 15ms (PostgreSQL faster than Oracle)

Day 3-4: 100% Traffic

• Increased feature flag to 100%
• All payment reads from PostgreSQL
• All payment writes to PostgreSQL (and still dual-writing to Oracle)
• Monitored for 48 hours: Zero issues

Day 5: Stop Dual Write

• Disabled writes to Oracle
• PostgreSQL is now single source of truth
• Oracle payment tables marked read-only (safety)

Week 5 Outcome:

• ✅ 100% traffic on payment-service
• ✅ Zero downtime
• ✅ Zero data loss
• ✅ Latency improved 15%

Week 6: Optimization and Documentation

Objective: Optimize performance, document architecture, train team.

Day 1-2: Performance Optimization

AI Prompt:

Analyze this payment service for performance optimization opportunities:

Current metrics:
- P50 latency: 45ms
- P95 latency: 120ms
- P99 latency: 280ms
- Throughput: 150 req/sec

[Paste relevant code for payment processing]

Identify:
1. N+1 query problems
2. Missing indexes
3. Unnecessary computations
4. Caching opportunities
5. Async opportunities

Provide specific code changes with expected impact.

AI Response:

Identified 5 optimization opportunities:

1. N+1 queries in listPayments (loading customer for each payment)
2. Missing index on payments.customer_id
3. Fraud check called synchronously (can be async)
4. Customer data fetched every request (can be cached)
5. Payment gateway client creates new HTTP connection per request (connection pooling)

We implemented all 5. New metrics:

• P50: 45ms → 22ms (51% improvement)
• P95: 120ms → 65ms (46% improvement)
• P99: 280ms → 150ms (46% improvement)
• Throughput: 150 → 280 req/sec (87% improvement)

Time Saved: Performance analysis normally takes 2-3 days. AI did it in 1 hour. Implementation took 1 day.

Day 3: Documentation

AI Prompt:

Generate architecture documentation for payment service extraction:

Include:
1. Architecture overview
2. Service boundaries
3. API documentation
4. Database schema
5. Deployment architecture
6. Monitoring and alerting
7. Rollback procedures
8. Known limitations

Use C4 model (Context, Container, Component, Code).

AI Response:

Generated 20-page documentation in Markdown. We reviewed and added team-specific details. Total time: 2 hours (would take 2 days manually).

Day 4-5: Team Training

Trained team on:

• Microservices patterns used
• Payment service architecture
• How to add new payment providers
• Monitoring and debugging
• Incident response

AI Assistance:

Generated training materials and exercises:

• Workshop slides
• Hands-on exercises
• Quiz questions
• Reference architecture diagrams

Week 6 Outcome:

• ✅ Performance optimized (2x throughput)
• ✅ Documentation complete
• ✅ Team trained
• ✅ Production-ready

Final Results

Timeline: 6 weeks (as planned)

Metrics:

Before:

• Deployment frequency: Monthly
• Lead time for changes: 3-4 months
• Payment processing latency: P95 180ms
• Payment service uptime: 99.2% (tied to monolith)
• Time to add new payment provider: 6 weeks

After:

• Deployment frequency: 2x/week (payment service)
• Lead time for changes: 2-3 weeks
• Payment processing latency: P95 65ms (64% improvement)
• Payment service uptime: 99.8% (independent deployment)
• Time to add new payment provider: 1 week

Business Impact:

• Payment processing 64% faster
• Can deploy payment features independently
• Reduced coupling (8 fewer monolith deployments/year)
• Faster feature development

Effort:

• 6 engineers × 6 weeks = 36 engineer-weeks
• Traditional approach estimate: 18-24 months = 108-156 engineer-weeks
• Time saved: 72-120 engineer-weeks (67-77% reduction)

The Framework Summarized

Week 1: Understanding and Mapping

• AI: Dependency analysis, domain modeling, test strategy
• Output: Clear extraction boundaries, test plan, ADR

Week 2: Test Coverage and Refactoring

• AI: Test generation, refactoring patterns, migration planning
• Output: 67% test coverage, refactored God objects, migration plan

Week 3: Service Extraction

• AI: Project setup, code adaptation, API design
• Output: Working microservice, 10% production traffic

Week 4: Database Migration

• AI: Dual-write implementation, validation queries, cutover plan
• Output: Separate database, validated data consistency

Week 5: Gradual Rollout

• Manual: Gradual traffic shift, monitoring
• Output: 100% traffic on new service, zero downtime

Week 6: Optimization and Documentation

• AI: Performance analysis, documentation generation, training materials
• Output: Optimized service, complete documentation, trained team

Key Success Factors

1. AI Accelerates Analysis, Not Decisions

• AI analyzes dependencies in hours (not weeks)
• But humans decide what to extract and when

2. Incremental Extraction

• Extract one service at a time
• Validate at each step
• Rollback capability always available

3. Feature Flags Everywhere

• Gradual rollout (10% → 50% → 100%)
• Immediate rollback
• A/B testing capabilities

4. Test Coverage Before Extraction

• 67% coverage minimum
• Focus on business-critical paths
• AI generates, humans review

5. Dual-Write for Data Migration

• Zero downtime
• Zero data loss
• Validation at every step

When This Framework Works

✅ Good Fit:

• Monoliths with identifiable domain boundaries
• Teams with 4+ engineers
• Business tolerance for 6-week timeline
• Access to AI coding tools (Copilot, ChatGPT, Claude)

❌ Poor Fit:

• Codebases < 50K LOC (not worth extracting)
• No clear domain boundaries (need architecture work first)
• Teams < 3 engineers (too small for parallel work)
• Business can't wait 6 weeks (use strangler pattern more gradually)

The Bottom Line

Legacy code modernization doesn't require 18-month rewrites. With AI acceleration and the right framework, you can extract microservices in 6 weeks.

The key is using AI strategically at each phase:

• Week 1: Understanding (dependency analysis, domain modeling)
• Week 2: Preparation (test generation, refactoring)
• Week 3: Extraction (project setup, code migration, API design)
• Week 4: Data migration (dual-write, validation, cutover)
• Week 5: Rollout (gradual traffic shift)
• Week 6: Optimization (performance, documentation, training)

This isn't about AI magically modernizing your code. It's about using AI to accelerate the time-consuming parts (analysis, test generation, boilerplate) so you can focus on the decision-making (what to extract, how to structure it, when to cut over).

Start with one service extraction next quarter. Follow this framework. Track time savings. You'll never go back to traditional modernization approaches.