Starting a process instance Camunda 7 proect ( to keep it compliant for potential migration to C8 later )

Hi there,

we are working a C7 project atm which we plan to migrate to C8 later. does anyone see any challenge in if we use standard C7 java api -
runtimeService.startProcessInstanceByKey to start the process instance ??

or should we use C7 rest api to start process instance, the goal is to keep it compliant / minimal possible refactoring when we migrate to C8.

Kindly advise.


Hi @Pramod_Yadav,

In C8, every command will be sent via the API. However, if you use a client library, such as Spring-Zeebe, the actual API call is taken care of. The command is similar to the one in C7. In other words, I think it is completely fine to use the java API for starting process instances.
It would be even better for migration, if you migrate everything to external task workers.
I also recommend having a look at the following blog posts (if you have not already):

Thanks Stephen, few things -

  1. should we use Camunda rest api or we shouldn’t ? I have noticed in C8 rest apis are only for operate to fetch historical data.
  2. Yes we are using external workers (ava based) for service tasks, but how can we leverage that for starting a process instance ? Workers would pick the topics only after process instance is started ??
  3. If we use runtimeService.startProcessInstanceByKey now in C7 and later use spring zeebee clienrt, do you think this is best optimal solution or should we adjust anything ??..we would be using java now and later as well.



  1. The external task clients only communicate via the REST API to C7. In C8, gRPC is used instead of REST. For both versions exist client libraries, which hide the actual protocol from you. For C7, we recommend using the remote engine architecture; thus, we recommend using the REST API.
  2. I see, this means you embedded C7 into another part of your application and start the process from there? In my opinion, it does not really matter. However, if you follow our recommendation, and you go fully remote (i.e., using Camunda Run), the REST API is your only option.
  3. No, there are no changes necessary at this point. The Java API will change, so you have to refactor, but the same is true for the API.

we are not (won’t be) using camunda run atm, we have few ava spring boot based microservices and one of these misroservices has camunda engine embedded within spring boot app.
This ms hosting engine writes custom endpoints and exposes these to other misroservices and also to frontend (written in react), one of these custom endpoints is /startWorkflow and the implementation of this endpoint is what I have been talking about. So inside the implementation of this custom endpoint which starts process instance we are equally good to use either camunda rest api or camunda java api ??

Both of these would require refactoring when we mibgrate to C8 ? which would be less painful to migrate at a later point ?

as we are using spromg boot external task clinets now in c7 and would be using spring zeebee clients in C8…do you think dircetly using Camunda rest api inside the implementation of this custom endpoint /startWorkflow has any advantage instead of using runtimeService.startProcessInstanceByKey ??


Thanks for the additional information. Since you’re using an embedded engine, I’d use the Java API to start a process instance. There is no advantage in using the REST API.
Yes, both requires refactoring (the API changes and the client library changes). The efforts will be smaller with the Java API, since it is less code that you need to change. Let me briefly summarize what would be necessary:

  • Add a Zeebe client to your Spring Boot application
  • Configure the connection to the Zeebe engine
  • Replace the call to C7’s java API with a call to the Zeebe client

As a side note: C8 only support the remote engine architecture.

perfect, many thanks Stephen. highly appreciated!