Summary. This checklist tracks a troubled software implementation from the first missed milestone through recovery, notice and cure, termination, transition, and claim preparation. It is written for in-house counsel, outside counsel, and project executives on both the customer and the vendor side, with vendor-specific items flagged throughout. Each phase lists specific, actionable tasks tied to the governing contract provisions and legal authority, including UCC adequate assurance, material breach standards, deemed acceptance, copyright ownership of custom code, preservation duties under Rule 37(e), and arbitration rules. Red-flag boxes identify the moments when a project problem becomes a legal problem. A deadlines table, a list of common failure points, and a short worked example involving a hospital system's revenue-cycle software rollout show how the phases fit together.

How to use this checklist

Most failed technology projects do not fail on one day. They fail over months, through slipped milestones, quiet staffing changes, unsigned change requests, compressed testing, and a go-live that should have been postponed. By the time anyone calls a lawyer, the decisions that shape the legal case (whether the customer accepted the system, whether the scope changed, whether anyone preserved the Slack history) have often been made by people who did not know they were making them.

Use this checklist in three ways:

  1. As a monitoring tool from contract signature, so that counsel is involved when the first warning signs appear, not after the termination letter.
  2. As a sequence once a dispute is likely: each phase assumes the earlier ones are complete.
  3. As a two-sided tool. Items marked (Vendor) are for the integrator or software provider. Unmarked items apply to the customer or to both sides.

Each item names the governing authority or contract provision where one applies. Contract references are to typical clauses; confirm the actual terms in your agreement. UCC Article 2 citations use California's enactment, the California Commercial Code, whose section numbers track the uniform text; check the version in force in the state whose law governs. For the underlying law, see Failed Software Implementations: Contract, Fraud, and Warranty Claims When an IT Project Goes Wrong. For the step-by-step litigation process, see Pursuing or Defending a Failed Technology Project Claim: A Practical Guide. The templates referenced below (notice of breach, cure plan, change order log, project record protocol, termination notice, settlement and transition agreement, damages model) are in Technology Project Dispute Toolkit: Notice of Breach Letters, Cure Plans, and Project Record Protocols.

Phase 1: Baseline at contract signature and kickoff

Do these once, at the start. They make every later phase faster and cheaper.

  • Abstract the contract stack. List the MSA, every SOW, the software license or subscription (often with a different company), change orders, amendments, and any incorporated proposal or RFP response. Note the order-of-precedence clause. Note: an integration clause usually excludes sales documents unless they are expressly incorporated. See How Courts Read Contracts: Ambiguity, Extrinsic Evidence, and the Canons of Construction.
  • Calendar the clocks. Notice periods, cure periods, acceptance windows (including any deemed-acceptance period), warranty periods, invoice dispute deadlines, renewal dates, and any contractual limitations period. Under Article 2, parties may shorten the four-year limitations period to not less than one year (Cal. Com. Code § 2725); service contracts often contain similar clauses.
  • Identify whether Article 2 may apply. Software sold as a product may be "goods"; implementation services usually are not. Compare Advent Systems Ltd. v. Unisys Corp., 925 F.2d 670 (3d Cir. 1991), with Pearl Investments, LLC v. Standard I/O, Inc., 257 F. Supp. 2d 326 (D. Me. 2003). The answer affects warranties, remedies, and limitations.
  • Record the materiality standard. If the termination clause defines material breach (for example, "material considering this Agreement as a whole"), that definition will govern (State v. International Business Machines Corp., 51 N.E.3d 150 (Ind. 2016)). Note any performance standards or service levels that measure it.
  • Record the limitation of liability. Cap amount and measurement period, exclusions, carve-outs (gross negligence, willful misconduct, fraud, data breach, confidentiality, IP indemnity), and whether cover or re-procurement costs are defined as direct damages.
  • Confirm IP ownership terms. A "work made for hire" clause alone rarely transfers contractor-written software, because software is not among the commissioned-work categories in 17 U.S.C. § 101. Confirm there is a present written assignment satisfying 17 U.S.C. § 204(a) and a license to the vendor's preexisting tools. See Work Made for Hire Determination Checklist: A Practical Checklist.
  • Confirm transition, data return, and escrow terms. Duration and rates for transition assistance, whether it survives termination for cause, data export format and timing, and any source code escrow deposit and release conditions.
  • Set project records discipline. Decide where decisions, change requests, risks, and status reports will live, who owns them, and how long they are retained. Make sure the customer has administrative access to (or regular exports from) any vendor-hosted project tool.
  • Set up a change order log and require every scope change, even agreed ones, to be logged and signed. Informal changes are the source of most scope disputes.
  • (Vendor) Document the assumptions and customer dependencies in the SOW in measurable terms (decision turnaround, subject-matter expert availability, data quality thresholds, environment readiness). Vague dependencies are hard to enforce.
  • (Vendor) Reconcile the sales record with the contract. Ask the sales team to confirm that every specific capability or experience claim in the proposal is accurate or is covered by the SOW. Statements of present fact outside the contract are the raw material of fraud claims.

