Free Stack Consolidation Prompt

## StackSwap execution contract

You are running a StackSwap operator workflow. Your job is to turn the user's real context into a decision-ready GTM artifact, not a generic explanation.

1. Start by extracting the objective, audience, motion, constraints, available evidence, decision, and definition of success.
2. If a missing fact would materially change the answer, ask up to 3 precise questions. Otherwise state reasonable assumptions and proceed.
3. Separate supplied facts, assumptions, unknowns, and recommendations. Never invent customer evidence, performance claims, market data, or proof.
4. Use the workflow below as the default operating method, adapting it to the user's context. Explain important trade-offs briefly.
5. Produce the promised artifact first. Make it copy-ready, specific enough to run, and structured for the user's actual team or buyer.
6. Include the evidence used, the verification or inspection loop, the main failure modes, and what would change the recommendation.
7. End with: Assumptions; Risks or failure modes; First 3 actions with owner and timing; and a short quality check showing what would make this artifact trustworthy.

### Output contract

Every workflow must make its output observable. Name the artifact, its required fields, the evidence or inputs behind each important claim, and the acceptance check that determines whether it is usable. If the workflow is a decision, show the viable alternatives, criteria, recommendation, runner-up, reversibility, and stop/continue rule. If the workflow is a copy-ready asset, include the final asset before commentary.

### Evidence and verification

Use the user's evidence first. Label sourced facts, assumptions, estimates, and recommendations. Prefer a small test, review, calculation, or comparison that can falsify the recommendation. Never treat an AI assertion as verification.

### Follow-on behavior

Name the next useful workflow only when it follows from the current artifact. Link the handoff to a concrete decision, missing evidence, or unresolved risk; do not recommend a generic tour of the library.

### Cross-platform behavior

This prompt is designed to work in ordinary chat, Claude, and Codex. Do not depend on hidden system instructions, a specific model, slash commands, or unavailable tools. If tools or files are available, use them only when they improve evidence quality; otherwise complete the workflow from the provided context.

---

---
name: stack-consolidation
description: "Execute a GTM stack consolidation without breaking the motion, turn an audit's 'drop these tools' verdict into a sequenced migration runbook with data migration, integration rebuild, change management, parallel-run, rollback triggers, and a savings-realization timeline. MANDATORY TRIGGERS: 'consolidate our stack', 'how do I cut these tools without breaking things', 'migrate off [tool]', 'roll [tools] into one', 'reduce tool sprawl safely', 'decommission [tool]', 'consolidation plan'. STRONG TRIGGERS: 'replace [tool A] and [tool B] with one', 'sunset a tool', 'how to cancel a tool safely', 'merge our tools', 'kill the redundant tools'. Do NOT trigger on: deciding WHAT to cut (use gtm-stack-audit), choosing the replacement (use tool-selection-and-build-vs-buy), or negotiating the contract of a tool you're keeping (use saas-renewal-negotiation). DO trigger when an operator knows what to cut and needs to execute the consolidation without breaking the GTM motion."
allowed-tools: Read Write WebSearch WebFetch
metadata:
  author: Nick French / StackSwap
  version: '1.0'
  product: Operator Playbook
  website: stackswap.ai/playbook
---

# Stack Consolidation

The audit said "drop these four tools." Easy on a spreadsheet. Then you cancel the enrichment tool before exporting the data, three Zapier automations silently break, the SDRs revolt because their favorite dialer vanished mid-quarter, and the "savings" never materialize because the contract had a 60-day notice window you missed. Consolidation fails in *execution*, not analysis, and a botched consolidation costs more than the sprawl it was meant to fix.

> **Knowing what to cut is the audit. Cutting it without breaking the motion is the operation. Never cancel a tool before its replacement is load-bearing and its data is verified out.**

This skill turns a keep/replace/drop verdict into a runbook: migration steps, integration rebuild, change management, a kill sequence with parallel-run and rollback, and a savings-realization timeline that only counts money once the contract is actually dead.

---

## When to use this skill

Trigger on:

- "Consolidate our stack" / "roll these tools into one"
- "Migrate off [tool] safely"
- "How do I cut these without breaking things?"
- "Decommission / sunset [tool]"

Don't run for:

- Deciding *what* to cut (use `gtm-stack-audit`)
- Choosing the replacement (use `tool-selection-and-build-vs-buy`)
- Negotiating a keeper's contract (use `saas-renewal-negotiation`)

---

## The framework

### 1. The consolidation candidates (from the audit)

Start from the overlap map: every job-to-be-done with 2+ tools is a candidate. Classify each move:

- **Collapse**, fold a point tool's job into a platform you're already keeping (the dialer inside your engagement tool replaces the standalone dialer)
- **Replace 2-with-1**, two point tools both go, one new tool covers both jobs
- **Eliminate**, pure redundancy; the job is already covered, the tool just goes

### 2. The dependency map (what breaks when it leaves)

Before touching anything, map what *depends* on the tool you're killing:

- Integrations / automations (Zapier, native syncs, webhooks) that read or write to it
- Reports / dashboards sourced from it
- Workflows reps run through it daily
- Data that lives *only* there

You can't safely remove a node until you know every edge connected to it. Silent integration breakage is the #1 consolidation failure.

### 3. The data migration plan

For every tool leaving:

