Modernizing a legacy insurance core.

The legacy reality in insurance

In an insurance core, the product is largely a rules engine: rating tables, underwriting criteria, rounding conventions, jurisdictional variations, commission schedules, and endorsement calculations.

Over many years, those rules accumulate across procedures, triggers, views, and batch chains. The precise scale varies by organization, but the operating pattern is familiar: business logic is distributed and poorly documented, batch sequencing is tightly coupled, integration occurs through shared tables, and regression confidence depends on people rather than repeatable tests.

The work is not to migrate the database. It is to migrate the business decisions the database has been making on the insurer’s behalf.

Target-state architecture

The target state separates channels, orchestration, business services, rules, events, and data. Services own workflow and data access; a rules layer owns pricing, underwriting, and eligibility decisions that change frequently or require business approval. The legacy core remains available during transition, but its responsibility shrinks domain by domain.

From stored procedure to business service

The central modernization task is to separate workflow from decision logic. Services should retain orchestration and data access. Rules that change frequently or require actuarial or underwriting approval should become named, versioned decision graphs with explicit inputs, outputs, tests, and ownership.

CREATE PROCEDURE sp_calc_premium
  @policy_id INT
AS
BEGIN
  SELECT @state = state_cd,
         @driver_age = drv_age
  FROM policy_master
  WHERE policy_id = @policy_id

  SELECT @base_rate = rate_amt
  FROM rate_table
  WHERE state_cd = @state

  IF @driver_age < 25
    SET @surcharge = @base_rate * 0.35
  ELSE IF @driver_age > 70
    SET @surcharge = @base_rate * 0.15

  UPDATE policy_master
  SET premium_amt = @base_rate + @surcharge
  WHERE policy_id = @policy_id
END

@Service
class PremiumRatingService {
  private final RateTableRepository rates;
  private final ZenEngine rules;

  PremiumQuote calculate(PolicyContext ctx) {
    var base = rates.findLiabilityRate(ctx.state());
    var input = Map.of(
        "driverAge", ctx.driverAge(),
        "baseRate", base,
        "state", ctx.state());

    var result = rules.evaluate(
        surchargeDecisionId, input);

    return PremiumQuote.from(
        ctx.policyId(), base, result);
  }
}

The Java example illustrates the boundary: a configuration-driven decision identifier, an engine call, and a typed result. Exact SDK signatures should be confirmed against the version selected for implementation.

Decision location and environment are configuration

rules:
  engine:
    mode: agent
    agent-url: https://rules-agent.internal.example
    project: auto-policy-rating
    environment: ${DEPLOY_ENV:PROD}
  premium-surcharge:
    decision: auto/liability/age-surcharge
    version: latest-published

The age brackets and surcharge percentages are authored and tested as a decision table. GoRules stores the published model as JDM JSON; business users work through the management interface rather than editing this representation directly.

Conceptual decision table output

{
  "rules": [
    { "driverAge": "< 25",   "surcharge": "baseRate * 0.35" },
    { "driverAge": "> 70",   "surcharge": "baseRate * 0.15" },
    { "driverAge": "[25..70]", "surcharge": "0" }
  ]
}

Migration strategy: strangler pattern and CDC

A big-bang rewrite concentrates technical, operational, and regulatory risk into one cutover. A safer approach moves one bounded capability at a time, compares its output against the legacy path, and retires the old responsibility only after agreed evidence is met.

The five phases

Risks and controls

Governance: preserve the reason

The migration is difficult because years of decisions were embedded in code without durable context. Rebuilding the rules in a modern language without recording their purpose only recreates the same risk. Each extracted rule should be paired with a concise decision record: what it does, why it exists, who owns it, the source of authority, and the condition under which it should be reviewed.

What good looks like

Where to start

• Inventory procedures and triggers; produce a dependency graph and business-criticality ranking.
• Select one high-value domain with a contained blast radius.
• Define the event, CDC, reconciliation, and rollback patterns before moving live traffic.
• Establish the GoRules management workflow and connect Zen Engine using configuration-driven decision identifiers and environments.
• Build tests from real historical inputs and outputs of the legacy procedure.
• Run in shadow mode and investigate every material variance.
• Pair legacy specialists with engineers and capture rule intent in decision records.
• Track the remaining legacy surface as a program-level measure after every release.