1. assuming a running process pA on nodeA, registered in a cluster-level process registry by name N;
2. send the process pA's state to a function on node B, which will use it to start a process pB on node B that is a clone of pA;
3. update the cluster-level process registry to point N at pB.
4. if you want to be really clever — tail-call (or code-upgrade) pA out of its existing loop, into code that makes pA act as a proxy for pB, so that anything sending a message to pA ends up talking to pB through pA.
But this isn't "sending a process"; pA itself remains "stuck" on nodeA (node IDs are actually embedded in PIDs!), and there's especially no native mechanism that would do things like rewrite the links/monitors on other processes that currently point to pA, to instead point to pB (so if pA was a supervisor, you couldn't "re-parent" the children of pA over to pB.)
The closest you could get to this would be:
1. assuming a running process pA on nodeA, registered in a cluster-level process registry by name N;
2. send the process pA's state to a function on node B, which will use it to start a process pB on node B that is a clone of pA;
3. update the cluster-level process registry to point N at pB.
4. if you want to be really clever — tail-call (or code-upgrade) pA out of its existing loop, into code that makes pA act as a proxy for pB, so that anything sending a message to pA ends up talking to pB through pA.
But this isn't "sending a process"; pA itself remains "stuck" on nodeA (node IDs are actually embedded in PIDs!), and there's especially no native mechanism that would do things like rewrite the links/monitors on other processes that currently point to pA, to instead point to pB (so if pA was a supervisor, you couldn't "re-parent" the children of pA over to pB.)