Upgrading in place to OH3 on Windows

After much wringing of hands an gnashing of teeth, I’ve given up on setting up a brand new OH3 instance in Ubuntu under either Docker or HyperV on a Windows 10 WSL2 instance. Just too many roadblocks.

Instead, I’m going to upgrade my old Windows OH box from 2 to 3 “in place” (after a backup, of course). This article makes it seem pretty easy.

Generally, I was looking for any “gotchas” anyone wants to share. I didn’t see too much here on the subject (Windows, specifically).

I would also like to switch from MySql (running on the same hardware as OH) to PostgreSQL (running in a docker container on separate hardware. It wouldn’t be the end of the world to lose my historical data and start fresh, but it’d be nice to keep it if not too difficult. Presumably it would probably be best to do that after upgrading OH.

Next, I’d like to do away with all my .items .things etc files and just use have everything in OH’s database.

Lastly, I want to upgrade from my old HS Z-stick to the new Aeotec Z-stock I bought for this project. Again, probably post-upgrade.

Any pointers, caveats, gotchas, or dire warnings on any of that?

Any concerns about doing an “upgrade in place” making it more difficult to re-orient to the semantic model. I’m really loving how that looks.

TIA for any advice.

Since a Windows installation is mainly just an unzip and registration of a service file, you could probable do a side-by-side install for OH 3 and do a fresh configuration on OH 3. The main restriction will be you won’t be able to run both your production OH 2 and the new OH 3 at the same time. But it’s easy enough to shutdown OH 2, manually start OH 3 and do your work.

Once OH 3 is where you want it, you can modify the service file to point at the new OH 3 instance.

Anyway, I can’t comment on the Windows upgrade process. I know early on the service file wasn’t quite right in the docs for OH 3 but I think that has been fixed.

I would wait until after the upgrade. I believe the script posted at Migrate your existing persistence data to InfluxDB should be generic enough to work for this with only minor modifications.

I just cut my losses and started over. The advantage there was as I was rebuilding from scratch I was able to change the names of some of my Items. To migrate the data you must keep the same Item names.

I started importing the Items from my .items files. But I also wanted to use the model and it turned out to be a lot of work to retrofit my Items to the model. So instead I rediscovered and created my Things and then used the “Create Equipment from Thing” option to recreate the Items. For me this was twice as fast as trying to rework my existing Items into the model.

Definitely have at least a quick skim of the Getting Started Tutorial.

No real advice but a quick tip. You can exclude a device from a different controller that it was included on. For example, you could use the Aeotec to exclude a device from the Z-stick and then include it on the Aeotec. That might make your migration between the two a little faster.

Thanks much @rlkoshak. That’s exactly what I was looking for. Great to hear your experience about importing items and building the model. I’ll follow that path. And I agree about “cutting my losses” with historical data … this upgrade is the ideal time to start fresh. Cheers!