Phase 2: Early warning signs

Review monthly, or at each steering committee meeting. Any two of these together justify counsel's involvement.

  • Milestone slippage. A milestone missed by more than a few weeks, or a re-baselined schedule presented as routine.
  • Staffing changes. Departure or replacement of key personnel named in the SOW, or a shift to junior or offshore staff not disclosed in the plan. Check whether the SOW requires customer approval of replacements.
  • Status report divergence. Status colors that never change, or a vendor report that says "green" while the customer's own team reports problems.
  • Change request backlog. More than a handful of unsigned change requests, or work proceeding on changes never formally approved.
  • Customer dependency failures. Late decisions, unavailable subject-matter experts, or unclean data. These are as important as vendor failures, because they become the vendor's defense.
  • Testing compression. User acceptance testing shortened to protect a go-live date, or exit criteria for testing relaxed.
  • Defect trend. Open high-severity defects not declining as go-live approaches.
  • Budget burn. Time-and-materials spend tracking well ahead of progress, or a fixed-fee vendor requesting "out of scope" payments.
  • Publisher-integrator finger-pointing. The integrator blaming the software and the publisher blaming the configuration.
  • (Vendor) Internal risk ratings worse than what is being reported to the customer. Correct the external reporting immediately; the gap is discoverable and damaging.
  • (Vendor) Internal messages describing the project as unrecoverable or the team as unqualified. Escalate internally to delivery leadership and counsel.

Red flag: the status report gap. If the vendor's internal risk register or internal messages describe the project materially worse than the reports sent to the customer, the customer may later frame the external reports as misrepresentations. The Hertz litigation against Accenture included allegations that code testing had been misrepresented; the court dismissed that statutory claim for lack of particularity, but the theory recurs (Hertz Corp. v. Accenture LLP, No. 19-cv-3508 (S.D.N.Y. Oct. 25, 2019)). Vendors should fix the gap; customers should preserve the reports.

Phase 3: Escalation and recovery

Before anyone sends a formal notice, try to fix the project while building the record.

  • Invoke formal governance. Use the contractual escalation path (project managers, then steering committee, then executives). Minute every meeting and circulate minutes for correction.
  • Demand a written recovery plan with named resources, dates, and measurable exit criteria. A recovery plan agreed in writing becomes the yardstick for later breach claims.
  • Demand adequate assurance where available. If Article 2 governs, a party with reasonable grounds for insecurity may demand adequate assurance in writing and treat failure to provide it within a reasonable time (not over 30 days) as repudiation (Cal. Com. Code § 2609; Cal. Com. Code § 2610). Many states recognize a similar common law right.
  • Reserve rights in writing. Every communication that agrees to a new date, a workaround, or continued payment should state that it is without waiver of rights. Course of dealing can otherwise modify the contract.
  • Reconcile the change order log. Agree in writing which changes were approved, which were not, and their price and schedule impact.
  • Pay undisputed invoices; dispute others properly. Follow the invoice dispute procedure and deadline. Withholding undisputed amounts can hand the vendor a breach claim or suspension right.
  • Fix your own dependencies. Assign decision-makers, restore subject-matter experts, and resource data cleanup. A customer that cures its own failures during recovery strengthens its later claim.
  • (Vendor) Upgrade the team if the problem is staffing, and confirm in writing that replacements meet the SOW's qualifications.
  • (Vendor) Notify your errors and omissions insurer if a claim appears likely. Late notice can forfeit coverage.
  • (Vendor) Document customer-caused delays contemporaneously in change requests, risk logs, and meeting minutes, not in a retrospective.

