The four signals, and what each is good for
Each answers a different question and has a different blind spot.
- Job postings. The strongest signal for internal systems, because a company must name the stack to hire for it. Blind to anything they are not hiring for.
- Public code and dependencies. Precise for what they build openly. Blind to everything private.
- Documentation and integration pages. Good for anything customer-facing, and often the earliest public trace of a partnership.
- Vendor and DNS records. Good for infrastructure-level services, blind to internal tooling.
Change needs a baseline
None of these signals mean anything as a snapshot. A list of what a company uses today is mildly useful for qualification; a diff against last quarter is what tells you a migration started.
That means the first collection is not the deliverable. It is the baseline, and the value begins with the second one. Any tool that offers a one-off technology lookup is giving you the least useful half.
Reading a migration correctly
A real migration shows a pattern: roles naming the new technology appear, roles naming the old one stop, the documentation gains pages for the new one, and the engineering blog eventually explains it. A single posting mentioning a technology as nice to have is not a migration and should not be sold to as one.
The honest summary of one detection is: this company mentioned X in a posting dated this day. That is checkable and it is enough.
What this is genuinely useful for
Qualification, timing and displacement. Qualification because a stack tells you whether you fit. Timing because a migration creates budget and urgency. Displacement because a company that just adopted a competing product is a poor prospect this year and a reasonable one in two.