Hate to keep raising problems @johan - guess @Maj will think me a ‘wingeing Pom’ to borrow a cricketing term! - but playing devil’s advocate here and trying to concieve solutions/mitigation strategies… The user may not have control of the GWs or own them, also simply migrating the GW’s to V3 if they do have control simply switches off other V2 users nodes/applications covered by them - not very community spirited 
How can we co-ordinate these activities and transitions. Some users - especially many end users - may not even be aware of pending transition and behind the scenes activity and just receive a service or the output from a dashboard integration perhaps on a shared url link… then suddenly one day it stops working/updating…
in @esairq 's case above clearly he didnt get the telegram saying do x before doing y, and likely is only the 1st of many - we need to quickly come up with a very simple (so people like me can do it!) step by step guide and publish it professionally and well signposted or the community is going to get very fragmented & very messy very quickly (and the Forum likely wont be a nice place to be for a while!
)
The moderators I’m sure will curate and clean up and guide where they can but this could get overwhelming I fear…
From what I am getting on back channels 3 main issues look to be biggest concern - timing with RO from April even if actual sunset much later - everyone dealing with pandemic and thinking this is too much too quickly. And 2nd is the lack of V2 to V3 dataflow atleast during transition phase…may not be technically possible or a big lift to fix but can something be done before chaos lets loose. Many now getting the transition message and looking far out to sea the Tsunami is already building
And that leads to 3rd concern that GW’s that are relied on may switch before users ready/have time/can access nodes to effect change or update…many indeed wont even know if what they have in their hands or have deployed in the field falls into (which) one of the 4 categories of device you called out depending if build or bought of the shelf and if a screwdiver build or s/w compiled themselves etc. They simply may not know where to start!
Whilst we cant cover all the self builds and hacks people have put together & deployed on TTN perhaps we can post a traffic light system for popular off the shelf systems - Green - will transition with no issue, Amber may need a reset (OTA or power cycle) or a minor intervention, some ttnctl cmd line hacking or whatever, Red - oops you’ve got a potential problem/may be stuffed and need to work hard! And apply that to the likes of say (just for examples) Laird RS1xx T&H, Dragino LHT65, ERS-xyz, MCF88-abc, DecentLabs-ghi etc…(Maybe start with labeling the items listed in the TTN/TTI Marketplace?!) That way we can focus efforts and manage by exception/scale of problem…?
Perhaps this is something we can recruit the product manufacturers/suppliers into doing?