Legacy Modernization

Anti-Corruption Layer: Wrap Legacy APIs

Before calling a legacy service or utility from new code, wrap it in a thin interface. This shields new code from legacy naming conventions, mutable data structures, and exception contracts.

// Legacy code you cannot change
public class LegacyInventoryManager {
    // Global state, throws checked Exception, returns null on miss
    public static InventoryRecord getInventory(String sku) throws Exception { ... }
    public static boolean reserveStock(String sku, int qty) throws Exception { ... }
}

// Anti-corruption layer: clean interface + adapter
public interface InventoryService {
    Optional<InventoryRecord> findBySku(Sku sku);
    boolean reserveStock(Sku sku, int quantity);
}

@Service
public class LegacyInventoryAdapter implements InventoryService {

    @Override
    public Optional<InventoryRecord> findBySku(Sku sku) {
        try {
            return Optional.ofNullable(LegacyInventoryManager.getInventory(sku.value()));
        } catch (Exception e) {
            throw new InventoryLookupException("Failed to look up SKU: " + sku.value(), e);
        }
    }

    @Override
    public boolean reserveStock(Sku sku, int quantity) {
        try {
            return LegacyInventoryManager.reserveStock(sku.value(), quantity);
        } catch (Exception e) {
            throw new InventoryReservationException("Failed to reserve stock for: " + sku.value(), e);
        }
    }
}

// New code only sees InventoryService — no legacy types cross the boundary
@Service
public class OrderService {
    private final InventoryService inventoryService;  // not LegacyInventoryManager
}

Find Seams Before Making Changes

A seam is a place in the code where behavior can be changed without modifying the code at that point. Identify seams before touching legacy code.

Common seams in Java legacy codebases:

• Interface implementations you can swap out
• Constructors that accept dependencies (even if those were originally hardcoded with new)
• Static method calls that can be wrapped in instance methods
• Database calls behind a DAO class

// Legacy code with no seam (hardcoded dependency)
public class OrderProcessor {
    public void process(Order order) {
        // Hardcoded: no way to substitute without modifying this class
        EmailSender sender = new SmtpEmailSender("smtp.company.com", 25);
        sender.send(order.getEmail(), "Your order has been processed");
    }
}

// Introducing a seam: extract interface, inject dependency
public interface NotificationSender {
    void sendOrderConfirmation(String email, OrderId orderId);
}

public class OrderProcessor {
    private final NotificationSender notificationSender;

    public OrderProcessor(NotificationSender notificationSender) {
        this.notificationSender = notificationSender;  // seam: can substitute in tests and migration
    }

    public void process(Order order) {
        notificationSender.sendOrderConfirmation(order.getEmail(), order.getId());
    }
}

Test First, Then Migrate

Do not migrate untested legacy code. If the existing behavior isn't captured in tests, you have no way to verify your migration preserves it.

Migration sequence for a legacy Struts Action:

1. Write characterization tests against the existing behavior (what does it actually do?)
2. Extract the business logic from the Action into a plain Java class
3. Test the extracted class in isolation
4. Wire the extracted class into a new Spring @Service
5. Route new traffic to the new service; legacy action continues to serve existing traffic
6. Monitor for behavioral differences
7. Remove the legacy action when confidence is high

// Step 1: Characterization test — captures existing behavior as-is
@Test
void legacyCreateOrderAction_producesExpectedSessionAttributes() {
    var action = new CreateOrderAction();
    var form = new OrderForm();
    form.setCustomerId("cust-1");
    form.setItemSku("SKU-001");
    form.setQuantity(2);

    ActionForward forward = action.execute(mapping, form, request, response);

    assertThat(request.getSession().getAttribute("orderConfirmation")).isNotNull();
    assertThat(forward.getName()).isEqualTo("success");
}

Migration Priority Order

When deciding what to modernize first, use this sequence:

1. High-churn code first. Code that changes often in Struts is painful to maintain; migrate it first for the largest ongoing benefit.
2. Extract service interfaces before rewriting. Any Struts Action with more than ~50 lines of logic likely has extractable business logic.
3. Route new features through Spring. Never add new behavior to a Struts Action — create a Spring service and wire the new feature there.
4. Leave stable, tested legacy code alone. Working code with passing tests costs nothing to leave in place. The risk of touching it exceeds the benefit.

// High-value migration target: Struts Action with business logic
public class ProcessPaymentAction extends Action {
    public ActionForward execute(...) {
        // 200 lines of payment logic mixed with HTTP concerns
        String cardNumber = request.getParameter("cardNumber");
        // validation, charge, receipt generation all tangled together
    }
}

// Extract the business logic, leave the routing alone until ready
@Service
public class PaymentService {
    public PaymentReceipt processPayment(PaymentRequest request) {
        // Clean implementation, testable, no HTTP
    }
}

// Phase 1: the old Action delegates to the new service
public class ProcessPaymentAction extends Action {
    private final PaymentService paymentService = SpringContext.getBean(PaymentService.class);

    public ActionForward execute(...) {
        PaymentRequest req = PaymentRequest.from(request);  // extract params
        PaymentReceipt receipt = paymentService.processPayment(req);
        request.setAttribute("receipt", receipt);
        return mapping.findForward("success");
    }
}

Never Break Working Legacy Code

If a legacy code path works and has users, do not break it. Parallel paths exist for a reason. If you must change behavior, add a feature flag or route new traffic to a new endpoint.

Prefer adding a new path over changing an existing one. Removing the old path comes last, after the new path has operated in production under load.