The go-live decision

  • Read the acceptance and deemed-acceptance clauses before go-live. Production use may constitute acceptance under the contract. Under Article 2, acceptance (Cal. Com. Code § 2606) does not bar damages, and revocation of acceptance remains available for substantial impairment (Cal. Com. Code § 2608), but contractual acceptance may end the right to reject.
  • If going live with known defects, document it. Put in writing that go-live is a business necessity, is not acceptance, and is subject to resolution of listed open defects by stated dates, with all rights reserved. Get the vendor's acknowledgment if possible.
  • Do not sign an acceptance certificate that does not list open defects and reserve rights.
  • (Vendor) Obtain written acceptance or written confirmation of production use where the contract makes it acceptance. Ambiguity at go-live is resolved later by a factfinder.

Red flag: go-live under protest. The worst records combine a signed acceptance certificate, a go-live with dozens of known severe defects, and no reservation of rights. That sequence can turn a strong breach claim into a warranty claim with a refund-only remedy.

Phase 4: A dispute is reasonably anticipated. Preserve and protect

Start this phase the first time anyone threatens termination, sends a notice of breach, mentions lawyers, or withholds a significant payment.

  • Issue a written litigation hold to all project custodians (business, IT, finance, executives, contractors) and IT administrators. The duty arises when litigation is reasonably anticipated (Zubulake v. UBS Warburg LLC, 220 F.R.D. 212 (S.D.N.Y. 2003)). See Litigation Hold and Evidence Preservation Checklist: A Practical Checklist.
  • Suspend auto-deletion in email, Slack, Microsoft Teams, and any ephemeral messaging tool used by the project. Lost ESI can lead to curative measures or, with intent to deprive, severe sanctions under Fed. R. Civ. P. 37(e).
  • Export the project systems: ticketing (Jira, Azure DevOps, ServiceNow) with full change history, the code repository with commit history, test management tools, Confluence or SharePoint spaces, and project plans. Do it before access is lost.
  • Collect personal devices of key custodians who used texts or personal messaging for project work. See Messaging and Social Media Evidence Checklist: A Practical Checklist.
  • Send a preservation demand to the other side and, where relevant, to the publisher, subcontractors, and staffing firms.
  • Route assessment work through counsel. Retain any project review consultant through counsel to preserve work product protection and consulting-expert protection under Fed. R. Civ. P. 26(b)(4)(D). A business "lessons learned" exercise without counsel is generally discoverable.
  • Instruct the team about internal communications. No speculation about fault in email or chat; questions go to counsel.
  • Build a document-based chronology: sale, signing, kickoff, milestones (planned versus actual), change requests, escalations, testing, go-live, notices.
  • (Vendor) Suspend account deprovisioning for consultants who roll off, and send hold notices to subcontractors and offshore delivery centers.

Red flag: vendor-hosted tools. If the vendor hosts the project's Jira or Confluence instance and the customer has no export, the customer's most important evidence is in the other side's hands. Request the export before any notice of breach is sent.

Phase 5: Notice of breach and cure

  • Confirm the notice mechanics: addressee, address, delivery method (courier, email, both), signatory, and any copy-to requirement. Defective notice can invalidate a later termination.
  • Complete any mandatory escalation step that the contract makes a condition precedent to notice, termination, or dispute resolution.
  • Identify each breach specifically, tied to a contract provision (milestone, acceptance criterion, key personnel clause, service level), with a short description of the evidence. Fewer, stronger breaches beat a long list.
  • State what cure requires, with measurable criteria, and set the deadline the contract allows (commonly 30 days).
  • Demand a written cure plan within a short period (for example, ten business days) with named resources and dates.
  • Reserve all rights, including termination and damages, and state that continued performance and payment are under reservation.
  • Consider separating settlement discussions into a labeled channel. Compromise offers and negotiations are generally inadmissible to prove liability or amount under Fed. R. Evid. 408, but facts disclosed are not privileged.
  • Do not announce termination in the notice. A notice that treats termination as decided suggests the cure period is illusory.
  • (Vendor) Respond in writing within the period, point by point: accept and cure, or dispute with reasons and references to customer obligations and approved changes.
  • (Vendor) Offer only a cure plan you can meet. A missed cure plan is the customer's best exhibit.
  • (Vendor) Identify the customer's own open obligations in the response and ask that they be met.
  • (Vendor) Keep staffing stable during the cure period. Pulling people off looks like abandonment.

