Guidewire Migration And UpgradeSAFE

Model-agnostic agent-skills platform with a harness-free canonical layer, verified adapters, and the ccpi package manager. Explore at tonsofskills.com.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: guidewire-migration-and-upgrade
description: Move a Guidewire deployment to a new platform or release without breaking running policies and claims — on-prem→cloud cutover (config reconciliation, data migration, parallel-run validation), in-place version upgrade (e.g., 202403→202503) with deprecated-API regression coverage, rehearsal-driven cutover with rollback path mid-flight, and broker/claimant communication so users hit the right system at the right time. Use when planning a cloud migration, executing a version upgrade, or rehearsing a cutover. Trigger with "guidewire migration", "guidewire upgrade", "guidewire cutover", "guidewire on-prem to cloud", "202503 upgrade".
allowed-tools: Read, Write, Edit, Bash(gradle:*), Bash(curl:*), Bash(jq:*), Bash(diff:*), Grep, Glob
version: 1.26.0
license: MIT
author: Jeremy Longshore <[email protected]>
compatibility: Designed for Claude Code
tags:
  - guidewire
  - migration
  - upgrade
  - cutover
  - cloud
  - rehearsal
---

# Guidewire Migration and Upgrade

## Overview

Move a Guidewire deployment without losing policies, claims, integrations, or trust. Two related but distinct workflows:

- **Migration**: on-prem InsuranceSuite → Guidewire Cloud (or one cloud tenant → another). Different infrastructure, different config-layer assumptions, different API surfaces.
- **Upgrade**: in-place version bump (e.g., release `202403` → `202503`). Same infrastructure, new code, new APIs, deprecated APIs to retire.

Both are heavy lifts that go badly if executed without rehearsal. Five production failures this skill prevents:

1. **Config reconciliation gaps** — on-prem carries 5 years of customizations; cloud tenant ships with newer base config; cutover deploys the on-prem config and breaks because base assumptions diverged.
2. **Deprecated-API blind spots** — version upgrade removes a Cloud API that an integration depended on; the integration starts returning 404 the moment the upgrade lands.
3. **No mid-flight rollback** — cutover starts at midnight, fails at 2am, decision is "abort or push through"; without a pre-defined abort path the team chooses badly.
4. **Data migration that loses optimistic-locking history** — claims migrate but `checksum` values do not; downstream integrations fail every PATCH for a week until checksums regenerate.
5. **Communication misalignment** — brokers told "use the new system Monday" while the old system is still authoritative for in-flight quotes; bound state lives in two systems.

## Prerequisites

- Approved migration / upgrade plan with named owners for: config reconciliation, data migration, integration cutover, communication, rollback authorization
- A staging tenant on the target platform (cloud) or target version that is exact-replica of production minus customer data
- Production-shape sample dataset for rehearsal (anonymized but representative volumes and shapes)
- Cutover window scheduled with documented blackout period for non-essential changes
- For upgrades: Guidewire's **release notes** for every version between current and target; **deprecated API list** for the target release

## Instructions

Build the migration / upgrade plan in this order. Each step targets one of the five production failures listed in Overview.

### 1. Inventory the current state

Before designing the move, know what is actually deployed:

| Surface | Catalog |
|---|---|
| Custom Gosu code | every file under `modules/configuration/gsrc/`; commit count, author distribution |
| Custom plugins | every entry in `plugin/registry/*.xml` |
| Custom entity extensions | every `.eti` file deviation from base |
| Outbound integrations | every Service Application registered in GCC; their roles and endpoints called |
| Inbound integrations | every messaging destination consuming App Events; their delivery destinations |
| Reports and queries | dashboards, scheduled batch jobs, ad-hoc Gosu Query API uses |
| Custom UI / PCF | every PCF file deviation from base |

The inventory drives reconciliation. Skipping it is how 30-month "migration" projects happen — surprise customizations surface every other week.

### 2. Reconcile against the target

For migrations: identify each customization's status against the cloud base config (still applicable / superseded by base / requires re-implementation / no longer needed). For upgrades: identify each customization's status against the target version's base config.

```
Custom file          Base file (target)         Status
gsrc/.../UWRule1.gs  same path, same hash       no-op (carrier kept it through upgrade)
gsrc/.../UWRule2.gs  same path, different hash  manual merge required
gsrc/.../UWRule3.gs  not present in target      cut by Guidewire; verify if rule still needed
                     gsrc/.../NewRule.gs        new in target; no carrier override needed
```

Use `diff -r` between current and target base config zones; the output is the merge backlog. Each row gets an owner and a target completion date.

### 3. Design the data migration plan

For migrations between deployments, every entity needs to move. The non-obvious challenges:

- **Foreign-key resolution**: `claim.Policy` is a reference to a Policy resource id; new tenant assigns new ids; mapping table required.
- **Checksum continuity**: Cloud API uses `checksum` for optimistic locking; migration must populate plausible checksums or downstream PATCH calls fail until they refresh through GET-then-PATCH.
- **Audit log retention**: regulatory requirement to retain claim-state history; the old system's audit log must migrate or be archived in a regulator-acceptable format.
- **Document attachments**: claim photos, declaration pages, evidence; can be GBs per claim; needs separate transfer plan.
- **In-flight resources**: submissions in `Quoted`, claims in `Open`; cutover plan must decide: complete in old, suspend through cutover, or recreate in new.

A typical large-tenant migration moves 100M+ entity rows; rehearsal at production scale

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.