Camunda 7 to 8 Migration, with Bernd Ruecker

Earlier this year, Camunda Platform 8 was launched as the universal process orchestrator.  In this month’s episode, I talk with Bernd Ruecker, co-founder and chief technologist of Camunda, about migrating to Camunda 8 from Camunda 7. We cover when it makes sense to do it, how to do it, and what to do if you can’t do it right now.

Whether you have a production system running on Camunda 7, are currently developing a system on Camunda 7, or are evaluating which major version to use for your next project, this episode has got you covered on how you can prepare for a migration from Camunda Platform 7 to Camunda 8!

If you enjoyed this episode, we recommend checking out Bernd’s blog post, “What to do When You Can’t Quickly Migrate to Camunda 8.” 

---

Visit our website.
Connect with us on LinkedIn, Facebook, Mastodon, Threads, and Bluesky.
Check out our videos on YouTube.
Tweet with us.

---

Camunda enables organizations to orchestrate processes across people, systems, and devices to continuously overcome complexity and increase efficiency. A common visual language enables seamless collaboration between business and IT teams to design, automate, and improve end-to-end processes with the required speed, scale, and resilience to remain competitive. Hundreds of enterprises such as Atlassian, ING, and Vodafone orchestrate business-critical processes with Camunda to accelerate digital transformation.

---

Camunda presents this podcast for informational and entertainment purposes only and does not wish or intend to provide any legal, technical, or any other advice or services to the listeners of this podcast. Please see here for the full disclaimer.

Transcript

Josh Wulf (00:00):

Welcome to another episode of the Camunda Nation podcast. I'm your host. My name is Josh Wulf and I'm a developer advocate at Camunda. It's the hottest topic at the moment, Camunda Platform 8. And we are going in-depth on one of the most popular aspects of that topic, migrating from Camunda 7. If you've found yourself asking the questions, when should we migrate from Camunda 7 to Camunda 8? Or how do we go about migrating or preparing ourselves for migration from Camunda 7 to Camunda 8, then you are going to want to hear this conversation.

Josh Wulf (00:38):

This month, I talked with Bernd Ruecker, co-founder and chief technologist at Camunda about the Camunda 7 to Camunda 8 migration pathway. When and how does it make sense to do it? Listen up, here we go.

Josh Wulf (00:54):

Yeah, this is a really hot topic. Everyone's thinking about it. Everyone who's using Camunda 7, that is, and even people who are looking at doing new projects on Camunda are asking the question, "Should I do C7 or C8 now?" But how about we start with people who are already on C7 right now and are thinking about, "What am I going to do with my system? When am I going to migrate it? What's involved in it?" Those kind of questions. That's the kind of space that I wanted to explore to start with. How does that sound?

Bernd Ruecker (01:23):

Good. Good from my perspective. I mean, that matches a lot of the questions we are currently getting also from the existing community and from our enterprise users. So let's say the general recommendation, it's pretty simple. The rule of thumb from our perspective is to, let's say, to migrate as soon as possible. So that's kind of the north star of saying, "Okay, migration makes sense. In the long run, you should migrate from Camunda 7 to Camunda 8 because that's the product where most of the innovation is going on in the future". At the same time, there are certain reasons why you don't want to probably don't want to migrate exactly right now. And that's also okay. That's one important message we always sending out. It's totally okay not to migrate now and to wait a little bit for a couple of reasons, which we might also want to go into a bit more, but-

Josh Wulf (02:25):

About why people might not want to migrate now.

Bernd Ruecker (02:28):

Yeah. Yeah. Let's quickly go into that. One of the top reasons is what we call feature parity. So we have a couple of features in Camunda 7, which are not yet available in Camunda 8. Basically Camunda 8 was a complete rebuild of the technology behind for a lot of good reasons, but that means we have to redevelop a lot of the features. So it's not just there. And we found a feature set, which we wanted to go live with Camunda 8 where we said, "Okay, that makes sense to get it to the market, to get feedback, to learn and to iterate on that." And also this is valuable to a lot of new users. At the same time if you're already running Camunda 7 and rely on that feature, if it's not there then Camunda 8 makes migration much harder. And that, for example, then poses the question.

Bernd Ruecker (03:22):

