This topic is more general based - you’d be best off finding the topic that matches closest to and posting there. The first question anyone will ask is, is it showing traffic - the indicator make take time to catch up.
I’m facing the following problem: Today I migrated successfully 45 nodes to v3 and now I do the same for a few gateways that are still in v2. Although my gateways display “connected” on v2 console, in v3 they are all still “Disconnected”. I follow line by line the migration guide, but still can’t figure where is the problem. I tried to read as many threads as possible before writing here but still couldn’t find a solution. Am I missing something? Do I have to wait for a few hours or access remotely each gateway and do some other process? One month ago I managed to migrate a gateway from v2 to v3 with success by following exactly the same steps. 
Thanks in advance!
Is this some voodoo time travel - no, it’s me hacking away at moving posts when someone double posts.
@Ioannis_K, please don’t double post.
Sorry, I apologise
Hello again,
Thank you for your quick response! I really appreciate it. Almost 8 hours have passed and I still haven’t seen any changes. Still all 9 gateways are remaining offline in V3. What is the maximum period of time for it to be considered abnormal?
Have sometimes gone to bed after some late night hacking and transitions or new additions to find all ok in morning so I guess lots of processes sweep overnight…Eu time. Typicalmused be adding a new V2 gw that wouldn’t sometimes wouldn’t show up on community maps until next day…not sure on timing/processes for V3. If showing as disconnected in V3 are you actually seeing data coming into applications? If so take a peek at message meta data…basically if gw info says your V3 name all is good and console waiting to catch up, if it shows as PacketBroker then still coming in through V2…
Have you run https://mapper.packetbroker.net/api/v2/gateways/netID=000013,tenantID=ttn,id={gatwayID} to see what it returns while not showing on the map or the console?
This will be interesting to know.
What do you mean by offline? Is the gateway console showing the regular pings (typically about every 30 seconds)? Is it showing any traffic from devices?
Personally when I setup a gateway or start one up, I see pings (alive messages) immediately. And I pay no attention to the connection status - it’s traffic that counts.
Good morning!
Their status is remaining ‘Disconnected’ and I still don’t see any traffic in the live data screen, not even pings.
Sure!
By running: https://mapper.packetbroker.net/api/v2/gateways/netID=000013,tenantID=ttn,id={gatewayId} the result I get is the following:
{“message”:“store: not found: get gateway”}
On the other hand by running: https://mapper.packetbroker.net/api/v2/gateways/netID=000013,tenantID=ttnv2,id={gatewayId} the result I get is as expected:
{“netID”:“000013”,“tenantID”:“ttnv2”,“id”:{gatewayID},“eui”:{gatewayEUI},“clusterID”:“ttn-v2-eu-3”,“updatedAt”:“2021-11-18T07:09:19.602706Z”,“location”:{“latitude”:40.56475042,“longitude”:22.99399674,“altitude”:0,“accuracy”:0},“antennaCount”:1,“online”:true,“frequencyPlan”:{“region”:“EU_863_870”,“loraMultiSFChannels”:[868100000,868300000,868500000,867100000,867300000,867500000,867700000,867900000]},“rxRate”:30.508188,“txRate”:0}
Interesting it say “online”:true
Do you see the data in the applications?
Indeed it says “online: true” but apparently this happens only in the case of the v2. I can’t see any data in the applications screen of the v3 console if this is what you are meaning.
The “v2” in the API have nothing to do with V2 or V3 stack.
Have you delete the gateway form v2? If you have not you have the same eui in V2 and V3
All my gateways are still in v2 console. According to the relevant guides, I have to make sure that the migration is successful before I remove the gateway from v2 because there is no way to undo this action in the future. Am I wrong about this?
Sorry a while a go I did mine.
Double check your cluster address.
https://www.thethingsnetwork.org/docs/the-things-stack/migrate-to-v3/migrate-gateways/
Is there a way to do it remotely? I have no physical access to my gateways. Actually they are located in a different city.
It is strange because I have successfully migrated one of them one month ago without even checking/changing the cluster address. Note that they are all configured years ago using this guide: How to build your own LoRaWAN gateway - Stories - Labs (thethingsnetwork.org).
Begs the question what make, model & configuration are your gateways? Are you able to remotely access them for management?
In my case I have set up >75% of my active personal GW estate in V3 already - rest should be finished next 7 to 10 days(#) and most of those are now operating fine in the new environmment (but not yet deleted from V2), however, there is a rump of GW’s that will not start operating on V3 until I either 1) physically travel to site to directly connect to the target GW and change target NS url to move from V2 to V3 (typically changing one line in code or in Management GUI depending on type for my case from e.g. router.eu.thethings.network instead to eu1.cloud.thethings.network), possiby updating any ports used depending on PF protocol or 2) travel to site or close proximity to allow to access the associated network to log in and do same as 1) or 3) remotely tunnel in over the internet (VPN or whatever) or in case of TTIG’s(#) trigger remote claiming process to effect change of config using scheduled CUPS server update (can take up to 24hrs unless GW is power cycled). So…besides doing work to migrate in the V2 & V3 consoles or via CLI how are you physically redirecting your GW’s to correct V3 server/cluster address?
(#) for several TTIGs I, and many others, still have the problem that we dont have the WiFi code saved locally (claiming code) required for claiming & migrating remotely deployed/inaccessible TTIGs as this is part of the ‘proof of ownership’ & claiming processs required by TTI - despite me or others ‘owning’ the device in V2 - ah well - bureaucracy 
(Fortunately, I did manage to pursuade the host of a GW deployed in Hamburg - to crawl on hands and knees into space where one was deployed and take a picture for me so I could claim/migrate remotely - dodging a near 2000km round trip 
Ok would never have happened it would have become abandonware…Similar story for one up in the Tyne Valley - a meer 980km round trip! 
)
Thank you for your response. As far as i understand I have to change manually the server address (just one line of code) from “router.eu.thethings.network” to “eu1.cloud.thethings.network” (gateways are based in Europe). The only way to do this by remotely accessing the gateway right? My gateways are based on the IMST iC880a board and I built them using a Raspberry Pi by following the known guide (see previous posts for the link).