I hear you Tim and I’m glad you were able to restore functionality on your devices. I have nearly a hundred devices on SmartThings so migrating is certainly not going to be an overnight experience for me. Best of luck on your home automation projects!
I was just happy that I had a viable solution that worked for me on hand and ready. 
Criticism of SmartThings is not being censored. In fact there are plenty of those posts that have not been moved. If you have genuine feedback or issues with the platform or integrations you can post them in the appropriate topic. There is a hubitat community to talk all about hubitat too. The alternative hubs thread was meant for SmartThings users who were also users of other hubs. If you feel a thread has been moved in error you can PM me about it.
Thank you Jody for the clarification
@jody.albritton Makes a very important point that from the very beginning there have been smartthings users who also have hubs of other brands, And there have always been discussion threads about both how to integrate these and how to coordinate them in the sense of which functions worked best on which hub. This includes Insteon, vera, HomeKit, MQTT services, hubitat, Ring Security, Alarm.com, 2Gig, Abode, LightwaveRF, HASS, etc.
Sometimes the integrations were through secondary hub options, sometimes via IFTTT, Sometimes through specialty bridges like HOOBS, sometimes through homegrown server implementations. But over the years there have certainly been dozens of threads on these topics. And a lot of creative work, often of interest to other SmartThings users. 
Hi @jody.albritton. Just noticed you had moved/unlisted (not sure which or if they are one of the same) one of my posts, so probably I violated some rules or guidelines. For that I’m very sorry as this was not intentional.
The post’s main intent was to give back to the community: I had taken a lot of people’s time to help me fix some of the new ST app migration issues (such as MyQ, life360, STHM, etc.), and given back very little in return. My notes of my HE migration was an opportunity to fix that, to some extent.
In no way this was an incentive for people to change, e.g. the cost of the migration & cases where the grass is not greener (especially the fact that GE non-plus z-wave dimmers/switches are better handled in ST than HE) are documented. This was more of: if you are forced to change (as it had unfortunately been my case), this may help you decide if Hubitat is an appropriate choice, and if you do migrate, here are a few tips that may save you some time and pain.
Hope this helps clarifying things, and feel free to delete that post or this one if appropriate. I won’t take it badly
In any case, I was and will remain a ST fan, watching it grow and evolve from the sidelines.
I know hubconnect for Hubitat was mentioned in the past on this thread but I never really paid attention to what it was. After watching the below video and seeing it mentioned on the Echo Speaks thread, I’m really interested in it now and the idea of using it to run the Smartthings hub AND a Hubitat together. I know @ogiewon you mentioned it. I’m curious to know more about it. What runs better on one hub or the other? Obviously Echo Speaks on the Hubitat is a no brainer, but what do you keep running on Smartthings? I know for sure my door locks would stay solidly on Smartthings because that’s the one thing my wife uses the app for and I dare not change it at this point, lol. https://www.youtube.com/watch?time_continue=156&v=XFRFDqtVgw0&feature=emb_logo
Lutron picos are GREAT on Hubitat. Schlage locks and GE zwave Classic Switches (older than zwave plus) don’t really work on Hubitat, so smartthings for those. A lot of Fibaro stuff has stopped working on smartthings, but may eventually get updated (looks like they need a new DTH).
Of course I have just the basic Lutron hub and not the Pro so i believe I would need to upgrade that for use of the PIco’s beyond Casetta devices. I heard about polling issues with the older GE zwave non-plus switches over there so would keep those solidly on Smarthings too. Thanks JD.
Just be aware that when groovy ceases in 2021 so will the current version of HubConnect on ST. It is unknown at this time if the developer will port it over to the new API. It may become clearer in November what direction the developer will take when he returns from vacation.
They work just fine on Hubitat using the built-in Poller app (which you have to manually enable). I have moved several of mine over. The Poller app merely does what SmartThings does (poll for physical switch changes, since these switches don’t report that).
FTFY. Lots of stuff is going away on SmartThings next year.
As far as HubConnect is concerned, it’s possible the part talking to the SmartThings API could just run on the Hubitat hub.
But again, it will depend on what direction the developer chooses to go.
Was there a specific month it is supposed to stop?
No specific month stated. Probably late 2021 according to one of the execs
Some of these have already been mentioned… But here is what I came up with off the top of my head. This list is not complete by any stretch of the imagination.
Better/Only on SmartThings
Better/Only on Hubitat
As for what I keep on SmartThings… 
I am currently utilizing the Logitech Harmony Hub integration to allow me to map lights to the Elite remote’s Home Control Buttons. I also have some ST_Anything devices on SmartThings for testing/development. Early on, I used Action Tiles on ST to display Hubitat connected devices via HubConnect. These days, I rarely use a dashboard or mobile app to look at devices or control them. I am running HomeBridge on a Windows 10 server which exposes to HomeKit the Hubitat devices that I might want to view/control on the go. For example, it is nice to be able to open/close my garage door when we go out for a neighborhood walk.
they didnt work well for me / i replaced them… there were unaccptable lag… using them even with poller app
Interesting - “lag” for what action? Since I have Poller to check them every 10s, it would mean an automation won’t see a manual switch action for up to 10s. But I don’t control any of my switches physically at all - all are triggered by motion or time. The one GE/Jasco dimmer that does on via motion is instantaneous.
That said, I just got 10 Inovelli Red dimmers. All of mine will be replaced soon.
Physical switch turning on which then is sensed and turn on hue lights. 10s is long. And never had that lag in St. I wonder how often their poller ran. Anyway replaced is wave plus.
I’ve been working with the GE/Jasco switches a lot and trying to update the DTH’s. From what I see, the older non-plus ones do send a report when they turn on/off, but it’s just a “basic” report that needs to be decoded by the DTH to figure out what happened. Most other Zwave devices send a “binary switch report” when they turn on and off so its easy for the controller to figure out what happened, but the older Jasco switches don’t seem to send that binary report. I had a similar issue with the older Aeotec Micro not updating status, but using a custom DTH that updated its parameters and decoded its report got it to instantly update status.
I noticed when I used the handler I updated based on the Nuttytree DTH, even though its for the newer “zwave plus switches”, its able to parse out an “on” “off” report from the Zwave basic report, and get an “instant” status when you turn it on or off at the switch. When I use the stock Zwave handler, the on/off status is delayed, sometimes by almost a few minutes. I’m thinking it has something to do with these lines of code:
// parse events into attributes
def parse(String description) {
log.debug "description: $description"
def result = null
def cmd = zwave.parse(description, [0x20: 1, 0x25: 1, 0x56: 1, 0x70: 2, 0x72: 2, 0x85: 2])
if (cmd) {
result = zwaveEvent(cmd)
log.debug "Parsed ${cmd} to ${result.inspect()}"
}
I’m sure there’s a way to get the on/off events from those switches out of the basic report on other hubs. I also think something in the Samsung hubs “polls” the switch either periodically or whenever it gets a basic report it doesn’t understand (if using stock DTH). I’m not really sure exactly how that works but imagine other hubs don’t have that. Also, I don’t have the non-plus dimmer switches so can’t speak to how those work.
I’d also imagine if you had a lot of these switches constantly being polled every 10 seconds, that would create a lot of zwave traffic on the network that could impact performance. Probably if its just a handful of switches though, I doubt it would make a noticeable difference though.
Maybe I don’t know all the ins and outs of exactly what’s happening behind the scenes, and I could be off on some of what I wrote. But the bottom line is when I use custom code on these switches, I get instant status, and when I use the stock DTH, I don’t. It’s essential on my one switch to get that status quickly because turning that switch on runs my whole morning wakeup routine in Webcore. And this is why being able to use custom code for device drivers is so important, and what I really worry about is what’s going to happen next year with the IDE phaseout and custom code. If I can’t run custom code and need to rely on only the stock or company supplied handlers, that really would be a deal breaker for me.