If that feature is not there and I want to migrate, I need to find a workaround. And that's, for example, something where you should probably hold on, talk to us, discuss that because very often it's simply a matter of time. So for example, we are missing a couple of BPMN elements we're catching up on that. So in a year from now, that should already look pretty different and then it doesn't make sense to introduce workarounds, to get around that problem, to migrate now. Then I would simply wait for another year to migrate or probably one and a half years to migrate later on it already have these features available.

Josh Wulf (04:00):

So that's kind of a technical barrier to migrating. What about the situation where I've like, I got my system up and running, it's on Camunda 7, I'm making money. Now, you've gone and change the whole thing to Camunda 8 and you want me to rebuild my whole system? I've already invested all this money and developers, tooling, expertise. The thing works. Now, we're going to go and rebuild it on top of something else. Maybe I've got a long cycle or maybe it's just making heaps of money. And I'm like, "Man, I just want to keep it running." What about that situation?

Bernd Ruecker (04:37):

I mean, yeah, also fair and totally understandable. I mean, there are multiple viewpoints on that. The one is if it's running totally fine and you don't have to touch it at all at the moment, that's probably also okay. I mean, we're still maintaining Camunda 7 and that means actively maintaining. So even adding features and actively developing on that for the next five years, that's what we guarantee. So that's a long time span in a way. And that means even then we are not chopping everything like, "Hey, five years ago, we're done." It's like, then we are entering the whole maintenance mode, which goes on for I, if you ask me for a long time, because we are having quite big installations, quite big products, customers on Camunda 7, which I'm pretty sure they will still run that in probably 10 or maybe even 20 years from now.

Bernd Ruecker (05:32):

For some of those customers, we even have agreements like contractual agreements for longer period of support, which is an option if that's super important for you. It's pretty comparable to other technology. I mean, you also operating systems are changing. Java versions are changing. Database versions are changing. And of course, at some point in time, all of these run out of support, it's kind of unavoidable and no vendor can support all versions from the past for all time. And that's in a way natural for IT. We try to extend the corridor, the time span you have for migration, as long as that makes sense from our perspective and at the moment I think we're having a pretty good compromise there.

Josh Wulf (06:22):

Makes total sense. It's the long runway. It's just the way that the world goes. That versions run off the back end. 

Bernd Ruecker (06:35):

What I expect honestly, is that over, let's say over the next five years that the world of software development is changing a lot. We see that everywhere cloud is coming, SaaS is coming. You shift more and more workloads to the public cloud vendors. You might embrace different architectures like microservice or whatever. And all of that has influenced how software development is done, how solutions are deployed, how the world is ticking. And what I definitely expect is that over time, all of our also existing Camunda 7 customers will experience those kind of changes independently of Camunda. And then there will be, let's say opportunities to adjust the architecture.

Bernd Ruecker (07:25):

And that might be the point where you say, "Okay, and now I migrate from Camunda 7 to Camunda 8 because now I also have a big advantage because I can, whatever, run that as cloud service, I can run that in my cloud native environment. I will have all these kind of new features and stuff we build on top of the Camunda 8 platform now, which then probably makes sense immediately for you." So there's also an upside opportunity for everybody involved here. So you should not only see that as, "Oh, I have to migrate." I mean, if you compare to, for example, operating systems, I'm not sure if you want to go back to a Windows 7 or Windows, whatever 95, just because it did its job. You see that there is so much more going on what you can do with an operating system. And it's not a good idea to lack behind too long from my perspective.

Josh Wulf (08:01):

Yeah, I get it. So there's like external opportunities and pressures in the technology space that are going to make, Camunda 8, just make more and more sense as time goes by. And this is the repositioning of the whole thing into this cloud native space.

Bernd Ruecker (08:18):

Yeah. That's a good summary of that.

Josh Wulf (08:24):

Okay. So, what's actually involved in doing a migration? Do you want to dive into that or is there more bigger context that you want to give before we jump into those kind of details?

Bernd Ruecker (08:31):

No, I think these details are actually interesting to explore because for me "When should I migrate?", is very much connected or "Can I migrate?", to the effort of migration and that's connected to "What exactly do I have to do to migrate?" So we can briefly go over it on a high level. So in a way you have to migrate your models like BPMN models or DMN models. You have to migrate code that might use the API and you have data basically, which might lift like runtime process instances, or probably also history data.

Bernd Ruecker (09:09):

