Elixir uses macros to generate some of the infrastructure that you need to use. This can result in modules that consist of a simple use macro and maybe one function. These modules are far more useful if you add some documentation about how it is to be used. Don’t just copy the generic parts, but mention the concrete use cases that you have.

I have been working on how to correct an identifier sent to a third party.
Their API does not have a rename option so I have to cancel the old version and create a new entry.

This is made more difficult because we had calculated the old identifier and not stored what we sent. In addition our system uses k8s so there could be multiple versions of the same application running at the same time. This also adds the wrinkle that a failed deploy would be rolled back.

The solution that I used was a fixed cutover date in the near future. This meant that before that date the old approach was used. After that date on the first change an upgrade was applied and for new and upgraded it would use the new correct identifier.

This does involve having code that can be removed at various points.
The pre code can be removed as soon as we know we are not rolling back.

The upgrade code will have to live for a year (the lifetime of the value in the third party service).

This gives an interesting option when structuring the code: plan for deletion. It is worth living with slightly more duplication than is normal so that the deletion can become much cleaner.