If you don't depend on clustering, the migration is very easy with a package change then.

hi @travissarles I just went through this myself with ~20 services in a monorepo with loads of shared sbt projects between them as well as roughly the same number of internal libraries hosted in another repo. the method i used was what my sensei would call "brutal duplication for total domination"

otherwise known as the bottom up approach. in a nutshell:

• start with the internal libraries. we knew that both would not be on the same classpath, so we just duplicated each library that had akka dependencies, updated the import statements, updated any akka-specific config, and published the artifacts under a different name. therefore both versions had the same package structure.
• for the shared sbt projects, also duplicated, replaced the akka dependencies as well as internal lib dependencies, updated the import statements and akka-specific config

all the leaves and shared branches of the dependency graph being duplicated, we were in a position to migrate each application one at a time--no application had both akka and pekko dependencies. yes, it meant for a period of time we were careful in PR reviews to make sure changes were replicated in duplicate projects, but the migration took less than a week. since we tag our docker images with the commit sha, rollback would have been easy but never happened.

we experienced two minor difficulties:

• running hybrid akka/pekko clusters: did not work initially but the team here was super helpful with the investigation, even fixed some code in the cluster formation protocol (this hybrid feature is unique to pekko). in the process i even went into what my sensei would call "complete yolo mode of the end of the universe" and moved from classic remote, which we were still using, to artery.
• for better or worse, we use swagger annotations in our http apis. we had to update all of them to the v3 annotations. luckily, this an agent can easily do today with minimum oversight.

it's been four months since, no issues reported

hi @travissarles I just went through this myself with ~20 services in a monorepo with loads of shared sbt projects between them as well as roughly the same number of internal libraries hosted in another repo. the method i used was what my sensei would call "brutal duplication for total domination"

otherwise known as the bottom up approach. in a nutshell:

• start with the internal libraries. we knew that both would not be on the same classpath, so we just duplicated each library that had akka dependencies, updated the import statements, updated any akka-specific config, and published the artifacts under a different name. therefore both versions had the same package structure.

• for the shared sbt projects, also duplicated, replaced the akka dependencies as well as internal lib dependencies, updated the import statements and akka-specific config

all the leaves and shared branches of the dependency graph being duplicated, we were in a position to migrate each application one at a time--no application had both akka and pekko dependencies. yes, it meant for a period of time we were careful in PR reviews to make sure changes were replicated in duplicate projects, but the migration took less than a week. since we tag our docker images with the commit sha, rollback would have been easy but never happened.

we experienced two minor difficulties:

• running hybrid akka/pekko clusters: did not work initially but the team here was super helpful with the investigation, even fixed some code in the cluster formation protocol (this hybrid feature is unique to pekko). in the process i even went into what my sensei would call "complete yolo mode of the end of the universe" and moved from classic remote, which we were still using, to artery.

• for better or worse, we use swagger annotations in our http apis. we had to update all of them to the v3 annotations. luckily, this an agent can easily do today with minimum oversight.

it's been four months since, no issues reported

Also an interesting approach. I think with our setup it would be difficult to manually keep changes in sync over a few months. If we did it in a week, like you did, that could work.

We have migrated to Pekko for some important scenarios. We mainly use Pekko streams and actors, such as live streaming, translation, proxying, and MCP server, and have not encountered any problems.

We are using pekko with Java and Java 21.