Home / Glossary / Tech Change Signal
Signals · the most direct buying intent · deep dive

Tech change signal. The recipient is already in vendor-evaluation mode. You're not interrupting.

A tech change signal fires when a target account adopts, drops, swaps, or consolidates a tool in their stack — and it's the single signal that most directly maps to pipeline for tool vendors. When a company just migrated from Marketo to HubSpot, every HubSpot-adjacent vendor has a 90-day window to land. The buyer isn't being interrupted by your outreach; they're literally inside the evaluation mindset your message taps into. The challenge is detection: tech changes don't announce themselves in a tweet the way funding rounds do. Detecting them requires four complementary layers — JS sniffing, DNS/MX shifts, careers-page mentions, and structured third-party feeds — that together produce coverage no single source provides. This essay covers the four detection layers, the four migration-pattern archetypes (drop / add / swap / consolidate), the operational windows for each, and the structural reason this is the single hardest signal to fake — which is why it's Mama's biggest data moat.

Category: Signals · Read time: 10 min · Updated: 2026-05-24 · TECH-1.0
TL;DR
A tech change signal is a detected change in a company's tech stack — a tool added, dropped, swapped, or consolidated. It's the most direct buying signal in B2B SaaS because the recipient is, by definition, already in vendor-evaluation mode. Four migration patterns each open different windows: drop (a tool removed → urgent need for replacement); add (a new tool deployed → 90-day window for integrations and adjacencies); swap (one tool replaced with another → most pipeline-rich); consolidate (multiple tools collapsed into one platform → opportunity for the consolidation winner). The detection challenge is real: tech changes don't announce themselves the way funding rounds do, so detection requires four complementary layers operating together — JS sniffing (BuiltWith, Wappalyzer), DNS/MX monitoring (for backend tools), careers-page parsing (job listings reveal stacks), and structured third-party feeds (HG Insights, Datanyze, Enlyft). No single source has complete coverage; the serious operator runs all four and dedupes. The opener that works references the specific migration ("now that you're on HubSpot, the data-syncing-to-Salesforce question typically comes up in month 2") rather than the generic "saw you're using HubSpot." And the structural reason this is the single hardest signal type to fake: detecting a tech change requires real-time scraping infrastructure + 5+ year baseline data + dedup logic across 4 sources — a multi-million-dollar engineering investment that purely API-driven competitors can't match. That's why it's Mama's biggest data moat.

01What a tech change signal is

A tech change signal is a detected change in a company's tech stack — something added, dropped, swapped, or consolidated. The signal is uniquely valuable in B2B SaaS because it doesn't just imply buying intent; it captures the buyer at the moment of active vendor evaluation. A company that just adopted Snowflake is, right now, evaluating Snowflake-adjacent tools. A company that just dropped Marketo is, right now, evaluating Marketo replacements. The recipient isn't being interrupted by your outreach; they're already in the mindset your message taps into.

The signal fires at three layers of the stack:

  • Front-end / visible technologies — analytics scripts, marketing pixels, chatbots, CDN providers. Detectable via JS sniffing on the company's website.
  • Back-end / infrastructure — email servers (MX records), DNS providers, hosting infrastructure, security tools. Detectable via DNS/MX monitoring + occasional content analysis.
  • Internal stack — CRMs, sales tools, finance tools, HR systems. Generally invisible from outside the company; inferred from careers-page mentions, integration partner lists, and self-disclosed customer logos.

The detection difficulty scales with depth: front-end is the easiest to detect (the tool's script literally runs in every visitor's browser), back-end is harder (requires DNS analysis + content inference), internal stack is hardest (requires NLP on job posts + customer logo mining). The teams that have all three layers are rare; the value of having them is high.

The reframe
Most signals tell you that a buyer might need something. Tech change signals tell you the buyer is, right now, actively evaluating something. The other major signals (funding, hiring, exec moves) imply downstream buying behavior; tech change signals capture the buyer mid-evaluation. That's why tech-change-anchored outreach consistently outperforms most other categories — the message lands in a moment of decision rather than a moment of contemplation.

02The four migration patterns

"Tech change" is an umbrella; the operational reality is four distinct patterns that imply very different buying motions:

D
Pattern 1 · Highest urgency
Drop
An existing tool removed from the stack without an obvious replacement. Strongest urgency — the team has a now-immediate gap. Common after budget cuts, vendor contract endings, or M&A consolidation.
Window: 14-45 days · the gap is acute and decisions happen fast
A
Pattern 2 · Adjacent opportunity
Add
A new tool deployed without removing existing ones. Opens windows for integrations, complements, and adjacent-category solutions. Less urgent but more strategic — the new tool changes what the buyer wants next.
Window: 60-120 days · the new tool unlocks adjacent needs in months 2-4
S
Pattern 3 · Most pipeline-rich
Swap
One tool replaced with another in the same category. The richest pattern for outbound: the buyer just made a vendor-evaluation decision, knows the comparison landscape, and is now in active mode for adjacent decisions. Often the highest converting.
Window: 30-90 days · the buyer is in active evaluation mode for related tools
C
Pattern 4 · Strategic restructure
Consolidate
Multiple tools collapsed into a single platform. Strategic decision usually driven by procurement or executive mandate. The consolidation winner picks up substantial revenue; everyone else in the displaced category loses their seat.
Window: 6-12 months · slow-rolling decisions but high stakes per decision

The strategic value of segmenting by pattern: each one calls for different messaging and a different decision-maker. Drop signals require urgent "we can fill this gap in 2 weeks" outreach to the operator who just lost their tool. Add signals reward "now that you're on X, the integration question typically comes up" to the buyer who just adopted. Swap signals reward direct competitor-comparison content delivered to the buyer mid-evaluation. Consolidate signals reward strategic C-level outreach about platform vs. point-tool tradeoffs.

03The four detection layers

No single source has complete tech-change coverage. The serious operator runs four complementary detection layers that each catch what the others miss:

L1
JS sniffing
Crawl the target company's website + apps. Parse the loaded JavaScript for known vendor signatures. Catches analytics, marketing pixels, chatbots, CDNs, A/B testing tools, session replay — anything that runs in the browser.
Coverage: front-end
~70% of public sites
L2
DNS / MX monitoring
Track DNS records and MX records for changes. Catches email providers (Google Workspace vs Microsoft 365), CDN providers, DNS providers, and email-security tools. MX record changes are particularly diagnostic — they signal email-platform migrations.
Coverage: infrastructure
Real-time updates
L3
Careers-page parsing
NLP on job descriptions to extract mentioned tools. Catches internal-stack tools that don't appear on the public website — CRMs, marketing automation, BI tools, dev tools. "Experience with Salesforce required" reveals the CRM; "5 years of Looker" reveals the BI tool.
Coverage: internal stack
Highest signal density
L4
Structured third-party feeds
Commercial datasets — BuiltWith, Wappalyzer, HG Insights, Datanyze, Enlyft. Each provider has different coverage strengths. Use for backup detection + historical baseline + structured metadata. The redundancy across providers helps catch each one's gaps.
Coverage: aggregate
$ to $$$ per query

The combined coverage from running all four layers is roughly 85-90% of meaningful tech changes — substantially higher than any single source. The teams running only one or two layers are systematically missing 30-50% of the signals their ICP is producing.

04Why this is Mama's biggest moat

Of all the signal types Mama detects, tech change signals are the single hardest for competitors to replicate. Here's why:

The structural moat
Detecting tech changes requires infrastructure most signal vendors don't build.
Funding signals are trivial to source — Crunchbase has an API; SEC EDGAR is free; PR wires push to RSS. Any vendor can build funding signals in a weekend.

Hiring signals require ATS scraping — non-trivial but mostly an engineering exercise. Vendors who invest the build get there.

Exec move signals require LinkedIn data partner relationships — there are 4-5 viable providers; any vendor can license access.

Tech change signals require something different: real-time JS-sniffing infrastructure crawling millions of websites + DNS monitoring at scale + NLP for careers-page parsing + dedupe across 4 commercial datasets + a 5+ year baseline to detect "change" against. That's a multi-million-dollar, multi-year engineering investment. The vendors that have it (Mama, BuiltWith, HG Insights, Datanyze) are the only ones with credible tech-change data; the vendors that don't can't simply buy their way in.

This is why tech change is Mama's biggest data moat. The other signals are competitive table-stakes; tech change is the category where the infrastructure investment compounds.

