Is it possible to transfer web push subscriptions to a different domain / web push service?
Migrate to another domain
No, it’s not possible, because web push subscriptions (endpoints) and service worker registrations are bound to the domain. So when you use an endpoint, it will always try to activate the service worker that has generated it (and the service worker is associated to a path / domain).
You best chance is to keep the service worker on the original domain for some time so that you can continue to use the old subscriptions. Meanwhile you start collecting new subscriptions on the new domain (you can even use the old VAPID key pair).
Migrate to a different web push service
The last trend for authentication in web push is VAPID. This means that in order to send web push notifications to a client you need:
- the browser endpoint
- the VAPID key pair associated to that endpoint (you can associate a key to an endpoint when you generate it with Javascript)
If you have that information, then you can definitely migrate to another push service. For example at Pushpad we support data portability: this means that you can always export your endpoint and VAPID key pairs from Pushpad. Also, if you like to import data from another service to Pushpad we can help.
Another thing to consider is that different web push services use different service workers. Currently the update of the service worker may take some time to propagate and clients with the old service worker may see some errors in the meantime (for example a notification saying “The website has refreshed in background”).
Finally, different web push services may use different strategies, not always compatible, to deliver the notification payload:
- some web push services deliver the payload to the client through FCM, Mozilla autopush, etc.
- other web push services (e.g. Pushpad) only deliver a signal to the client through FCM, Mozilla autopush, etc. Then the client creates a new connection (in the service worker callback) to fetch the unread notifications from the web push service (e.g. Pushpad)
This means that if you decide to migrate from a service of the second kind to a service of the first kind you may need to collect additional key pairs from the client in order to encrypt the payload: you can collect them when the user surf your website for example.
Last but not least, there isn’t any standard for porting metadata associated to the endpoints (e.g. tags) from a service to another.