There is a solution that does not require you to recreate everything manually.
One way could be to simply use the things file from OH2. This will give you your things in OH3.
If you plan to shift the maintenance to the UI you can simply open the “Code” tab of a thing, copy the YAML from there. Then create a generic knx device in the UI, give it a unique ID and save it. After this go to the Code tab of this thing and replace it with the YAML you took from the old device, but keep the new devices ID.
Save it. You will see that all your channels are now visible in the UI and the thing can be managed from UI.
Now comment the old thing definition in your .things file and it will vanish from the UI.
Advantage of this process is that you now can modify the thing either in the UI or textual by editing the YAML.
Sticking to the .things file your thing is locked for editing in the GUI (you see the lock in the things list).
I did shift my knx things (and others) to the UI that way and in my opinion it was the right way to go.
Most likely you are still on the knx1 binding, right?
I just did the same migration and it was quite some work.
There are some migration tools out here (one python script from Jo and an excel sheet) that might be of help.
However for me they did not help much so I ended up doing the knx1 -> knx2 migration by hand. I have a parallel OH3 instance running that I used to debug.
It took me a few days (not working fulltime :D) to get it done but in the end I am quite pleased with the result.
I did some refactoring of my knx installation and items - so it was a good opportunity for a “spring” clean.
Thanks for your answers. I think i will run the openhab 3 alongside the openhab 2 in my docker and then take it over manually. I also have some rules and so on that i also want to take over. About the manual way I can then use the complete gui functions.
And I can use it like bernd for a cleanup