The cold email after a tech stack change.

What "tech stack change" actually means.

Tech-stack changes are the most leak-y signal in B2B because the artifacts of a swap live in places marketers can't suppress: the page source, the DNS, the security headers, the engineering job descriptions, the changelog. If a company moved from Mixpanel to PostHog, half a dozen public surfaces tell you within a week.

But "tech stack change" the marketing term and "tech stack change" the useful signal are two different things. Most stack-change databases include every JS library upgrade — that's not what we mean. The useful signal is an operational software change: a swap that costs the buying team something to make, that they had to get approval for, that someone now owns internally. A new auth provider counts. A jQuery point-release does not.

The three sub-types worth chasing

• Swaps — replaced Tool A with Tool B (e.g. moved from Salesforce to HubSpot, from Segment to RudderStack). These are the highest-yield because the buyer just lived through a migration and remembers exactly what they wished was different.
• Additions — added a new category where one didn't exist (e.g. first analytics tool, first CDP, first observability stack). These signal a maturity step — the team has decided this category matters now.
• Removals — quietly retired a tool without a replacement. Often the most overlooked. Signals either budget pressure or that the team realized the tool wasn't earning its line item. Both are openings for a cheaper, leaner, or better-fit option.

Which changes are worth chasing.

Not every detected stack change is equally interesting. We score them on two axes: how recently the change happened and how operationally costly the change was to the buyer. The intersection determines whether to open on the signal or just file it.

The "sales window" is roughly how long the buying memory stays warm — after that, the migration is old news and the opener will land cold. Reply uplift is the multiplier we see vs. a control opener (the generic "I noticed you ___" template) sent to the same ICP without the signal anchor. The numbers are from our own outbound corpus and three customer corpuses they let us aggregate anonymously.

Why most of these openers fail.

Open the inbox of any VP Engineering or RevOps lead at a company that just swapped a major tool. Count the cold emails referencing the swap. Most weeks, they get more than ten. The signal is high; the field is crowded.

Which means the bar for being read is no longer "did you spot the swap" — every tool with a BuiltWith scrape spotted it. The bar is now did you say something the other ten didn't. The four failure modes we see most:

• Generic "I saw you switched to X" with no observation about X specifically. Says nothing the buyer doesn't already know. Reads like a script.
• Pitch in the same sentence as the observation. "I saw you moved to PostHog — we help with PostHog analytics rollout!" — collapses the gap between noticing and selling. Buyer's brain treats it as a single ad unit.
• Worship the swap. "Smart move adopting WorkOS, they're killing it!" — flattery of the tool, not engagement with the buyer's actual choice. Reads as junior or sycophantic.
• Old swap, hot opener. Buyer migrated 11 months ago. The note treats it as fresh news. The signal is real, the timing is dead.

The 4-line frame.

The structural skeleton we recommend, refined across roughly 300 outbound campaigns. Same 4 lines for every stack-change opener regardless of sub-type. The variables that change are what specifically you observed and the consequence-question in line 3.

Three structural rules that hold across every variant of this frame:

• Lines 1 and 2 contain zero pitch. The pitch sits in line 3 as a question, never as a claim. If a reader stops after line 2, they should still have learned something.
• Length is fixed at ~55 words. Longer emails get scanned, not read. Shorter ones look like template injection. 55 is the floor where credibility lives.
• The consequence-question is the single most important line. If you only have 30 minutes to write the email, spend 25 of them on line 3.

Three worked examples.

Same frame, three different stack-change types, three different ICPs. Reply rates listed are the actual outcomes — these are anonymized from customer corpuses, with permission, names and identifying companies changed but the patterns intact.

Example 1 · Identity / auth swap (Series B, ~ 80 engineers)

Example 2 · Analytics swap (Series A, ~ 35 engineers)

Example 3 · CRM swap (Series A, ~ 12 SDRs)

The receipts test.

This is the single discipline that separates working stack-change outbound from the cold-merge variant. Every email we send through the frame above goes through a final pre-send check: is there one detail in line 1 that couldn't have come from a list? If no, the email goes back for a rewrite, not to the send queue.

When not to use this play.

Stack-change opens are powerful, which means they're easy to over-rely on. Three situations where this play is the wrong choice:

• The buyer's role doesn't touch the stack. Don't email a CFO about a database swap. The signal might be real, but it's not their decision context — the email reads as misaligned.
• The swap is older than your sales window. A migration completed 9 months ago is institutional memory, not active pain. The reply rate drops to baseline cold within roughly the windows in the matrix above.
• Your product solves a problem on the OLD tool. If they just left the thing you'd solve their problem on, you're showing up too late. The exception is if you specifically help with the migration itself or with the missing-feature gap in the new tool.

Related playbooks.

This playbook works in a system, not alone. The four playbooks below sit next to this one in the library — three are live, the rest are in the publishing queue.