I haven’t worked on erleans in a while (the company I developed it at is no more) but would like to again and to create an Elixir example or interface if it makes sense to offer some nicer abstractions when using in Elixir. And I suppose an ecto hookup for persistence would be good to do.

So it isn’t production ready but happy to help if anyone tries it out.

You might want to check out erleans and/or horde.

In migrating there are 3 things you need to consider:

1. process state
2. process registered name aka how do other processes still contact it
3. messages in queue

Process state
You can place the state into a struct or map and have the new SM start_link with this state this would solve this issue.

Registered name
Either use global or have an internal name/process resolver to ensure current processes can still access the migrated SM.

Message in queue
This is a bit trickier. Before migrating you will have to dequeue the messages into a list and provide it to the new SM.

This is a common trick to always dequeue messages into an ets table and process off the table. This trick is typically uses for high transaction processes or for message reordering.

I wouldn’t use mnesia for distribution unless you have a very controlled environment (i.e. not the cloud).

Mnesia just was not built for such an environment where instances and the network are coming and going. I’m sure someone who has had the fun of attempting this would have better details than I can provide. The best I can do is link to Jesper’s post about it https://medium.com/@jlouis666/mnesia-and-cap-d2673a92850 which has some of the history behind Mnesia.

There are libraries to improve the situation, like Ulf’s unsplit which he discusses in this erlang-questions thread http://erlang.org/pipermail/erlang-questions/2010-February/049213.html