So these are the three, let's say big parts you have to look at. So if you go over them, one by one, the models are relatively easy. So we are still using BPMN. We still using DMN. There are a couple of different extensions. The experience we have so far with customers that are looking into migration is that it's not too hard to migrate most of the models. We have a plugin, for example, a model of plugin that can do that conversion for you for the cases where we support it. We're currently looking into making that available as a static webpage where it can go and upload your BPMN file and you get back basically the migrated one, which also would help you very early on in seeing what is probably not supported in Camunda 8 at the moment or where you need to look at.

Bernd Ruecker (09:58):

So the models are, I think not the big problem part of the models. And that might be more interesting to some of the users, part of the model are the expression languages. So for example, if you have a gateway, which is a point of the model where you go either this or that way, then you have an expression describing the logic when you go this or that way. And in Camunda 7, that was JUEL, Java Unified Expression Language, and in Camunda 8, we use FEEL, the Friendly Enough Expression Language, which you might know from DMN. We use that all over the place now. So that was already in DMN in Camunda 7. Now, that's the default expression language everywhere. And that means you have to adjust your expressions. And that can be very easy.

Bernd Ruecker (10:43):

So if we have simple expressions, you can just convert them to FEEL. That's even also automatable. Again, we have a model of plugin, which does that for easy cases, but at the same time, it can be also impossible because with JUEL, you can always dive into Java. So for example, if you're in a Spring Environment, you could define a Spring bean with a method where you code arbitrary, complex logic, and you can invoke that in a dual expression. And that's not possible in FEEL, and that's by intention because FEEL expression should but just be expression, they should not invoke code. And if you have these kind of situations, you have to look into that very specifically. So these are the models, from my perspective, really the easy part.

Bernd Ruecker (11:35):

Then you have the application code. Application code is it's a different API. So we're using a different API for Camunda 8 than for Camunda 7. There is an adapter product out there as a community extension where you might simply reuse the existing code, and that gets adapted to Camunda 8. It works again for the typical cases, but at the same time, I'm not sure if that's the best approach for the projects out there. I'm still in an observation mode in a way.

Bernd Ruecker (12:11):

I'm looking at the project we are seeing and looking at them, if they are really want to use that adapter and how much value that adds. Because for a lot of projects, if you simply adjust the API and let's say, let's speak Java terms, you change the library, like the main dependency, and then you get a lot of probably red code markers where the APIs changed, then you simply go through them. Like what we said earlier, in early days on a rainy Saturday afternoon, it shouldn't take too long. It's a very mechanic thing, it's not super complex. And afterwards, you have adjusted your application to the new API, you don't need any weird adapter logic anymore.

Bernd Ruecker (12:57):

My gut feeling at the moment is that this is the easier path for most products, but I might be wrong. Maybe an adapter library is the solution. So as I said, I'm in observation mode. This gives you by the way, also an opportunity to recheck, to reassess your architecture. So if these kind of code changes are spread all across your application, that might be a smell that this was not designed. I don't want to say properly, but this was probably not the best design. Let's say it that way. And that might give you an opportunity to rethink some of that stuff at the same time. I know that this might increase the effort and you might not want to do that as part of the migration, but it's a good opportunity to do that in a way.

Josh Wulf (13:46):

Yeah. I notice with because I came into Camunda really and using it with Zeebe Camunda 8, and there's a real clear separation of concerns between business logic application code and the engine. Whereas in Camunda 7, it seems as though a lot of it can be, I don't know if you'd say tightly coupled. It's running inside the engine, you can directly access the internal state of the engine it seems, like there's some pretty crazy things that people can do with it. And I don't know how well that translates to the new platform.

Bernd Ruecker (14:20):

No, 100%. I think that's one of the big advantages of Camunda 8 that isolation you just mentioned and exactly what you said in the end, this allowed people in Camunda 7 to do. I always call that dirty hacks so they could do whatever they want. Basically, they can cast to engine implementation classes, they can influence a transaction manager. They can do basically everything there. And this typically also leads to problems. That's one thing, but now for these kind of hacks, they're challenge for migration because they're not possible anymore. So these might influence your architecture, but how big of a problem that is, really depends on how you design your application.

Josh Wulf (15:07):

Okay. So it's also a good opportunity to revisit the architecture, maybe question your choices in life.

Bernd Ruecker (15:08):

