Migration + License Addendum Playbook (Copy/Paste Kit)

Use this mini‑template as an addendum to your next SOW. Pick one pricing path (or offer two with a default). Keep the Background‑IP schedule honest and specific. Include a guaranteed data handback so renewals are about value, not hostage dynamics.

Clause 1 — Module Description

1.1 Licensed Module. Provider grants Client the right to use the [MODULE NAME] module (the "Module") embedded within the Deliverables to [OUTCOME] as described in Exhibit A (Specification).
1.2 Scope. The Module includes the following Provider‑owned components: see Exhibit B (Background‑IP Schedule).

Clause 2 — Ownership & IP Boundaries

2.1 Background IP. Each party retains ownership of its Background IP. "Background IP" means IP, code, models, libraries, templates, and tools conceived or developed by a party prior to or independent of the SOW.
2.2 Foreground/Developed IP. Except for the Module and items listed in Exhibit B, Client owns Deliverables specifically created for Client under this SOW ("Developed IP").
2.3 No Assignment of Provider Background IP. Provider does not assign ownership of Provider Background IP or the Module. Client receives the license in Clause 3.

Clause 3 — License Grant (choose one or more)

Option A (Seat Plan). Provider grants Client a non‑exclusive, non‑transferable license to use the Module for up to [SEAT_CAP] Named Users during the [TERM], within [TERRITORY]. Fees: $[SEAT_PRICE]/user/month; overage at $[OVERAGE_PER_SEAT].

Option B (Usage Plan with Caps). Provider grants Client a non‑exclusive license to use the Module up to [USAGE_CAP] [USAGE_UNIT]/month, with soft cap and throttling above that threshold. Fees: $[BASE]/month + $[PER_UNIT] per [USAGE_UNIT] above [INCLUDED_UNITS], subject to a monthly charge ceiling of $[MONTHLY_CAP]. Publish real‑time usage meters to Client’s admin.

Option C (Revenue‑Share Plan). For Module‑linked revenue streams defined in Exhibit C, Client pays [REV_SHARE_%]% of Net Revenue attributable to the Module, with a monthly minimum of $[MIN_COMMIT] and an annual true‑up against committed use.

Clause 4 — Transparency, Caps, and Fair‑Use

4.1 Visibility. Provider will expose usage meters and seat rosters to Client admins.
4.2 Caps. Usage charges shall not exceed the monthly cap in Option B without written consent. Client may pre‑purchase committed use at a discount of [X]%.
4.3 Fair‑Use Protections. Provider will implement rate‑limiting and backoff to preserve stability; no penalty for transient spikes under [SPIKE_WINDOW] minutes.

Clause 5 — Security & Data Processing

5.1 DPA/Data Exchange. The parties adopt Exhibit D (Data Processing/Data Exchange Agreement) governing personal data and cross‑system transfers, including Article 28 GDPR‑aligned return/deletion obligations where applicable.

Clause 6 — Guaranteed Data Handback (portability)

6.1 On termination or Client request, Provider will export Client Data in [DATA_FORMAT] with schema docs within [HANDOFF_WINDOW_DAYS] days. Provider will provide reasonable export assistance at $[EXPORT_ASSIST_RATE]/hour, not to exceed [ASSIST_CAP] hours without approval.
6.2 Deletion & Certification. Within [DELETE_WINDOW_DAYS] days of export, Provider will delete remaining Client Data (except to the extent retention is legally required) and supply a deletion certificate.

Clause 7 — Migration Cooperation

7.1 Cutover & Rollback. The parties will follow Exhibit E (Migration Runbook), including rate‑limit strategy, non‑prod test, cutover window, and explicit rollback triggers.

Clause 8 — Term, Termination, Audit

8.1 Term. [TERM]. 8.2 Termination for Convenience: [NOTICE_DAYS] days.
8.3 Metering/Audit. Provider’s metering is subject to independent verification upon 10 business days’ notice.

Exhibit B — Background‑IP Schedule (Template)

Component: [NAME]
Type: [Library | Connector | Model | Template | Script]
Version/Commit: [V|HASH]
Owner: Provider
Embedded In: [Deliverable/Service Step]
License to Client: [SOW‑Bound Use Only | Internal Use | Per‑Seat | Per‑Usage]
Third‑Party Licenses: [List if any]
Notes/Limits: [E.g., no source code disclosure; runtime only]

