We used the following workaround to migrate saved postfunction configurations during the GDPR API switch of 2019.
When a postfunction is triggered, Atlassian send the configuration that app vendors provide via the synchronous JS API in the webhook. We took a hash of that config, modified it and stored the new, GDPR compliant config in our systems, and did work using the new modified config. Every time we received a webhooks with a configuration payload that matched a hash we already had, we used the modified payload we stored. Every time a customer viewed the edit page for the workflow postfunction, we checked if we were storing a modified version of their configuration and presented that to customers instead.
It didn’t cover cases where postfunctions were created, only those which actually got triggered.
Another workaround we haven’t tried it to rely on the behaviour that when a postfunction is saved, the next screen that the customer sees lists out all the postfunctions, so app vendors should get an HTTP request to render a description of the postfunction, allowing us to see the configuration that was saved and do something with it. However, this may not work if the customer navigates away from that page before all the iframes have successfully loaded.