Gravity Migration

09 · Cutover

Move in slices you can take back.

A single big weekend bets everything on one rehearsal. A slice is small enough to reverse, a bank or a capability at a time, with one writer for each piece of data and a way back that someone has actually tried.

Slices move one at a time from the estate on the left to Gravity Standard on the right: late follow-up, funding notices, remittance intake, then payment correction. The ledger stays on the left and is reached by a hand-off. ANCHOR CORE GRAVITY STANDARD LATE FOLLOW-UPFUNDING NOTICESREMITTANCE INTAKEPAYMENT CORRECTION THE LEDGER STAYS: EACH POSTING IS A DOCUMENTED PROCESS

Slices · at Tidewater

The riskiest bank goes last.

Late follow-up starts with Harborside, the typical bank. Pinecrest follows, since it's small but quirky. Granite Valley goes last because it's the most cautious and it carries the fee waiver. Bank-by-bank works because tenants already vary by configuration.

#SliceWriter after cutoverWay back
1Late follow-up, HarborsidePayments writes Scheduled Payment statusRe-enable ACLP210 for that bank; reconcile fees sent since
2Late follow-up, Pinecrest, then Granite ValleySameSame
3Funding noticesPayments writes Funding NoticeRe-point the queue; replay from the outbox
4Remittance intakePayments writes Payment; posts to Anchor CoreConnect:Direct route retained for one cycle
5Payment correctionPayments; Anchor Core posts the resultTWPY stays read-only, re-enabled if needed
6Payoff quotesLendingBankLink route retained for one cycle
7KeelTrack replacementThe productKeel Street's IBM i kept read-only
8Monthly statementsPayments writes statements; Anchor Core supplies balancesTWSTMT kept ready for one cycle

The permit ladder · at Tidewater

Real data first. Real effects later.

Migrations add a rung. The shadow environment lets Payments hold real data while it can't affect anyone, and the pipeline refuses production until a new permit lists it. That new permit needs the parallel-run results, which is how proof reaches the go-live decision.

RungPermitDataReal effects
devBuildConstructedNone
testTestConstructed or irreversibly maskedNone
shadowProduction, naming only shadow (PERMIT-080)Real, captured from Anchor CoreNone: no route to Anchor Core, banks or staff
productionNew permit adding production (PERMIT-079)RealReal, starting with Harborside

Payments is one application with six slices, so one permit covers them all. The first slice earns the new permit, and each later slice links its own results before its feature flag is enabled.

How the family fits together

Three sites, one cutover.

Gravity Scheduling

When

Each slice is a glide path, and each cutover date is a gravity point. A newly discovered rule arrives as a weight ticket. Scheduling keeps discovery from silently eating the date.

Gravity Standard permits

Whether

The permit is the gate. Say it for test, do it, prove it in shadow, then show the parallel-run results to add production. Each application holds its own permit, and the rehearsed rollback counts as evidence.

Gravity Migration

What

The slice plan says what moves, who writes what, and how to reverse it. Decided differences show that it's ready.

In-flight work · at Tidewater

A loaded record doesn't know it was halfway through something.

Conversion loads records silently, so 240,000 scheduled payments don't send anyone a notice. But a payment nine days into a 15-day grace period needs a follow-up already waiting, and loading the record will never start one.

So each slice names its in-flight work. At cutover, a small process starts Late Payment Follow-up for each expected payment, as of that moment.

Easy to miss

This failure is silent. Nothing errors and nothing alarms. The payment just never gets followed up, and you find out when a bank asks why. Check for it in the shadow rehearsal.

Afterward · at Tidewater

Switching it off is a project too.

Anchor Core keeps seven years of TW.PROD.LATEFEE generations on virtual tape. Cutting over the slice doesn't end that obligation, and the data's no use if nothing can read packed decimal and EBCDIC after the machine's gone.

So each archive gets a readable format and a named owner before anything is switched off. Plan decommissioning as its own gravity point, because the savings don't arrive until it's done.

Settled with the Standard

Writing this method raised nine questions for Gravity Standard, and all are now resolved there.

  • QUESTION-016: A hand-off is a documented process.
  • QUESTION-069: Records may move; ledgers stay out.
  • QUESTION-070: A schedule starts bulk work, and a process runs it.
  • QUESTION-071: Outside systems use named providers and a role in one tenant.
  • QUESTION-072: Conversion is a process that starts no work.
  • QUESTION-073: Whether a record keeps its past is a design decision.
  • QUESTION-074: No reporting solution is prescribed.
  • QUESTION-075: A parallel run holds a permit naming only shadow.
  • QUESTION-076: MIG, EV and DIFF are reserved.

Rules

MIG-034 to MIG-037, MIG-044

  1. MIG-034

    Each slice is the smallest piece that can be cut over and reversed on its own.

  2. MIG-035

    Each piece of data has exactly one writer at any moment, and the cutover plan names that writer.

  3. MIG-036

    Rollback is rehearsed, including what happens to data written after cutover.

  4. MIG-037

    The source is decommissioned only after its retention obligations are met and a read-only period has passed with no need to return.

  1. MIG-044

    Each slice names its in-flight work, and a process starts that work as of the moment the new system takes over.

cutover-slice.md
# Cutover slice — <name>

- **Glide path owner:** <one person>
- **Gravity point:** <cutover date> — YYYY-MM-DD
- **Capability and banks included:** <what's in, and what's explicitly out>

## Ready when
- [ ] Rule coverage is complete
- [ ] Parallel run covered a full business cycle: YYYY-MM-DD to YYYY-MM-DD (MIG-030)
- [ ] Every difference is decided; none unexplained (MIG-032)
- [ ] Parallel run happened in a shadow environment under a permit naming only `shadow` (MIG-038)
- [ ] Production permit, including `production`, is valid until YYYY-MM-DD (PERMIT-079)
- [ ] Each load rehearsed in `shadow` and reconciled by count and control total (MIG-013)
- [ ] Runbooks exercised, dashboards live, alarm routes tested

## One writer (MIG-035)
| Data | Writer before | Writer after | Switch moment |
|---|---|---|---|
| <record or dataset> | <system> | <application> | <event or time> |

## In-flight work (MIG-044)
| Work under way at the switch | Process that starts it | As of |
|---|---|---|
| <what's halfway through> | <process> | <the switch moment> |

## Feeds to keep alive
| Consumer | What it still needs | How it gets it | Ends when |
|---|---|---|---|
| <system> | <data> | <hand-off> | <condition> |

## Way back (MIG-036)
- **Trigger:** <what would make us reverse, and who decides>
- **Steps:** <in order>
- **Data written since cutover:** <how it returns to the source>
- **Rehearsed:** YYYY-MM-DD — by <who> — took <time>

## After
- **Source goes read-only:** YYYY-MM-DD
- **Retention obligations and archive owner:** <what and who> (MIG-037)
- **Decommission date:** YYYY-MM-DD