Exhibit C — Revenue Attribution Rules (if using Option C)

Attribution Model: [Last‑touch | Split | Uplift]
Inclusions: [SKUs/Transactions]
Exclusions: [Taxes, refunds, pass‑through fees]
Reporting: [Frequency, source of truth]

Exhibit D — DPA/Data Exchange (attach your DPA or template)

Exhibit E — Migration Runbook (see Section 2).

List every Provider‑owned element that ships with the client’s build. Be precise, so reuse is protected and the client’s rights are clear.

Example filled row set:

Component: ETL Connector — Stripe → Warehouse
Type: Connector (Make.com scenario)
Version/Commit: v3.4.1
Owner: Provider
Embedded In: Billing analytics Module (Deliverable §A)
License to Client: Internal use within Client’s [BRAND] operations; no redistribution; runtime only
Third‑Party Licenses: Stripe API terms; Make.com license
Notes/Limits: Source not provided; config and scenario JSON provided; rate‑limit backoff baked in

Component: Prompt Library — Support Triage
Type: Prompt/Template Set
Version/Commit: 2026‑05‑15
Owner: Provider
Embedded In: Support agent assist flow
License to Client: Seat‑based under Option A; export of prompts allowed on termination
Third‑Party Licenses: OpenAI model terms (client account)
Notes/Limits: Evaluated prompts remain Provider Background IP; Client may use compiled variants internally

Component: Forecasting Model
Type: Notebook + lightweight service
Version/Commit: 1.2
Owner: Provider
Embedded In: Revenue forecast dashboard
License to Client: Usage‑based under Option B; API access key w/ monthly cap
Third‑Party Licenses: MIT libs listed in NOTICE
Notes/Limits: Model weights not provided; inference only

Tips:

• If you can’t list it in one line, you probably need to split components.
• Tag anything you plan to reuse across clients.
• Avoid promising source access unless the price reflects it.

This is the runbook your PM follows so the cutover passes the Lisbon Test (it works on café Wi‑Fi, has a backout plan, and keeps customer data safe). Copy this into Exhibit E and adjust.

Pre‑migration (T‑14 to T‑7)

• Owners named: [CLIENT PM], [PROVIDER PM], [TECH LEADS]. Single Slack/Signal channel set up.
• Environments ready: Non‑prod mirror with masked data. Access keys rotated.
• Schema diff complete: Source vs target with field‑by‑field map; null/default rules captured.
• Data quality gates: Define reject/skip lists, idempotency keys, and dedupe logic.
• Throughput estimate: Rough volume, record size, and acceptable window.

Rate‑limit and resiliency plan

• Prefer bulk/export endpoints where available.
• Implement client‑side throttling and exponential backoff with jitter on 429s/timeouts.
• Batch size tuned and resumable checkpoints written to [STORE].
• Retries bounded; poison‑message queue for manual review.

Testing (T‑7 to T‑3)

• Dry run on 1–5% of data; reconcile counts and key metrics.
• Functional tests: Queries, dashboards, and workflows that depend on migrated data.
• Non‑functional tests: Latency, error budgets, and rate‑limit behavior under load.

Cutover window (T‑1 to T0)

• Freeze period starts at [T‑1 hh:mm]; announce to stakeholders.
• Final delta sync; verify no lagging jobs.
• Switch DNS/keys/webhooks; confirm heartbeats/healthchecks green.

Rollback triggers and backout (pre‑agreed)

• Triggers: >[X]% record mismatch; sustained 5xx or 429s >[Y] minutes without recovery; P0 functional test fails.
• Backout steps: Repoint to legacy, replay missed events, unfreeze, schedule post‑mortem.

Post‑cutover (T+1 to T+7)

• Reconciliation report signed by both PMs.
• Observability on: error rates, throughput, and cost anomalies.
• Access clean‑up: remove legacy creds; archive logs.
• Data handback artifacts prepped (if relevant): export, schema docs, deletion cert draft.

Nomad‑proofing

• Offline fallback: scripts runnable from a local container with queued batches.
• Small‑batch replays: Make.com/worker can resume from last checkpoint on unstable Wi‑Fi.
• Runbook snapshot stored where both parties can reach it on low bandwidth (Markdown + plain text).