[inaudible 00:15:08].

Josh Wulf (15:08):

Go have a look at yourself.

Bernd Ruecker (15:07):

It's always a good habit. No. Yeah, I would say that. And I mean, again, looking back, we are still supporting Camunda 7 for a long time. So if you have one project where say, "Okay, we did all that dirty hacks and we're aware that was not a good idea, but it's not easily possible to migrate that at the moment then keep running it with Camunda 7, that's also fine. So if it's too hard to migrate, it's also understandable. So far the most products I've seen, these hacks are limited to, let's say smaller parts in the architecture, which are normally possible to redesign. And then also a good idea to redesign. So far, that's not such a big problem as I've seen it, but I haven't seen all, obviously not all the Camunda 7 solutions.

Josh Wulf (16:43):

And while we're on APIs, one thing I've noticed for users coming from Camunda 7 to Camunda 8. They're like, "Why so many APIs?" There's like a gRPC API, there's REST, there's a couple of REST ones, there's GraphQL. What's going on?

Bernd Ruecker (17:01):

It's understandable from a user perspective. From a architecture perspective, you basically separated the different concerns we have. So we have the core engine. There you have an API to talk to, like start a process instance or register workers for service task, and so on and so forth, and there we pick gRPC basically for efficiency reasons. For other stuff, for example, task for the task list, the human task API, we pick GraphQL because querying is the core requirement there. And that means that you end up with a couple of different API for the different concerns.

Bernd Ruecker (17:42):

I totally understand that this is confusing. We're still discussing it for only how we can probably improve the developer experience around that. So not saying this is coming, I'm just saying we're discussing that. But one idea also is that maybe a Java client could then embed the different APIs. So as a Java developer, if I use my SDK, I don't even recognize they use different API technologies underneath. That could be one example to hide that from the developers. But we are discussing that, we are keeping a close eye on users in community at the moment on that.

Josh Wulf (18:23):

Yeah. That's really how it is with the gRPC API. At least it's like, unless you get an error because you had the wrong version of a gRPC dependency, you don't even know it's happening. You're just calling high-level API methods and things happen under the hood. Maybe you have to configure a firewall or something. That's about it.

Bernd Ruecker (18:42):

Yeah. And that's the thing. It might be more complicated to configure if you have different end-points, but at the same time, that's kind of the reality. You want different systems serve different purposes. And specifically, as we are looking at big installation, big customers, very often, that's an issue also in Camunda 7 at the moment that for example, if you take task management, then you can make complex queries like, "Hey, I want to see all tasks for this group and this whatever contract or just unassigned." This boils down to SQL queries on the database, that's sometimes pretty hard to process, for the database and the same time that might even influence runtime performance negatively. So there are all these kind of connections internally. And now we are separated that. So we are having the run time. The run time cannot be influenced by queries at all.

Bernd Ruecker (19:38):

We are pushing all the data to ElasticSearch, which is much more optimized for making complex queries and even custom queries. So overall, I think that cleans up a lot of the problems we have. It of course adds a bit of complexity because we now have different components. To some extent, my assumption for, let's say, the later future at least is that you will not really recognize that because first of all, the runtime is SaaS. So it's operated by us. So you don't care how many components we operate. And at the same time, the APIs might be hidden between behind a simple SDK. And then as the developer, you don't also don't care that much. And then you have a system which is where the complexity is hidden from the user. And at the same time, it's super powerful because it can do all these complex queries one time throughput, low latency at scale and all these kind of things. And yeah, that's kind of what I find so fascinating about Camunda.

Josh Wulf (20:43):

Okay. It sounds great when the battle station is fully operational. At the moment, it's kind of like the death star with the scaffolding still a little bit visible, put that SDK skin over the top of it and you won't recognize it. So speaking of the different components, you've touched on modeling the expression language, which has changed from JUEL to FEEL, the application code the APIs, and there's a few other kind of components involved that people probably have to touch to do migrations. Right? You touched on tasks, there's also forms.

Bernd Ruecker (21:21):

