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).
Are they set up using e.g OpenVPN access or similar (Normal RPi OS images - Raspian etc include a VPN option - but you need to configure…) such that you can log in remotely? If not you will have to access directly and edit appropriate local_conf.json or global_conf.json files to edit server address & if needed ports, potentiall add API key etc - will all depend on what config/firmware builds & PF config you have used - sorry no time to go off following links etc. From what I have seen most users of such have followed e.g. the TTN Zurich or Technoblogy derivative builds or one of Charles Hallard’s or his Ch2i builds if not using a Pi image from actual vendor (iMST had image for their Lite GW using same board.). Many are now looking at remote solution like e.g. Balena to allow remote fleet management - but that still requires a new uSD card image loading physically into the device to get you going. TL:DR likely you need to gain physical access…
The software used in that guide is very old and should probably be updated. Did you choose to use the remote configuration option?
@Ioannis_K, you said previously that you had successfully migrated a gateway a month back.
Can you not replicate that same actions?
How did you manage to change the gateway address on that gateway?
Hello again,
Unfortunately I am not the same person who setup these nodes. I took over the task of migrating all nodes and gateways from my boss. I do not know if they had enabled this option while the were building these nodes.
So I created the needed .json files with the correct server address using the relevants EUIs and now I am waiting my request to be accepted in GitHub. I believe I have exhausted all possibilities considering the fact that I have no physical access to the gateways.
Thank you all for your support.
If there was no file for the gateways in the repository there is little chance the installed gateway use the remote configuration method because there wouldn’t be a current configuration.
Is there no ssh access to the gateways? To migrate you don’t need physical access.
Thank you for your response!
Because gateways are located at different places around a city we are trying to get ssh access and make the needed change to the server address.
Unfortunately, there where no files in the repository for the gateways. I did a pull request 2 days ago but we are not sure that each gateway has been configured for remote configuration during setup.
Hello,
I experience same error as this topic. I have spend some hours to find out why, but can’t find a solution
I have 8 Cisco gateways I try to migrate from V2 to V3.
I have remote access to all gateways.
I created all gateways at TTN console with same EUIs I had on V2, but I choose another.Gateway ID.
I logged into to the gateway and changed in config.json:
“Gateway_ID”: “sunds”, (ID from TTN )
“server_address”: “eu1.cloud.thethings.network”,
I have changed nothing else
But in TTN console the gateways says “disconnected”
I have also tried to run the test with this command
/tools/pkt_forwarder -c /tmp/config.json -g/dev/ttyS1
I hope sombody can help to find a solution to this.
Thank you
Searching the forum comes up with lots of “Gateway ID on the Gateway is the Gateway EUI on the Console”
Make the config file on your Gateway have the Gateway EUI of the Gateway so it matches the Gateway EUI on the Console.
The Gateway ID on the Console is an ID for you to identify your Gateway using your own ID scheme.
If you click the “Download global_conf.json” button it will download a global_conf.json so you can see all the settings that you can copy over to your gateway.
This should be the EUI. I know it is confusing that in the LoRaWAN world we use the same name for different things but once you fill out the EUI you’re in business.
Hi Nick,
Thank you very much.
This was exactly what I needed. I have got the Gateway-ID wrong and have not seen the “Download global_conf.json” button
But now my gateway is connected and I can now change my other Gateways.
Hi Jac,
Thanks for your reply.
I changed the Gateway ID to EUI and now it’s connected.
Hi again
I got most of my gateways running with v3, but one gets after some hours this error:
ERROR: sx1301ar_parse_gga failed; Unspecified error code
Does anyone know why this error accur.
Thanks