That’s roughly where my thinking is too but I think a potentially bigger issue will be non-native device migration because many of the devices exposed through Vera plugins will take a while for the developers to port/rewrite for the ezlo firmware (if they even do in some cases). Harmony Hub, Broadlink, MyQ, etc. come to mind. Ideally, we would be able to bridge legacy Vera devices to the ezlo until they are supported on ezlo.
As for scenes, they are easy to port from one controller to the other, provided “all” ezlo and vera devices are exposed/bridged (triggers and actions) on ezlo and the ezlo offers similar scene constructs/semantics. My most complicated scenes are in Reactor because they are easier to express with Reactor so if Reactor were available…
Personally, during migration, I’d want my primary focus and time investment during migration to be ezlo because it offers better zwave/zigbee device support including S2 (proven by Atom and ezlo Linux firmware that I have used), new devices can be added without a firmware release, etc. So, if I could rip the bandaid off without loosing legacy Vera device support, that is what I would do.
Net, net, the Vera firmware is static, bugs and all, so I would want to move native devices and scenes to ezlo as quickly as possible with a bridging solution for non-native Vera devices. This will help flush out issues on the ezlo platform and the developers will be able to respond to much more quickly than they ever could on Vera. I’m hoping the end result is a more capable and stable automation solution sooner.