Yeah. UI parts, for example, it might be interesting. Yeah. That if you build yourself, it's again just the API change at the same time forms. If you used, for example, Camunda forms, they are supported in Camunda 7 and 8. So that's the good part if you used any of the other form techniques we had in Camunda 7. They're not supported in Camunda 8, so you have to probably look at that. Again, gut feeling wise, there are not that many customers doing that, but if that's an issue, what I always recommend is reach out and discuss the use case with us because just discussing it theoretically for all possible use cases in a way weird. So if you have a concrete use case, discuss that with us or ask in the forum, that's always a good opportunity.

Bernd Ruecker (22:14):

But probably the last and also very interesting part is data. So if you're having a Camunda 7 system in production, you have data in your database and how to migrate that? And at the moment, there's a twofold answer to that. So the first is the runtime data. So for the runtime data, we don't have a migration script or something like that. You cannot just simply push a button and now it's from Camunda 7 to Camunda 8 because that's connected to that. You also have to change other things. So we cannot simply migrate that over, but we're basically having a procedure, which is very similar to when we migrate data from a third party workflow system, like whatever, an Oracle, IBM, or what have you Pega. Then we have a procedure how to start new process instances in the right state. And then it means you read the data from your Camunda 7 database and start new process instances in the right state in Camunda 8.

Bernd Ruecker (23:24):

And as time goes by, so we're currently looking into that with customers and partners. So my guess is that in, I don't know the exact timeframe, I would say probably half a year or maybe at least a year, then you will have examples and success stories of, "Hey, this is how we migrated our data." Probably even here's the script we used in these kind of things. So that's the runtime data and the history data at the moment, just this is migratable. So you cannot migrate the history data from Camunda 7 easily to Camunda 8, but I don't think that it's that big of a problem. Why? Because there's one component which is stable from Camunda 7 to Camunda 8, which is called Camunda Optimize. Camunda Optimize is, let's say, BI tool for understanding what happened in our process instances in the past and making analyzes on that.

Bernd Ruecker (24:29):

And if you exported data from Camunda 7 into Optimize, it will stay there and then you can push the data from Camunda 8 in the same optimized instance. And that makes it, "Okay, there's the long-term storage." I can leverage that for business analyzes and I lose the history in the local Camunda 7 engine, but that's normally then only used for operations. Is everything going well or not, which is not necessary anymore. If you shut down the Camunda 7. So that's how I'm thinking about that at the moment. But again, we're learning every day. So I can just motivate everybody. If you have a use case, if you don't agree with what I'm saying, reach out and discuss that with us.

Josh Wulf (25:16):

Yeah. Okay. I got it. So there's like migrating and then a clean break, "Hey, it's a new system next version," whatever. And then there's this platform itself is a quantum leap radical innovation rebuild. But from the data perspective, from the business perspective, you want business continuity. You want continuity of your business data. You want long running processes to be able to be shifted from one system to the other system and continue running. And it sounds like that is either possible or soon to be possible, but looking historically at the view of your business and what's been happening in it, that's basically going to be a break with the past there. So you'll be looking at your new system and your old system in two different interfaces.

Bernd Ruecker (26:07):

I would say yes for the operational parts or the daily run time, but not for the business analyzes part. So if you look at Optimize, Camunda Optimize, you probably have all the data from both systems overall, but what's going on a day to day basis it's pretty different. And of course there are always nuts and bolts, which might need to be figured out currently. And that's probably also interesting for everybody, which is who is looking into migration products. So currently we are having actually a couple of partners from us looking into that more deeply on a project level. And really my expectations is that we will have a lot of learnings over the next year, which might lead to also let's say more established practices. So at the moment, there are a lot of ideas. There are attempts, but obviously no, or at least no customer I know of is already completely through. "Okay. We migrated this big in production system from Camunda 7 to Camunda 8."

Josh Wulf (27:14):

I'm surprised to hear that you can look at a Camunda 7 and Camunda 8 system history in the same interface because they're radically different data stores.

Bernd Ruecker (27:26):

The Optimize has the same data stores. So Camunda Optimize is one component, which was already in the Camunda 7 architecture decoupled from the rest. So basically seven, the engine pushed on a... No, I think it was even Optimize pulling data from a Camunda 7 engine and then storing that in a different internal format for Optimize. We already did that with Camunda 7 and Optimize basically stays the same. So with Camunda 8, it means that Camunda 8 is pushing all the data out to an elastic store. And then we have a loading mechanism to get it into Optimize. And then the data is there in the same form of independent, if you're coming from Camunda 7 or Camunda 8 in Optimize.

