Enrollment & Claims Platform Modernization

The mandatory upgrade to a supported platform version, with configuration support, interface guidance and conversion support. Issued under the governing master agreement.

SOW-001 · Core Platform Upgrade

1 · Parties and Instrument

2 · Scope

The Client operates an enrollment and claims platform supplied by the Vendor, and the Vendor has announced end-of-support for the version the Client is running. The upgrade is therefore mandatory rather than discretionary — the program exists because a supported version is a condition of continuing to operate, not because a business case identified an opportunity. That distinction shapes everything below: the deadline is external, and scope reductions cannot reach the upgrade itself.

Alongside the upgrade sit conversion of historical data and re-establishment of six downstream integrations. Those are the Client's, not the Vendor's, and the boundary is drawn deliberately. Integration build, conversion execution and testing all depend on knowledge of the Client's own downstream systems and business rules. Outsourcing them would transfer that knowledge out of the organization at exactly the moment it is being rebuilt — the Client would finish the program with a supported platform and no one who understands it.

In scope. Supply and licensing of the supported target version; upgrade planning with a documented approach and technical prerequisites; execution of the upgrade across development, test, staging and production; configuration support to establish plan, benefit and business-rule configuration equivalent to current production; technical guidance to Client integration developers on platform interfaces and APIs; support to Client-executed data conversion; defect remediation through build, test and the Warranty Period; technical documentation and knowledge transfer to Client IT Operations; and support to Client cutover execution.

Out of scope. Development of the six downstream integrations. Execution of data conversion, reconciliation and testing. Business process change, training delivery and organizational readiness. Any work on the retired version beyond what the upgrade requires. Production operations after warranty exit on Nov 2, 2027.

Anything not described in this section is out of scope. The boundary is stated in both directions because on a mandatory upgrade the pressure to absorb adjacent work is highest exactly when the deadline is closest.

3 · Approach

The engagement runs in four phases aligned to the program's own milestones, so that a payment milestone and a program milestone are never two different dates. Non-production environments are upgraded and configuration proven before production is touched, and the rollback procedure is rehearsed rather than documented and hoped for.

Configuration is established against an equivalence test rather than a correctness test. The Vendor demonstrates that the upgraded platform produces outcomes equivalent to current production for the Client's plan, benefit and business-rule configuration. The oracle is the retiring system, which is an uncomfortable but necessary standard: nobody can specify twenty years of accumulated configuration from first principles, and the only available definition of correct is what the current system does today.

Interface and conversion work is delivered as guidance, not as build. The Vendor documents the target data structures, load mechanisms and constraints, and the Client's developers build against them. This is slower than having the Vendor build it, and it is the reason the Client still owns its own integrations at the end.

Defect severity is defined in Terminology and drives the response and resolution targets in Timeline and Resourcing. A Defect is a failure of delivered scope to perform to its specification — a request for behavior the specification never described is a variation, and the difference is worth keeping clean because it is the argument every upgrade eventually has.

4 · Delivery Phases

Phase 1 — Approach and licensing

The upgrade method and prerequisites documented, and licensed software delivered, before any environment is touched.

Phase 2 — Non-production upgrade and configuration

Development, test and staging upgraded and configuration demonstrated equivalent to current production. Aligns to System Upgrade Validated, Jan 5, 2027.

Phase 3 — Interfaces and conversion guidance

Documentation sufficient for the Client to build its own integrations and execute its own conversion. Aligns to Integration Build Complete, May 11, 2027.

Phase 4 — Production, cutover and warranty

Production upgraded with a rehearsed rollback, cutover supported, and the Warranty Period closed out. Go-Live Aug 24, 2027; warranty exit Nov 2, 2027.

5 · Acceptance

Each Deliverable is submitted with the evidence its acceptance criteria call for. The Client has the stated Review Period to accept, or to reject in writing with specific, criterion-by-criterion reasons. Silence for the whole Review Period is acceptance — deemed acceptance — because a program cannot hold a supplier to a date while leaving its own review open-ended.

A rejection must identify which criterion failed and how. An objection that the Deliverable is not what was expected, where it meets every stated criterion, is a variation rather than a rejection. The Vendor re-submits within ten Business Days and a second Review Period of five Business Days runs. A Deliverable rejected twice on the same criterion is escalated rather than looped.