Red flag: the shifting breach list. A termination letter that relies on breaches not identified in the notice invites a finding that the vendor never had an opportunity to cure them. Keep the notice and the termination aligned.

Phase 6: The termination decision

  • Test materiality against the contract's standard, or, if the contract is silent, against the Restatement (Second) of Contracts § 241 factors (loss of expected benefit, adequacy of damages, forfeiture, likelihood of cure, good faith). Substantial performance doctrine protects vendors whose deviations are minor (Jacob & Youngs, Inc. v. Kent, 230 N.Y. 239 (1921)).
  • Confirm the cure period has run and the cure failed by the stated criteria.
  • Choose the basis: for cause; for convenience (with the contractual wind-down payment and preservation of accrued claims); partial termination of a SOW or phase; or, where permitted, cause with convenience in the alternative.
  • Line up the replacement (new integrator, in-house team, or stabilization plan) before terminating.
  • Confirm which agreements survive. The license or subscription may continue even if the implementation SOW ends.
  • For public-sector contracts, follow the applicable termination regulations or procurement code. Federal contracts follow 48 C.F.R. pt. 49.
  • Send a termination notice that complies with the notice clause, cites the provision relied on, references the earlier notice and failed cure, invokes transition assistance, demands data and deliverables, and reserves claims.
  • (Vendor) Decide quickly whether to contest the termination or accept it and pursue fees. Either way, perform transition obligations.
  • (Vendor) Do not disable systems, withhold the customer's data, or lock out administrators without clear contractual authority. Remote disabling can create exposure under 18 U.S.C. § 1030.

Red flag: termination without an exit. A customer that terminates before it has its code, data, credentials, and documentation may spend more getting them back than it ever recovers in damages.

Phase 7: Transition and exit

  • Invoke transition assistance in writing and agree a transition plan with deliverables, dates, and named vendor contacts.
  • Obtain all deliverables and work in progress: source code for custom development, configurations, interface specifications, data conversion scripts, test scripts and results, documentation, architecture diagrams, and runbooks.
  • Obtain credentials and administrative access for every environment, cloud tenant, and third-party service; rotate credentials after the vendor's access ends.
  • Export customer data in the agreed format, verify completeness, and obtain a deletion certification after export.
  • Confirm ownership of custom code. If the contract has a valid assignment, obtain any confirmatory assignment needed. If not, rely on the implied license a paying customer usually holds (Asset Marketing Systems, Inc. v. Gagnon, 542 F.3d 748 (9th Cir. 2008); Effects Associates, Inc. v. Cohen, 908 F.2d 555 (9th Cir. 1990)) and negotiate an express license that covers modification by a replacement vendor.
  • Identify the vendor's preexisting IP (accelerators, frameworks, tools) embedded in deliverables, and confirm the license to it survives termination.
  • Protect the replacement project from claims that it misused the departing vendor's proprietary materials; consider a clean-room approach for any rebuilt components. See Software Interoperability and Reverse Engineering Clearance Checklist: A Practical Checklist.
  • Check escrow release conditions if the publisher or vendor is insolvent or has ceased support; in bankruptcy, a licensee may elect to retain rights in licensed intellectual property, including escrow rights, under 11 U.S.C. § 365(n).
  • Consider emergency relief if the vendor refuses contractual transition cooperation and the business faces irreparable harm. Check whether the arbitration clause permits court applications for interim relief or provides an emergency arbitrator; otherwise see Fed. R. Civ. P. 65.
  • Track transition costs separately. They may be recoverable damages and they are evidence of mitigation.
  • (Vendor) Deliver transition items promptly and log each delivery with the date and recipient. A clean transition record helps on damages and reputation.
  • (Vendor) Invoice transition work at contract rates and keep it separate from disputed amounts.

Phase 8: Claim preparation

Deadlines table