Josh Wulf (28:13):

Whoever did that architecture for optimize needs to get a medal because they clearly nailed the abstraction.

Bernd Ruecker (28:20):

Yeah.

Josh Wulf (28:22):

Yeah, well done. Okay. So that's kind of covers like you've got a running system in C7, when do we lift it and shift it to C8? What about if you are looking to start a new project and maybe you have tons of C7 experience in house and tooling and everything, and you're like, "Should we do it on C7 or C8 at this point?" What are your thoughts on that?

Bernd Ruecker (28:47):

Yeah. The part of what he said in the beginning is probably the most complicated. If you have a lot of knowledge, a lot of best practices internally, and we have customers running big center of excellence, running tens or hundreds of products and switching the modus operandi is not super simple for them, and I totally understand that. At the same time, I would try to get to a situation where it can start new projects with Camunda 8, as soon as possible because starting a new project with Camunda 7 is kind of weird because that already means you have migration in the back of your head when you start doing it. And I would try to avoid that and the whole discussion around feature parity, we are missing this or that feature normally is not that big of a show stopper for new projects because they are rarely going live tomorrow.

Bernd Ruecker (29:47):

So first of all, there's a bit of runway to build a couple of features and we have a roadmap where we relatively good when we build what, but of course it can happen, but very often then it's also not a big problem to live without this or that feature because you're building it from scratch and then you're having this work around in and that's probably okay. We did that also with Camunda 7 in the early years for years and that worked pretty well. So I tend to recommend to start with Camunda 8 then now, because then you avoid any kind of migration in the future. You avoid any kind of confusion around, "Okay, what should we do now? Is there anything we should definitely avoid to be migrated?" And so on and so forth.

Josh Wulf (30:37):

Okay. So you're strongly advocating if it's at all possible go to Camunda 8 now with any new projects, Greenfield stuff?

Bernd Ruecker (30:46):

Yeah. And I totally understand the part where you're already invested in best practices and probably in code and frameworks internally. Still, if I do a new project, I would like introducing Camunda probably in the first time I would do at least a pilot project, proof of concept, a lighthouse project, whatever, some of those project with Camunda 8 to again, to learn and understand what that means and how probably best practices need to adapt. And then adapt that slowly. I would also not pull the trigger saying, "Okay, now everybody does Camunda 8. We have no idea yet what that means, but we do that from now on." That also doesn't make sense, obviously. So you have to do that again, step by step. And that's probably harder for big organizations than it's for small. If you have one or two Camunda projects and all of those are done by the same developers, it's relatively easy to switch. If you have hundreds of developers running or doing Camunda projects is definitely a different story of course.

Josh Wulf (31:51):

Okay. I got it. So let's say that I'm listening to the podcast and I'm like, "I don't believe I'm listening to this and hearing what he's saying, because we literally just started this new project like two weeks ago on Camunda 7. And there's no way I'm going to be able to get management to realign on switching this to C8 now." Now, what am I going to do? So do you have any advice for someone who finds themselves in that situation?

Bernd Ruecker (32:14):

Yeah, we do. I mean, there is a migration guide in the docs, which I can totally recommend to have a look at. So if you just go to the camundadocs. Camunda.io. In the guide section, there is a guide migrating from Camunda Platform 7, which also by the way, walks you through all the concrete steps, what you have to do. And the adapter logic I mentioned earlier on is linked here, and so on and so forth. And that also has one section about it's called preparing for smooth migrations. And that means I'm basically okay if I do Camunda 7 projects or if I probably touch a Camunda 7 project, I need to touch it, but I can't migrate it right now. It might be worth to look at those practices to make it easier to migrate later on. And in a way that's pretty much obvious and related to what I said in the beginning, what are the differences?

Bernd Ruecker (33:10):

So for example, no hacks, no dirty hacks. So we call that clean delegates. So if you write a bit of code, don't assume you're running the same JVM as the engine. Don't assume you can have a transactional integration there. Don't assume you can cast to any engine classes. So there are a couple of these things which are also linked here. So clean delegates, I think is really the most important thing, because if you do that right, then you can use that adapter and reuse the code in a minute easily. Then other things like what I said early on don't spread the API, the Camunda API, use it all across the application. So don't expose it to the outside world. So I've seen customers exposing the REST APIs to their UIs and making that harder to switch in a way.

