just wanted to let you know that I'm currently working on an extension to 7.5s migration mechanism.What Camunda provided with 7.5 release is a very good idea! Instead of having to reinvent the wheel over and over again... ah, well, I guess you get the point

So, why an extension then? you might ask.The answer is simple:

The migration plans you can create are deployment-specific. It's not out-of-the-box possible to create a migration plan on a dev machine, test it in a QA environment and then run it on production.

Sometimes its just not enough to simply migrate a variable along. You have to rename it, change its value, its type or delete/create it. Just think of some composite key stored in one variable that has to be split up into two.

And that's exactly what the extension addresses.

I'd be glad if I could get some feedback from you Especially if you plan to do some migrations in the near future and are looking for a way to do that, then please have a look at it. If you are interested in using the extension, then I'm interested in supporting you and speed up the extension's development.

It is great that you like migration and want to improve it. The improvements you mention are very similar to what we in the core team consider good improvements, confer our migration backlog and in particular issues CAM-5316 and CAM-5317.

In that sense, I would rather like such improvements to become part of the core codebase instead of a community extension.

Our plans for improving migration will be based on the feedback we receive and I think we still need to gather that feedback. Right now, we do not have a concrete plan for when we are building new features and which that will be. For a specific JIRA ticket, you can tell by the "Fix Version" field. My point in my previous post was rather that we are thinking in the same direction

I agree that an extension is good to get going fast and get feedback. In contrast, I think that certain features are easier to build within Camunda BPM than on top of it (e.g. transforming variables during migration; Cockpit integration) and that a core feature reaches more people. So if you are going to tackle these topics, you can also consider contributing directly to the Camunda core when the API design is not risky and the implementation actually easier.

You are right with what you say. Plus: I would definitely like to be a core contributer As for now I'd like to go with the extension approach until I have more clarity about the use cases.But I could move closer to the core in terms of design, conventions etc. so we could more easily move this into it at a later point.

That way you will get a more mature feature for the core. What do you think?

There hasn't been an update for some time, but I wasn't lazy On February 13th we will have a Camunda User Group meetup in Hamburg. And guess what, process instance migration and camunda-bpm-migration will be the topic.

Thorben told me that you made some progress on your extension and you would like to add it as an Camunda community extension. As Thorben is already quite busy supervising another community project, I would like to assist you with all the help needed to setup the the extension properly. So feel to approach me any time you have an organizational question

The next step would be to transfer your project to the Camunda organization. There are two ways to achieve that:

I can create the repository in the Camunda organization and give you push rights. This would lose the two issues in your current repository and would not create redirects from the current repository URL to the new URL.