Hi I’m trying to move my existing openhabian 3.4 (RPi 3) installation to a Win11 based 5.1.3 installation. (M710q tiny)
I have a backup of my 3.4 install but unfortunately some items/things were created by file and some by UI.
I also tried moving the jasondb files to the new installation but however alway if I open a e.g. thing thats created by the jasondb file, UI gets stuck loading.
What is the best/easiest way to get my config to the new installation?
For such a big move there are likely a number of manual steps that will need to be done.
My recommendation would be to do a gradual migration and use the Remote openHAB add-on to make running the two instances at the same time a little easier. The overall process will be as follows:
Start up an empty openHAB 5.1 on your Windows machine. Install the Remote openHAB add-on, discover the other instance as a Thing. The Thing will have one Channel for each Item in the old OH instance and those Items will be kept in sync with the old instance. So create Items linked to the Channels and your new OH will have all the same Items as the old instance. If you are looking for a managed config, you could use “add points to model” to create them all in one go.
You have your choice on what to move over to the new instance. I recommend doing so one binding at a time, but you could also just move the rules first and then move the Things/Items over one at a time. But the process is generally:
a. disable the Things/bindings on the old instance
b. install the binding and create the things on the new instance
c. replace the links to the Items for that Thing with links to the Thing’s Channels instead of links to the remote openHAB Thing.
d. repeat until all add-ons are moved over.
The other alternative is to try to eat the whole elephant in one go. You’ll have to review every release announcement for OH versions between 3.4 and 5.1 for breaking changes. Most of the time breaking changes need to be manually handled through some manual change.
Which is why I’ve argued that this information should be available chronologically somewhere - having people manually look up and read all of them is… more than enough to discourage me from upgrading a system.
I’m sure if someone wanted to take that on it would be supported. By I know of no other self hosted service that maintains such a list. OH would definitely be an outlier.
And how far back should one go? OH 3.4 came out almost three years ago. Is that long enough? Too long? Should we go all the way back to OH 1?
What about situations where something changed twice (e.g. between version x and y and then an additional charge between y and z that modifies the change)? List both changes? only the latest?
I struggle to see how putting everything on one page would be anything but more confusing.
I was thinking about what I suggested a long time ago, here, about having a changelog with important changes. It would simply list versions chronologically and include “major changes”, especially breaking ones, for each version. Upgrading would then be reduced to pull up the changelog, start with your “from” version and go through everything until you reached the “to” version.
Having changelogs isn’t uncommon, the challenge in OHs case is how to “filter it down” to something manageable, because especially all the changes to the add-ons makes for a complete information-overload if everything from the current release notes were just put into a chronological document.
It all depends on what kind and number of bindings you are running.
I migrated yesterday in a good two hours from 3.4.3 to 5.1.3; three find/sed; 1,600 items, 85 things, 200 rules. (though no scripts, no scenes; ~30 bindings, automations, persistence, BasicUI and HABpanel; the latter is toast, no tablet came up afterwards (despite changing the IP address to reach OH). Other than that; all good.
As for your items, you could import these in the UI. Things are easily recreated in the UI too. (I have done that, but kept my rules exclusively in files).
Migrating between machines is easier than in-place.
In any case: good luck 
a) every release has notes
b) lookup; a matter of choice
c) I dread updating my production system every time (I planned three times post 3.4.3 and always chickened out); however, since moving to a docker install, this has become a breeze. Even without docker, install on a spare machine, install new version, copy over and see what breaks
Yes, but my point, then as now, was to present them in a chronological way so that people doing an upgrade, or considering doing an upgrade, could get an overview of the obstacles. Now each and every user has to do this “work” individually, figuring out what releases exist, find the release notes, and then somehow, try to filter out what’s important from the wall of text that often is the release notes. I just think that’s “less than ideal”, and I think it would make upgrading a better experience for people, if they could prepare for and know which challenges would present themselves, upfront - instead of just “jumping in” and hoping for the best. Not all issues will present themselves immediately, so I wouldn’t “trust” that everything went smooth even if nothing appeared to have failed right away.