Bernd Ruecker (34:06):

So sometimes then it makes sense to keep that more locally. It depends a bit what you do, what that means exactly. But the other more local, the usage is the easiest to switch it later on. Then more concrete hands-on, things like use primitive variables or Jason. Jason is something we also support in Camunda 8 primitives. Of course also because primitives are part of Jason. So that will be easy to migrate. We don't support XML out of the box. We don't support any Java types. That was possible with Camunda 7. You could just throw in a Java object and it was serialized in the database. We don't support that anymore. So that can get a bit of a hassle if you have, especially Java objects or probably XML there. So it should be primitives and Jason. Same goals for the expression language was kind of connected. So we are using FEEL instead of JUEL. There is a community project, how to hook in the FEEL expression language into a Camunda 7 engine.

Bernd Ruecker (35:13):

So that might be worth a look because then it can, could already write, feel expressions from day one with Camunda 7. If that's not possible for whatever reason or too complicated, it's not too much of a problem if you write simple expressions only. So if you have simple dual expression, they will be automatically transformable. If it's just saying, "Hey, X is grade R equals five," that's super easy to transform.

Bernd Ruecker (35:42):

Again, don't go into Spring beans or Java codes and so on and so forth. So keep them simple. That helps a lot and use Camunda forms. So you asked that earlier on, right about the UI. So Camunda forms are there in Camunda 7 and 8. So that's a good way of keeping them migratable. All the other forms former Camunda 7 are not supported in Camunda 8. And I think these were the main things you should have a look at. And then despite that just probably have Camunda 8 back of your mind, probably look at the architecture or build a small example that gets started guide quickly. And then you should have an idea how Camunda 8 is behaving and then it can build the better migratable Camunda 7 solution.

Josh Wulf (36:30):

You think that building with Camunda 8 in mind would lead to better, more maintainable C7 systems?

Bernd Ruecker (36:41):

I would think yes. Yeah, because a lot of the things I talk about, make it simpler and more isolated, like clean delegates. That's something you should have done forever in Camunda 7 already. So clean delegates is something you should always do. By the way, that's a discussion that comes up regularly. "Why do you have to do this kind of different components? Or why do you have to do microservices? You could do a well-structured monolith." But no, you can't very often because if you can cast an implementation class, if you can do this work around just for a tiny case, people do it. So I definitely would say that if you follow these rules, you will get a better design, Camunda 7 architecture as well. Yeah.

Josh Wulf (37:34):

You get a system like Optimize where you can just whack it on top of a completely different system and not even notice, right?

Bernd Ruecker (37:41):

Yeah.

Josh Wulf (37:41):

It's like the right level of abstraction and isolation.

Bernd Ruecker (37:44):

Honestly, it was also a learning process for us internally. I remember and that was more like 10 or 12 years back. For example, you could throw in a Java object into Camunda 7 and we had a mechanism which could recognize, "Oh, that's an JPA, that's the Java Persistence API, JPA entity." So we manage that with the right JPA Persistence manager, so ends up in their database and just remember the primary key for it. And then we do that transparently in the background.

Bernd Ruecker (38:16):

That's super cool because if your Java developer can throw in your entity and will be persisted correctly, will retrieve correctly, and so on and so forth. So we experimented with that and I was a fan in the beginning. So we had a lot of these kind of tricks with JPA or CDI, all the Java enterprise stuff. But in the long run, it turned all, that was simply not a good idea because it like couples everything together, too tightly. And that was also for us, the learning process in a way.

Josh Wulf (38:45):

Too much magic and unmaintainable.

Bernd Ruecker (38:48):

From my perspective, to summarize, I find it important that people are not worried. So we don't leave anybody alone with Camunda 7. So it's here for quite a long time. We are still actively developing it. We're looking into migration projects learning along the way, and I'm pretty sure we will also improve our migration practices over time. So we're not letting people alone with that. That's, for me, very important because I mean, the older Camunda 7 users are of course, close to my heart. They brought us where we are and I'm pretty sure there is a good way of migration for almost any of those.

Josh Wulf (39:28):

Thanks for coming on the podcast, Bernd, and sharing about the Camunda 7 to 8 migration, connecting the past with an exciting future in the cloud.

Bernd Ruecker (39:39):

Thanks so much for having me Josh and keep up the exciting podcast.