Enrollment & Claims Platform Modernization

1 · Purpose and what this plan owns G-02

The RTM records G-02 because the rollback, hypercare and cutover-window requirements had no single owning document — they were implied across the FSD, the Test Strategy and the schedule, but a cutover run from three documents at once is a cutover with no one holding the sequence. This plan is that document. It does not restate the data-conversion rules; those belong to the Data Conversion Plan. It owns what happens to the service — the outage, the switch, the decision, the fallback, and the elevated-support period that catches what testing did not.

Cutover is the moment a mandatory replacement concentrates all of its risk. Every earlier phase — requirements, build, conversion, testing — can be re-attempted at relatively low cost. Cutover cannot: it takes the live service offline, moves it, and turns it back on, and for a bounded window the organisation has no production platform at all. A program can absorb a slipped requirement or a failed test cycle; it cannot absorb a cutover that neither completes nor rolls back cleanly. That asymmetry — low-cost failure everywhere else, high-cost failure here — is why this plan is built around a single reversible decision and a rehearsed fallback rather than around a schedule, and why its readiness gate is the most demanding gate in the program.

2 · Cutover readiness — the entry gate Go / no-go

The cutover window does not open on schedule; it opens on readiness. A cutover begun before its preconditions are met is a cutover that discovers, mid-window, that it cannot complete or cannot roll back — the two worst outcomes. The readiness gate is checked at a formal go/no-go meeting before the window opens.

Why a weekend window, and the change freeze that protects it

The cutover is scheduled into a low-volume weekend window for one reason: the outage it requires is least disruptive when enrollment and claims traffic are lowest, and the time available to convert, validate and — if necessary — roll back is greatest. A weekday cutover would compress every phase of the §3 runbook against live business volume and leave no room for the point-of-no-return decision to go the wrong way. A change freeze is imposed on both platforms ahead of the window: no configuration or data changes are made to legacy once the extract snapshot is frozen, and none to the new platform once UAT is signed off, so that the thing tested is exactly the thing cut over. A late change slipped in "to be helpful" is a change that was never in any dry run — and the freeze exists precisely to stop it.

3 · The cutover runbook TR-006 · TR-007

The cutover executes as a sequenced runbook over the cutover weekend, timed against the conversion duration measured in Dry Run 2. Each phase has an owner and an explicit checkpoint; the runbook does not advance to the next phase until the current phase's checkpoint is confirmed.

4 · Rollback — the runbook for the decision that must never improvise TR-007

The Data Conversion Plan requires the rollback path to exist and be tested. This plan carries how it is executed. The rollback is available only up to the point of no return; its whole design purpose is to make reverting to legacy a practised, bounded action rather than a panic.

5 · Hypercare — elevated support after cutover TR-010

TR-010 requires hypercare staffed at elevated levels for a defined period following cutover. Hypercare exists because a smoke test proves the platform runs; only production volume proves it runs correctly, and the first real claims, the first real enrollment changes and the first real member-cost-share calculations against converted accumulators are where residual conversion and configuration issues surface. Hypercare is the controlled period in which they are caught fast and fixed fast, before they compound.

• Elevated staffing, defined duration. Support is resourced above steady-state for a bounded hypercare window running from Go-Live toward Production Support Handover / Closeout (02 Nov 2027). The elevation is temporary by design; permanent elevation would mean the platform never stabilised.
• Triage prioritises member-visible harm. An incorrect accumulator (FS-008) or a misadjudicated claim reaches a real member as real money, and is triaged ahead of internal inconvenience. The Customer Experience Manager (V. Alaoui) owns the member-facing view of hypercare.
• Exit is a decision, not a date. Hypercare ends when incident rate and severity return to steady-state thresholds — not merely when the calendar window elapses. Ending hypercare on schedule while incidents are still elevated would hand an unstable platform to a support team sized for a stable one.

Hypercare severity and response

Not every post-cutover issue is equal, and triage is what keeps elevated staffing from being consumed by noise while a member-money defect waits. Incidents are classified on the harm they reach rather than on how loudly they are reported.

The classification is a control on the staffing, not just on the queue: elevated support exists to make Sev 1 and Sev 2 fast, and the exit from hypercare is defined against those, not against Sev 3 volume that will exist on any live platform.

6 · Legacy retention and external notification TR-011 · TR-012

Two requirements bracket the cutover on either side — one looks backward at the legacy system, one forward at the people affected.

TR-011 — legacy read-only retention

Legacy platform access is retained read-only after cutover until data-retention obligations are verified as satisfied — owned by M. Alvarez. This is not sentiment; it is the safety net the rollback (§4) depends on during the window, and the system of record for any post-cutover question that converted data cannot answer. Read-only is deliberate: the legacy platform must not accept new transactions that would fork the system of record. Retention ends only when the obligations are verified satisfied, not when someone assumes they are.

TR-012 — member and provider notification

Any externally visible change is notified to members and providers in advance — owned by V. Alaoui and coordinated with the Communications Plan. The Communications Plan surfaces Customer Service as the under-served stakeholder and defines a deliberate quiet period; cutover notification is the moment that quiet period ends. The rule is advance notice of anything the member or provider will see — a planned outage, a changed portal, a different statement — because an unannounced visible change generates exactly the contact volume hypercare is least able to absorb in its first days.

Notification is sequenced, not a single broadcast. Providers are notified ahead of members, because a provider who understands the change absorbs member questions rather than escalating them — a well-briefed provider network is the first tier of contact deflection during hypercare. The notification names the outage window, what will look different afterward, and where to go for help, and it is timed so that it arrives with enough lead to be read and not so early that it is forgotten. Contingency wording is prepared in advance for the rollback case (§4): if the cutover is deferred, members and providers are told the planned change has been postponed, using a message that was written before the pressure of the moment rather than during it. A notification the organisation has to compose while executing a rollback is a notification that will be late, wrong, or both.

7 · Roles and sign-off Governance

8 · Traceability — this plan against the RTM G-02 closed

TR-001–005 are owned by the Data Conversion Plan; TR-008–009 by the Training Plan. G-02 closes with no requirement shared ambiguously between plans: where a requirement has both a data rule and an operational runbook (TR-006, TR-007), the data rule is stated once in the Data Conversion Plan and the runbook once here, cross-referenced rather than duplicated.