Hey Trailblazers ๐
Heads up: Standard-Volume Platform Events (SVPE) will be retired in Winter '27. If you've been
waiting for an easier path onto High-Volume Platform Events (HVPE), the new SVPEโHVPE migration
tool is now available in preview sandboxes โ and your migration clock has officially started.
The tool automates the heavy lifting of migrating your event definitions, Trigger and Flow
subscribers, and downstream integrations from SVPE to HVPE โ minimizing rework for both customers
and AppExchange partners.
โฐ This tool is the supported path off SVPE before retirement.
Why HVPE?
- Longer event retention
- More generous daily allocations and better scaling headroom
- The forward path for event-driven architecture on the platform
Where things stand:
- โ Available now in your Preview (Pre-release) Sandbox
- ๐ Generally Available with the Summer '26 release (production rollout starts ~June 15, 2026)
- ๐ SVPE retires in Winter '27 โ plan your migration accordingly
What I'm asking of you:
1. Try it now in your preview sandbox โ don't wait for GA.
2. Tell us what worked and what didn't โ especially edge cases, weird subscribers, or anything
else. All feedback is wanted.
3. ISV/Partner builders โ Once you run it, your events will be updated, so you'll need to publish
a new package version for your downstream customers. Please run it against your managed packages
and share what you find, partner feedback is especially valuable here.
๐ฌ Reply in this thread with questions, findings, or issues โ I'll be watching and responding
personally.
Thanks for testing this @Charles Troster
and good eye on the Audit Trail entries. The two "Added Platform Event Migration" rows + the completion email is exactly the expected flow.
On the global-vs-per-event question: that was a conscious design decision, not an oversight. We need to get this migration done across the fleet, and there will be no extensions, so in the spirit of an actual "easy button," a single org-level action was the simplest, lowest-friction path to full completion. A per-event UI would have let orgs partially migrate and stall indefinitely, which is the opposite of what we need here.
On the ISV concern, you're right that there's a theoretical overlap where a managed-package author also ships a migration in an upgrade. We weighed that and landed on "get it done" over "preserve every partial-migration permutation," because the cost of orgs sitting half-migrated (and us chasing them) is far higher than the edge case of an admin migrating an event an ISV would have handled.