Standard Volume Platform Events Retire on 15 December 2026: Two Migration Paths, and Only One Lets You Phase It

TL;DR

• 15 December 2026 is end of life. After that date you can neither publish nor subscribe to a standard volume platform event.
• These have been deprecated since Spring '19. Since then you have not been able to create new ones, and Salesforce states plainly that support cases on them are rejected as not supported.
• Winter '27 adds a Setup button that migrates every standard volume event in your org in one step. That is the option the release note describes.
• There is a second option the release note does not mention. PlatformEventMigration, a Metadata API type available since Summer '26, migrates events one at a time.
• The distinction matters more than it sounds. During a migration, publishes do not work and you cannot create triggers or flows, and while it usually takes about 15 minutes per event it can run up to 24 hours.

What You'll Learn

• Why the all-at-once button is the wrong tool for a large event estate
• The quiesce sequence Salesforce documents, including the 72 hour fallback
• How to find out in one query whether you have any standard volume events left
• What "deprecated since Spring '19" means for a support case you might raise today

The Problem

Standard volume platform events are the older of the two platform event types, and Salesforce stopped taking them seriously a long time ago. They were deprecated in Spring '19. You have not been able to define a new one since. Any platform event you create today is high volume by default, and has been for years.

What makes the deprecation unusual is how explicit Salesforce has been about the support position in the interim. From the retirement article: you can continue to publish and subscribe to existing standard volume events, but if you encounter issues, Salesforce will not address them and cases will be rejected as not supported. There are no troubleshooting steps and no bug fixes.

So an org still running standard volume events has been operating an unsupported integration path for seven years, probably without knowing it, because nothing breaks and nothing warns you. That is the quiet part of this retirement. The loud part is the date.

On 15 December 2026 the events stop working in both directions. Publishing fails and subscribing fails, which means any integration still depending on them fails with it.

Common questions this article answers:

• How do I find out whether we still have any standard volume events?
• Can I migrate one event at a time instead of all of them?
• What does the migration actually do to my publishers and subscribers while it runs?

Quick Answer

Standard volume platform events reach end of life on 15 December 2026, after which publishing and subscribing both stop working. Salesforce offers two tools. The self-service migration button, on the Platform Events page in Setup and available in Winter '27, converts every standard volume event in the org to high volume in one step. The PlatformEventMigration Metadata API type, available since Summer '26, migrates events individually and is the option to use if you cannot take a single outage across your whole event estate. Migration usually takes about 15 minutes per event but can run up to 24 hours, and while it runs, publishes do not work and you cannot create new triggers or flows. Before migrating, stop all publish activity and let subscribers, including triggers and flows, finish processing. Salesforce's documented fallback if you cannot drain the backlog through your own business logic is to wait 72 hours after stopping publishing so the remaining events expire.

Find out whether this applies to you

Most orgs will have nothing to do here, because anything created since Spring '19 is high volume. Confirming that costs one query.

Standard volume and high volume events are distinguishable by their suffix in the metadata. High volume events use __e, and the event definition carries a publish behaviour and an event type you can read:

sf data query --use-tooling-api \
  --query "SELECT QualifiedApiName, EventType, PublishBehavior FROM EntityDefinition WHERE IsCustomizable = true AND QualifiedApiName LIKE '%__e'" \
  --target-org yourorg

The Platform Events page in Setup is the more reliable answer, because it is also where the migration button lives and where Salesforce will show you the two categories as it understands them. Check there before you plan anything, and check production, not a sandbox, since a recently refreshed one may not reflect what production actually carries.

If the answer is that you have none, you are finished. Note the date and move on.

The two tools, and why the difference matters

The release note describes one option. The retirement article describes two, and the second one is the interesting one.

Option 1: the Setup button. On the Platform Events page, one click migrates all of your standard volume events to high volume. Salesforce emails you as each one completes. It is the recommended option in their own documentation and it is genuinely the right choice for an org with one or two events.

Option 2: PlatformEventMigration via the Metadata API. Available since Summer '26, so it predates the button by a release. It migrates each event separately, which means you script it, sequence it, and run it against one event at a time.

Now put that against the operational behaviour. While a migration runs, publishes do not work and you cannot create new triggers or flows. It usually takes about 15 minutes per event, but Salesforce documents that it can run up to 24 hours in rare circumstances.

For an org with twelve standard volume events, the button means starting twelve migrations and accepting that your event pipeline is degraded until the slowest one finishes, with a worst case measured in a day. The Metadata API means twelve scheduled changes, each with a blast radius of one event, each of which you can put in a maintenance window that suits the integrations depending on it.

That is the decision, and the release note does not put you in a position to make it.

The quiesce sequence is the actual work

Clicking the button is not the project. Getting to the point where clicking it is safe is the project.