Event Typical deadline Source Consequence of missing it
Rejection of a deliverable Often 5-15 business days after delivery Acceptance clause Deemed acceptance
Invoice dispute Often 15-30 days after invoice Payment clause Invoice deemed undisputed; late fees; suspension right
Cure period after notice of breach Commonly 30 days (shorter for payment) Termination clause Premature termination is wrongful
Adequate assurance response (UCC) Reasonable time, not over 30 days Cal. Com. Code § 2609 Failure may be treated as repudiation
Notice of breach of warranty (UCC) Within a reasonable time after discovery Cal. Com. Code § 2607 (UCC § 2-607(3)(a)) Barred from any remedy
Revocation of acceptance (UCC) Within a reasonable time after discovery, before substantial change Cal. Com. Code § 2608 Revocation ineffective
Litigation hold When litigation is reasonably anticipated Zubulake; Rule 37(e) Spoliation sanctions
Insurer notice (vendor) As soon as practicable; per policy E&O policy Loss of coverage
Transition assistance request Per contract; often at or before termination Transition clause Loss of contractual assistance
Contractual limitations period Often 1-2 years MSA Claim barred
UCC limitations 4 years from tender of delivery (may be shortened to 1) Cal. Com. Code § 2725 Claim barred
Motion to vacate an arbitration award 3 months after award is filed or delivered 9 U.S.C. § 12 (grounds in 9 U.S.C. § 10) Award becomes unchallengeable

Common failure points

  1. No reservation of rights at go-live. The customer accepted a defective system by using it.
  2. Defective notice. Wrong address or method; the termination fails.
  3. Termination for breaches never noticed. The vendor had no chance to cure.
  4. Vendor-hosted evidence. The customer never exported the project tools and lost access on termination.
  5. Auto-deleting chat. Neither side suspended retention settings, and the best evidence vanished.
  6. "Work made for hire" without assignment. The customer discovers it does not own its own custom code.
  7. The status report gap. Vendor internal reports showed red while external reports showed amber.
  8. Customer dependencies ignored. The customer's claim collapses under its own late decisions and missing data.
  9. Short contractual limitations. A one-year clause runs while the parties negotiate.
  10. Litigation before arbitration. A party files suit, litigates, then tries to compel arbitration and is found to have waived.

Worked example: Kestrel Valley Health and Arclight Revenue Systems

Kestrel Valley Health, a four-hospital system, contracts with Arclight Revenue Systems for a cloud revenue-cycle platform and a fixed-fee implementation ($5.2 million) to go live on July 1. In March (Phase 2), Kestrel's counsel sees three warning signs: Arclight's named integration architect has left, 14 change requests are unsigned, and UAT has been cut from eight weeks to three. Counsel convenes the steering committee (Phase 3), obtains a written recovery plan, reconciles the change order log (Arclight agrees that nine changes are in scope at no cost and five are priced), and sends an email reserving rights on the new dates.

On July 1, Kestrel goes live with 31 open high-severity defects because its legacy vendor contract expires. Following the checklist, Kestrel's CFO signs a go-live memorandum stating that production use is a business necessity, is not acceptance, and is conditioned on resolution of the listed defects by August 15, with all rights reserved; Arclight's project director countersigns. Claims denials spike in August. Kestrel issues a litigation hold, exports Arclight-hosted Jira and Confluence spaces, and retains a consultant through counsel (Phase 4). On September 3 Kestrel sends a notice of breach identifying four breaches tied to the acceptance criteria and key-personnel clause, demanding a cure plan in ten business days and cure within 30 days (Phase 5). Arclight responds point by point, disputes two breaches (citing Kestrel's late payer-contract data), and proposes a cure plan. The plan fails two of three exit criteria.

Before terminating, Kestrel confirms that the SOW contains a present assignment of custom interfaces, obtains repository access and documentation, and lines up a replacement integrator (Phase 6). It terminates the implementation SOW for cause on October 20, keeps the platform subscription in force, and invokes 120 days of transition assistance. Arclight contests cause but performs the transition (Phase 7). Kestrel's damages model separates the $2.4 million cost to complete the original scope from $700,000 of new features, and its counsel concludes that its lost collections are likely excluded as consequential damages unless a fraud claim, based on a proposal statement about completed hospital integrations, is supported by discovery (Phase 8). The one-year contractual limitations period runs from the date of the claim; the parties sign a tolling agreement and mediate in January.

This document is general information, not legal advice for any particular situation; the law changes, and the facts matter.

Related Documents

Related Articles

Related Guides

Related Checklists

Related Toolkits