We have a requirement to migrate existing customers from one region to another within our platform (of which temporal is a part). Each region represents a separate temporal cluster.
For this, we would like to be able to move both workflow history and running workflows (we have long-running workflows [weeks or more]) over to a different cluster.
I know there is no built-in support for migrating the history, but I would like to know if it’s even feasible to do this: if we were able to identify the workflow runs in question in Cassandra, dump them out on one cluster, and load them into the other.
I’m really just trying to find out if this is a crazy idea that we shouldn’t even attempt, or it’s something that could be possible with some research and effort.
Any input is appreciated. Thanks!
One feasible option would be to use Temporal replication. For this you need to be able to connect the two clusters as per Self-hosted Multi-Cluster Replication | Temporal Platform Documentation
Provided you can do that, there are then workflows in the temporal workers which would allow you to replicate/migrate completed as well as running workflows. See for example the force replication workflow .
The replication docs are lacking, so setting things up can be tricky and it will also depend on your environment (can you for example create the required mTLS certificates to make replication work). It is doable though.
Hope this helps 
Hi @hferentschik , thanks for the input!
I’m actually setting up multi-cluster replication to boost our HA story, and yes, it’s been tricky to get the configuration set up properly.
One question I have, though, is if I add a completely separate cluster as a remote cluster, won’t that start replicating everything new from the current cluster over to the other one? I definitely don’t want that, and want to ensure I lift and shift only those workflows that are completed/running for a specific set of search criteria.
I’m actually setting up multi-cluster replication to boost our HA story, and yes, it’s been tricky to get the configuration set up properly.
There are several bit falls indeed, but if you get it to work, I think this is the way to go.
One question I have, though, is if I add a completely separate cluster as a remote cluster, won’t that start replicating everything new from the current cluster over to the other one?
No. There are two steps involved here. One is to connect the two or more clusters. This basically just means that they “can” replicate namespaces between each other. It also means that each cluster has and needs to have its own initial unique failover version. Clusters can be connected without anything being replicated.
Once they are connected you can selectively replicate namespaces.
I definitely don’t want that, and want to ensure I lift and shift only those workflows that are completed/running for a specific set of search criteria.
Are we talking about a single namespace or mutliplen? For completed workflows you can use a query to force replication selectively. See the workflow I mentioned above. For new/running workflows everything will be replicated for a given single namespace.
It depends a bit on our concrete setup/usecase.
–Hardy
Thanks for the response again, @hferentschik
Yea, the main issue is that I only want to replicate a subset of the workflows in a particular namespace, based on some search attributes.
It seems like this may not be flexible enough to allow for that, since replication is done at the namespace level. I can see how the force replication works, which likely will become useful for us, but maybe not in this case.
Any other ideas, or perhaps another secret functionality of replication I’m not aware of that could help? 
Yea, the main issue is that I only want to replicate a subset of the workflows in a particular namespace, based on some search attributes.
Got you. I don’t think that’s possible.
It seems like this may not be flexible enough to allow for that, since replication is done at the namespace level.
Right.
I can see how the force replication works, which likely will become useful for us, but maybe not in this case.
It would solve your replication of closed workflows, since it allows you to specify a query. You also need it to replicate long running workflows for the first time. A workflow can be “dormant” for a long time. Even if it is running, replication won’t pick it up until there is some sort of progress. So unless you start replication from the beginning, you probably always want to kick off things with a force replication run.
Any other ideas, or perhaps another secret functionality of replication I’m not aware of that could help
Not really. 