Salesforce's instruction is to ensure all publish activity has stopped and all subscribers, including triggers and flows, are done processing. Both halves of that are harder than they read.

Stopping publish activity means finding every publisher. Apex, Flows and Process Builder are the easy ones because they are in your metadata. External systems publishing through the API are the ones that catch people, because they are somebody else's deployment on somebody else's change schedule.

Draining subscribers means the backlog is empty, not that the subscribers are switched off. An event sitting in the stream unprocessed at migration time is an event you may lose.

Salesforce documents the fallback for when you cannot guarantee the drain through your own business logic, and it reads as a planning input more than an edge case: wait 72 hours after stopping your event publishing to let all standard volume events expire. That turns a fifteen minute migration into a three day change window, and it is the realistic path for anyone who cannot prove their subscribers are current.

If you are recreating events from scratch instead of migrating, the same article gives the full sequence: create the equivalent high volume event, stop publishing, process the remainder or wait it out, deactivate the standard volume subscriptions and delete the related artefacts, then start the high volume publish and subscribe path.

What changes after the migration

The event is high volume, which is the current and only supported type, and the platform behaviour follows that type, not the old one.

Two things worth testing instead of assuming. Anything that reads the event definition or its API name in code or configuration should be checked, because the migration changes the event's type and you want to know whether your automation cared. And any subscriber built with assumptions about delivery timing deserves a run under realistic volume, since the whole reason two types existed was different volume characteristics.

This is also the moment to look at delivery allocations, because a migration is when someone is already paying attention to the event pipeline. The related work is in Salesforce Platform Event Delivery Limits and Reducing platform event delivery costs.

Frequently Asked Questions

Q: We have never touched platform events. Do we need to care?

A: Almost certainly not, but confirm rather than assume, because platform events arrive in orgs through managed packages as well as through your own build. Check the Platform Events page in Setup for anything you did not create. That is a two minute check and it is the only way to be sure.

Q: Why is there a Metadata API option nobody mentions?

A: It shipped in Summer '26, a release before the button, and the Winter '27 release note describes the button because the button is what is new. The Metadata API type is documented in the retirement knowledge article instead. That is a reasonable place for it and a bad place to find it, which is why most coverage of this retirement will describe one option.

Q: What actually happens on 15 December 2026 if we do nothing?

A: Publishing and subscribing both stop for standard volume events. The failure is not subtle and it is not gradual. Any integration depending on those events stops working, and because these have been unsupported since Spring '19, a support case at that point is unlikely to help you.

Q: Can we migrate in a sandbox first?

A: You should, and be deliberate about which sandbox. A full or partial copy sandbox with realistic subscriber configuration will tell you something about timing. A developer sandbox will tell you the mechanics work and nothing about how long the drain takes in production, which is the part that governs your change window.

Q: Is 24 hours a realistic worst case or a lawyerly one?

A: Salesforce documents it as rare, and 15 minutes as typical. Plan the window for the documented worst case anyway, because the cost of assuming 15 minutes and getting an outlier is an unplanned outage on a pipeline you have already stopped publishing to. This is exactly the situation the per-event Metadata API route exists for.

Key Takeaways

• 15 December 2026 is a hard stop. Publishing and subscribing both fail after it.
• These have been unsupported since Spring '19, so support cases on them are already being rejected.
• The Setup button migrates every event at once. For more than a couple of events, that is one large unpredictable window.
• PlatformEventMigration in the Metadata API migrates one event at a time and has been available since Summer '26. It is the tool for a phased migration and the release note does not mention it.
• The quiesce is the project, and Salesforce's own fallback if you cannot drain subscribers is to wait 72 hours, which reshapes the change window entirely.

What's Next?

Open the Platform Events page in production and find out whether you have any standard volume events at all. Most orgs will not, and that ends the exercise.

If you do, count them. One or two is a button and a maintenance window. More than that, and the per-event Metadata API route is worth the scripting effort, because it converts one unpredictable outage into a series of small ones you control.

Then find your publishers, including the ones outside Salesforce, since those set the timeline rather than anything on the platform.

For the wider event pipeline work this is a good moment to pick up, see Salesforce Platform Event Delivery Limits. For the rest of what Winter '27 carries, see Salesforce Winter '27 Security Readiness.

Resources & References

• Salesforce Knowledge Article 002280033, Standard-Volume Platform Events Retirement, which carries both migration options and the manual sequence. Originally published July 2024 and updated August 2026.
• Salesforce Winter '27 Release Notes, Platform Events, for the Setup migration button.
• PlatformEventMigration in the Metadata API Developer Guide, for the per-event route.
• Salesforce Platform Event Delivery Limits and Reducing platform event delivery costs for the allocation work worth doing while you are in here.