The Review Period is deliberately short and deliberately symmetrical. The Client gains a fixed window in which to find defects; the Vendor gains certainty that the window closes.

6 · Timeline and Resourcing

Phases align to program milestones: System Upgrade Validated Jan 5, 2027; Integration Build Complete May 11, 2027; Testing Complete / UAT Sign-off Aug 10, 2027; Go-Live Aug 24, 2027; warranty exit and closeout Nov 2, 2027. A payment milestone and a program milestone are deliberately the same date.

Defect response and resolution targets: Critical — production unavailable, data loss or corruption, or an incorrect financial transaction — 1 hour response, continuous effort until resolved. High — core business function unusable with no workaround — 4 business hours, 2 business days. Medium — impaired with an acceptable workaround — 1 business day, next scheduled release. Low — 3 business days, by agreement. Delivery measures: Deliverables submitted by due date ≥ 95%; accepted on first submission ≥ 90%; Critical and High Defects resolved within SLA 100%.

7 · Fees and Payment

Fixed price of $1,850,000, payable against seven milestones. Percentages are stated alongside amounts so that a variation to the value does not leave a schedule that no longer sums.

Invoices are payable thirty days from receipt of a correct invoice. The Client may withhold the disputed portion, and only that portion. No fee is payable for a Deliverable that has not been accepted.

8 · Assumptions

The dates and the price in this Statement of Work rest on the following. Each is stated so that its failure is visible rather than argued about later; where one fails, the consequence is handled under Project Variations.

• Environments and infrastructure meeting the Vendor's documented prerequisites are provided by M. Alvarez, per the D-01 prerequisites.
• The baselined Business Requirements Document is available as the configuration basis from F. Jones at the Nov 3, 2026 milestone.
• Named decision-makers are available for configuration decisions throughout, per C. Tyrrell.
• Deliverables are reviewed and accepted or rejected within the ten-business-day Review Period by J. Albert.
• De-identified data of production-representative volume is provided by T. McCormick before D-03 acceptance.
• Data conversion, reconciliation and all testing are executed by the Client (T. McCormick / R. Whitfield) per the program schedule.
• Access and security clearance for Vendor personnel are provided at mobilization by M. Alvarez.
• Cutover is executed by the Client on Aug 24, 2027, with the Vendor in support.

9 · Project Variations

Either party may propose a variation. The Vendor prices it within five Business Days, stating the effect on fees, on dates, and on any other Deliverable. No variation takes effect until both parties sign, and work performed in anticipation of one is at the Vendor's own cost — the clause exists so that goodwill work does not arrive later as an invoice.

Where an assumption in the preceding section fails, the consequence is handled here rather than absorbed silently. A failed dependency moves the affected dates by the period of delay and no more; it does not reopen scope or price unless the parties agree that it should.

A variation that alters the program baseline set at the Nov 3, 2026 milestone is additionally subject to program change control and the Change Control Board, not to this SOW alone. A change within the SOW is a commercial matter between the parties; a change to the baseline is a program matter that other work packages depend on.

10 · Terminology

11 · Governing Agreement

This Statement of Work is issued under the Master Services Agreement between the parties and creates no rights independent of it. Warranty, limitation of liability, intellectual property, confidentiality, data protection, insurance, termination and dispute resolution are governed by the MSA and are not restated here. Restating them invites the two documents to disagree, and a Statement of Work that contradicts its own master agreement is worse than one that is silent.

Where the Vendor handles protected health information, the parties' Business Associate Agreement governs and prevails over both this SOW and the MSA to the extent of any conflict. On any other matter the order is: the BAA, the MSA, this SOW, then an executed variation, which prevails over this SOW only on the matter it changes. The Vendor's standard terms — in a portal click-through, an invoice footer or an order acknowledgement — are excluded.

12 · Execution

Executed following the approval convention this suite uses in SOW-001: the Vendor / Procurement Manager signs for the Client, the Vendor signs through its own authorized representative, and the internal approvals below are recorded separately. ⚠ The Program Manager approves but does not sign — program authority is not signing authority, and the separation is deliberate.

⚠ The Vendor is deliberately unnamed throughout this suite, so the vendor signature line carries a role rather than a person. That is the convention, not an omission — and an unexecuted Statement of Work does show a blank signature line on both sides. The Client side names individuals because they are the program's own people, who appear by name across the rest of the suite.