05The detect-to-send workflow

The operational pipeline for tech-change-signal outbound:

  1. Multi-layer continuous detection. JS sniffing + DNS/MX monitoring + careers-page NLP + third-party feed reconciliation, running continuously. Detect changes against a baseline of the company's stack 30 days ago.
  2. Pattern classification. Classify each detected change as drop / add / swap / consolidate. Different patterns route to different workflows.
  3. ICP fit + category overlap scoring. Filter to changes that touch categories adjacent to what you sell. A new analytics tool deployment is interesting if you sell BI; it's noise if you sell payroll.
  4. Decision-maker identification. The new tool's owner is usually the recipient — the head of the function that owns the tool category. For ambiguous categories, multi-thread to both the technical owner and the business owner.
  5. Brief generation. 60-second briefing: company, change type, old tool, new tool, days since detection, suggested operational hook, related changes in the same period.
  6. Send within window. Drop signals: 14-day window, send within 5 days. Add signals: 90-day window, send weeks 4-8 (after deployment stabilizes). Swap signals: 60-day window, send within 30 days. Consolidate signals: 6-month strategic engagement, send + nurture.
  7. Track conversion by pattern. Maintain reply-rate and conversion data segmented by pattern type. Most teams find that swap signals produce the highest pipeline; some find drop signals produce the fastest deals.

06The migration-anchored opener

The opener for a tech change signal needs to demonstrate that you actually understand what just happened — not just that you "saw they're using HubSpot." The structural pattern:

  • Reference the specific migration in the second sentence. "Now that you've moved from Marketo to HubSpot, the data-sync-to-Salesforce question typically comes up around month 2-3" is much stronger than "saw you're using HubSpot — wanted to see if you'd like to chat."
  • Name the next-stage problem. Migrations create downstream problems on a predictable timeline. The opener that names the specific problem the new buyer is about to encounter — before they encounter it — feels prescient rather than salesy.
  • Reference comparable migrations. "We've worked with 6 teams that made the same migration in the last year; here's what tended to come up in month 3" leverages social proof + specifics without name-dropping.
  • Don't oversell the data-source. "I saw on BuiltWith that you switched to HubSpot" is unnecessary and faintly creepy. Just reference the migration as if you'd noticed it through ordinary observation.

The best migration-anchored opener feels like a former operator at a peer company reaching out with hard-won knowledge from their own experience — not like a vendor scraping public databases.

07Common mistakes

Mistake 1
Single-source tech-stack data. BuiltWith alone misses 30% of internal-stack tools that only appear in careers pages. Careers-page parsing alone misses front-end tools you can only see by visiting the site. The serious operator runs all four detection layers.
Mistake 2
Treating "current stack" as the signal. Knowing what tools a company uses is table-stakes firmographic data, not a signal. The signal is the change: detection against a baseline. Teams pitching "I see you use Snowflake" when the company has used Snowflake for 4 years are not using a signal; they're spamming.
Mistake 3
Conflating all four migration patterns. A drop is different from a swap is different from a consolidate. Same data layer, completely different motions and windows. Treat them separately or you'll send the wrong message into each one.
Mistake 4
Pitching the new tool's competitor. When a company just adopted HubSpot, the response rate for "you should consider Salesforce instead" is near zero — they just decided. The opportunity is in adjacent categories (HubSpot integrations, Salesforce-data-sync tools, analytics-on-top-of-HubSpot), not in directly contesting the choice they just made.
Mistake 5
Generic "saw you're using X" openers. Doesn't tie back to what changed or what problem the migration creates next. The opener has to demonstrate understanding of the specific migration's downstream consequences, not just acknowledge the tool's existence.
Mistake 6
Acting on stale tech-stack data. If your detection has a 6-month lag, every "they just switched to X" pitch is actually about a switch that happened 6 months ago — by which point the buyer has moved on. Detection latency matters more than detection breadth for migration signals.
Try Mama free

The buyer just changed tools. They're already in evaluation mode for what comes next.

Mama detects tech changes across four complementary layers — JS sniffing, DNS/MX monitoring, careers-page NLP, and structured third-party feeds — classifies each as drop/add/swap/consolidate, and surfaces a migration brief in the right operational window. The buyer doesn't feel interrupted because they're already evaluating; you just got there first.