Vendor SOW Summary & Performance Scorecard — PulseConnect

Data export support, a dedicated technical contact through transition, and written deletion certification for CareLink Classic. Issued under the parties' existing agreement.

SOW-001 · Legacy Platform Transition and Offboarding Services

1 · Parties and Instrument

2 · Scope

Vantix Health Systems supplies CareLink Classic, the platform MedConnect Mobile replaces. The Vendor's announced end-of-support window is what drove this program in the first place, which makes this engagement unusual among vendor contracts: the Client is buying the Vendor's cooperation in its own replacement. The commercial relationship is ending by agreement, and the work below exists to make that ending clean rather than contested.

Offboarding is a one-time, checklist-driven engagement, distinct from the ongoing management of the incoming platform vendor. It runs alongside the program's sprints rather than as a separate track, because every migration increment depends on export access the Vendor controls.

In scope. Export access to all Client Data held in CareLink Classic, including inactive-patient and archival visit history; schema and field-mapping documentation sufficient for the Client to build its own migration pipeline; a dedicated technical contact through the transition window; support to the Client's migration validation at each sprint anchor; and written deletion certification following the Client's formal deletion request.

Out of scope. Building or operating the migration pipeline, which is the Client's. Data remediation or cleansing of records the Vendor holds. Any work on the replacement platform. Decommissioning of Client-side infrastructure. Retention of an archival export after certification, which is the Client's own records-retention obligation.

Anything not described in this section is out of scope. The boundary matters more than usual here, because a vendor being replaced has no commercial incentive to absorb unstated work.

3 · Approach

The engagement is sequenced to the program's sprints rather than to calendar months, so that each Vendor obligation lands where the Client actually needs it. Export access and schema documentation come first, because the Client cannot build a migration pipeline against a schema it has not seen. Validation support follows each migration increment, and the deletion request is only made once migration is validated and the second release is confirmed GO.

The order is deliberate and irreversible in one direction: deletion cannot precede validated migration. The Client therefore accepts each migration validation in writing before the deletion request is raised, and the Vendor is not entitled to treat an unvalidated migration as complete.

The Vendor's obligations are documentation and access, not execution. This is stated positively in Scope and repeated here because it is the commonest misunderstanding in an offboarding: the Client's team builds the pipeline, runs the migration and validates the result, and the Vendor makes that possible rather than doing it.

Certification closes the engagement. The written deletion certification is the last Deliverable and the final payment milestone, because it is the only evidence the Client can show that patient data no longer sits on a retired vendor's systems.

4 · Delivery Phases

Phase 1 — Export access and schema (Sprint 1)

Everything the Client needs to build a migration pipeline, before it builds one.

Phase 2 — Active-record migration support (Sprints 1–5)

Support to the Client's validation of active-patient migration ahead of the first release.

Phase 3 — Historical and archival migration (Sprints 4–7)

The full record set, including the inactive and archival history that is easiest to leave behind and hardest to recover later.

Phase 4 — Deletion and certification (Sprint 8 and post-program)

The engagement closes on evidence, not on assurance.

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. The Vendor re-submits within five Business Days and a second Review Period of three Business Days runs. ⚠ Review Periods here are shorter than a waterfall program would use, because acceptance is anchored to sprint boundaries: a ten-day review would straddle two sprints and stall the migration work that depends on it.

6 · Timeline and Resourcing

Phases are anchored to program sprints rather than to dates, because the migration increments they support are. Export access and schema land in Sprint 1; active-record validation runs to Release 1; historical and archival migration completes by Sprint 7; the deletion request follows in Sprint 8 once Release 2 is confirmed GO, and certification arrives post-program.

⚠ The end-of-support date is fixed and external. It does not move if a sprint slips, which is why the assumptions below are written as conditions on the price rather than as expectations.

The table below shows who is involved on each side. Client effort is not charged under this SOW; it is shown because the Vendor's obligations depend on it.

7 · Fees and Payment

Fixed price of $45,000, one-time, covering data export support and the dedicated technical contact through transition. Payable against Deliverables rather than elapsed time:

• 30% on acceptance of D-V1 — export access and schema.
• 25% on acceptance of D-V2 — active-record export validated.
• 25% on acceptance of D-V3 — full historical export validated.
• 20% on acceptance of D-V4 — written deletion certification.

⚠ The final twenty percent is deliberately held against certification rather than against decommission. Certification is the only Deliverable that cannot be produced by the Client alone, and a vendor being replaced has least incentive to produce it once the rest is paid.

Invoices are payable thirty days from receipt of a correct invoice. No fee is payable for a Deliverable that has not been accepted.

8 · Assumptions

The price and the sprint anchors 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.

• Export access is provided within five Business Days of execution. Every subsequent phase depends on it, so a delay here compresses the work rather than moving the end-of-support date.
• Schema documentation reflects the production schema as deployed. A discrepancy found during pipeline build is a Vendor obligation to correct, not a Client variation.
• The dedicated technical contact is available during Client business hours through the transition window, responding to field-mapping queries within two Business Days.
• The Client builds, runs and validates the migration pipeline. The Vendor provides access and documentation and does not execute migration.
• The formal deletion request is raised by the Client only after full historical migration is validated and Release 2 is confirmed GO.
• Deletion certification is issued within thirty days of that request, per the underlying contract.
• No further licensing fees are incurred after Client-side decommission, and the contract lapses at the end-of-support date rather than renewing.

9 · Project Variations

Either party may propose a variation. The Vendor prices it within three Business Days, stating the effect on fees, on sprint anchors, 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.

Where an assumption in the preceding section fails, the consequence is handled here rather than absorbed silently. ⚠ The binding constraint on this engagement is the Vendor's own announced end-of-support date: a delay does not move it. A failed assumption therefore compresses the remaining work rather than extending the end date, and the parties agree the reduced scope in writing rather than discovering it at cutover.

A variation that alters a sprint anchor is additionally subject to the program's change-control process, because other backlog items depend on those dates.

10 · Terminology

11 · Governing Agreement

This Statement of Work is issued under the parties' existing agreement for CareLink Classic and creates no rights independent of it. Warranty, limitation of liability, intellectual property, confidentiality, insurance and dispute resolution are governed by that agreement and are not restated here. Restating them invites the two documents to disagree.

Two terms of the underlying contract are load-bearing for this engagement and are therefore referenced rather than restated: ACME Health retains full ownership of patient data, and the contract obliges the Vendor to provide export access and a written deletion certification on termination. Nothing in this SOW reduces either. The data-processing agreement governs the handling of patient data and prevails over this SOW to the extent of any conflict.

12 · Execution

⚠ The Vendor signs through its own authorized representative. An unexecuted Statement of Work shows 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 this suite.