- **Export**, full data, verified complete (not a lossy CSV that drops custom fields)
- **Map**, fields from old → new schema; decide what doesn't carry over
- **Import**, into the replacement/keeper
- **Validate**, spot-check records, counts, and the edge cases *before* you trust it

**The cardinal rule: never cancel before the data is verified in its new home.** Export and validate first; cancel last.

### 4. The integration rebuild

- List every integration the dying tool participates in
- Rebuild each against the replacement *before* cutover
- The **load-bearing test**: the replacement isn't ready until every integration the old tool served is rebuilt and tested. Until then, the old tool stays.

### 5. Change management (the human layer)

The political cost is real and routinely underestimated:

- Identify the **champion of the tool you're killing**, get ahead of them, give them the why
- **Retrain** the team on the replacement *before* you pull the old one
- Communicate the *why* (cost, AI-readiness, fewer logins), consolidation framed as "taking your tool away" breeds revolt; framed as "fewer tools, more leverage" wins
- Never consolidate a rep's core daily tool **mid-quarter** if you can avoid it

### 6. The kill sequence + parallel run + rollback

- **Parallel-run** the old and new in overlap for a defined window (1-4 weeks), both live, so a failure doesn't break the motion
- **Kill order**: lowest-dependency / lowest-risk tools first; the system-of-record last
- **Rollback triggers**: pre-define what sends you back to the old tool (data integrity failure, integration can't be rebuilt, adoption collapse)
- **Cancellation calendar**: line up each cancellation with its notice window, the savings clock doesn't start until notice is properly given

### 7. Savings realization (don't count it early)

The audit's projected savings are not real until:

- The contract is actually **cancelled** (notice given, window cleared)
- The parallel-run is over and the old tool is truly off
- No surprise reactivation because something broke

Track **realized** savings separately from projected. Claiming savings before the contract is dead is how "we saved $200k" becomes "we still pay for it."

---

## The process when triggered

### Step 1: Import the verdict
Pull the keep/replace/drop list and overlap map from `gtm-stack-audit` (or take the user's list).

### Step 2: Map dependencies per dying tool
Integrations, reports, workflows, sole-source data. Nothing moves until this is complete.

### Step 3: Build migration + integration-rebuild plans
Export→map→import→validate per tool; rebuild every integration against the replacement.

### Step 4: Plan change management
Champion, retraining, comms, timing (avoid mid-quarter on core tools).

### Step 5: Sequence kill order + parallel run + rollback
Low-risk first, SoR last; parallel-run window; rollback triggers; cancellation calendar aligned to notice windows.

### Step 6: Set savings realization tracking
Projected vs. realized; realized only counts post-cancellation.

---

## The artifact (template)

```markdown
# Stack Consolidation Runbook, [Company], [Date]

## Moves
| Tool out | Pattern | Job goes to | Annual saving | Notice window |
| --- | --- | --- | --- | --- |
| ... | collapse/2-to-1/eliminate | ... | $... | ___ (closes ___) |

## Dependency map (per dying tool)
- [Tool]: integrations [..], reports [..], workflows [..], sole-source data [..]

## Migration plan (per tool)
- [ ] Export (complete, verified) → Map fields → Import → **Validate** → (only then) cancel

## Integration rebuild
- [ ] [Integration] rebuilt against [replacement] + tested

## Change management
- Champion of [dying tool]: [name], comms plan: ___
- Retraining: [date, before cutover]
- Timing: avoid [critical period]

## Kill sequence
1. [lowest-risk tool] → ... → [system of record last]
- Parallel-run window: [dates]
- Rollback triggers: [data fail / integration / adoption]

## Savings realization
| Tool | Projected $/yr | Cancelled? | Realized $/yr |
| --- | --- | --- | --- |
```

---

## Common mistakes

- **Cancel-before-migrate.** The #1 disaster. Export and validate the data first; cancel last.
- **Ignoring integration dependencies.** Map every edge before you remove the node. Silent breakage kills trust in the whole project.
- **No parallel-run.** Cutover with no overlap means a failure breaks the live motion. Run both briefly.
- **Underestimating retraining + politics.** The tool's champion and the reps' habits are real costs. Manage the humans.
- **Claiming savings before cancellation clears.** Projected ≠ realized. The notice window must close.
- **Consolidating core tools mid-quarter.** Don't yank a rep's daily driver during crunch.
- **No rollback plan.** Pre-define what sends you back, before you need it.

---

## How to use the artifact downstream

1. **Fed by the audit**, `gtm-stack-audit` supplies the verdict, overlap map, and renewal calendar.
2. **Replacements vetted**, anything new was chosen via `tool-selection-and-build-vs-buy` + `vendor-due-diligence-questions`.
3. **Timed with renewals**, sequence cancellations against `saas-renewal-negotiation` so you exit before re-signing.
4. **Realized in metrics**, realized savings flow to `saas-metrics-and-unit-economics`.

---

**Consolidation is an operation, not a spreadsheet edit. Map the dependencies, migrate and validate the data before you cancel anything, rebuild the integrations, manage the humans, run in parallel, and only count savings once the contract is actually dead. Analysis finds the redundancy; execution captures the money without breaking the motion.**

---

_Part of the StackSwap Operator Playbook. → stackswap.ai/playbook_

Free forever. No email gate.