Quantify real switching costs so you can negotiate on value. Implement this as a simple sheet or calculator. Define inputs, compute totals, and convert to monthly break‑even.

Inputs (fill these)

• Rebuild_Hours = [HOURS]
• Integration_Rework_Hours = [HOURS]
• Training_Hours_By_Role = [{Role: [ROLE], Hours: [HOURS], Loaded_Rate: [$RATE]}]
• PM/Change_Overhead_Hours = [HOURS]
• Blended_Engineering_Rate = [$RATE/hour]
• Opportunity_Cost_Per_Day = [$AMOUNT] (lost focus/slowdown during freeze)
• Freeze_Days = [DAYS]
• Contract_Fees = [$AMOUNT] (termination, export assistance)
• Data_Remediation_Cost = [$AMOUNT] (cleanup, backfills)

Formulas

Engineering_Cost = (Rebuild_Hours + Integration_Rework_Hours) * Blended_Engineering_Rate
Training_Cost = SUM( Role.Hours * Role.Loaded_Rate )
PM_Overhead_Cost = PM/Change_Overhead_Hours * [PM_RATE]
Freeze_Opportunity_Cost = Opportunity_Cost_Per_Day * Freeze_Days
Total_Switching_Cost (TSC) = Engineering_Cost + Training_Cost + PM_Overhead_Cost + Freeze_Opportunity_Cost + Contract_Fees + Data_Remediation_Cost
BreakEven_Months = TSC / Monthly_Value_Delta

Where Monthly_Value_Delta = (Monthly_Benefit_of_Switch − Monthly_Cost_of_Switch). If the delta is negative, don’t switch.

Outputs

• Total_Switching_Cost (one‑time)
• BreakEven_Months
• Negotiation Lens: Your renewal price should be easy to defend if it’s (a) aligned to measurable value and (b) clearly lower than amortizing TSC over a reasonable horizon [H] months: TSC / H.

How to use in negotiation

• Share the categories and your math openly; invite the buyer to adjust inputs.
• If they insist on portability, keep the handback clause—but show the TSC so they plan realistically.
• Use the TSC to justify committed‑use discounts or caps that remove bill‑shock risk.

Offer one or two paths that map to how the buyer consumes value. Keep meters visible, add caps or minimums to de‑risk both sides.

Choose Seat‑based when

• Access is tied to human seats (agent assist, back‑office tools).
• The buyer needs forecastability; compliance requires named users.
• You can show adoption by role and outcomes per seat.

Choose Usage‑based (with caps) when

• The Module’s value scales with events, credits, or API calls.
• Workloads vary by season; buyer fears surprise bills.
• You can expose real‑time meters, soft caps, and committed‑use discounts.

Choose Revenue‑share when

• The Module is tightly coupled to attributable revenue (e.g., upsell engine, paid lead‑gen).
• You have credible attribution rules and access to revenue reporting.
• You set a monthly minimum so you’re not subsidizing outcomes with zero floor.

Guardrails that build trust

• Publish meters and seat rosters to the client admin.
• Add a monthly price ceiling or committed‑use plan.
• Keep the guaranteed data handback no matter the plan.
• Document how you’ll measure value and review annually.

If you’ve got 90 minutes on decent Wi‑Fi, you can get a first draft ready for counsel and your buyer.

0–20 min: Duplicate and fill the Addendum

• Paste Part A into your SOW doc.
• Fill [MODULE NAME], [TERM], [TERRITORY].
• Pick Option A/B/C and set placeholders for prices/caps/minimums.

20–45 min: Build Exhibit B (Background‑IP)

• List every Provider‑owned component with version and license to Client.
• Flag anything you’ll reuse across clients.

45–65 min: Draft the Migration Runbook (Exhibit E)

• Paste Part B. Fill owners, windows, rollback triggers, and checkpoints store.

65–80 min: Wire portability

• Paste the Data Handback clause; choose [DATA_FORMAT], [HANDOFF_WINDOW_DAYS], [DELETE_WINDOW_DAYS].
• Attach your DPA/Data Exchange template as Exhibit D.

80–90 min: Run the calculator

• Create a quick sheet with Part C formulas.
• Populate rough inputs with your team; sanity‑check BreakEven_Months.

Next steps

• Send to counsel for a fast pass.
• Walk the buyer through pricing options and the migration plan with meters/caps highlighted.
• Book a 60‑minute dry‑run date.