If I recall correctly @johan wrote in chat that
“V2 GWs are fully connected to V3, for UL, DL and activations. However, GWs that are directly connected to V3 (new or migrated) will not route back to the legacy V2 environment”
So, I believe that a make-before-break approach would dictate to first move your applications to V3 and then migrate your GW to V3. Is this assumption correct?
Note: This message was moved here from another thread.
As understood in the TTN conference there are some things you need to know and arrange before you consider moving the gateway from V2 to V3. You may break things 
So, summarizing :
HT @kersing @johan @pe1mew for clarifying.
What more should you consider or definitely not do?
Note: This message was moved here from another thread.
Since we started this entire journey, it has been our goal to create a worldwide LoRaWAN ecosystem. We’ve done this with our public community network, but we also wanted to do this for other public and private networks. That’s why last year we announced Packet Broker.
With Packet Broker, different networks (but also clusters within the same network) can exchange traffic with one another. We call this peering. In this peering relationship, there are two sides:
The Things Stack (v3) can be both a Forwarder and Home Network (at the same time), while our V2 implementation is only a Forwarder. This means that two v3 clusters can have bidirectional peering, while a v2 cluster can only be the “gateway side”.
For the next couple of months it gets a bit confusing, since The Things Network now has both v2 clusters and v3 clusters. Between the different v2 clusters, there is full bidirectional traffic exchange (although that has always been a bit flaky). Between the different v3 clusters, there is full bidirectional peering through Packet Broker. You can have your gateways on v2 and your applications on v3. But you can not have your applications on v2 if your gateways are on v3.
One possible problem is V2 Application support will stagnate/wither on the vine as new V3 GW’s deploy they wont help coverage for V2 applications, and existing V2 GWs that get migrate to V3 will stop servicing V2 devices/applications - even if they historically did so. Coverage for V2 devices/apps will therefore decline and already deployed devices will in many cases stop working!.
Message appears therefore to be deploy no new V2 devices or apps… the network has just been Osborned! 
Or am I reading this wrong? 
My recommendations would be:
I posted some generic information here: The Things Network upgrade to V3
Let’s discuss the migration from V2 to V3 here.
I understand the potential coverage issue that may occur when migrating gateways now from V2 to V3.
What is highly advised is to migrate devices as soon as possible to V3. Gateway coverage is already there. We support all application level integrations as we do in V2, including storage API, MQTT and webhooks.
See Migrating from The Things Network Stack V2 | The Things Stack for LoRaWAN. When you migrate, you can convert your V2 devices to ABP devices, i.e. remove the AppKey, so the end device will not join on V2 anymore.
Then, if your device has a mechanism to detect link loss (missed acks, missed ADR acks, link check misses etc), it will revert to join mode and join automatically on V3.
So the order would be:
What about V2 devices without OTAA? Nearly all of my devices and many more here in the Community are only based on ABP and not OTAA.
See https://www.thethingsnetwork.org/forum/t/the-things-network-upgrade-to-v3/43256:
- Activation by personalization (ABP) devices, i.e. devices that have a fixed DevAddr and session keys, are personalized for a specific network, in this case, The Things Network V2. You should consider V3 as a new network. So if you want to keep using ABP and you cannot use over-the-air activation (OTAA), it is highly recommended to create a new ABP device in V3 and reconfigure the device with the new session. Note that the (default) RX1 delay has changed from 1 to 5 seconds.
Ok so during the conf a user opens his/her TTN Console page (the current ‘public’ face & most used start point for users?), goes to Applications - add new application - will that automatically be in V3 now or will it still be V2?
We need this to be V3 ASAP if we are not to then orphan devices & apps starting now (that also create a big workload revisiting apps and devices to migrate). Going OTAA ok - but if devices dont restart (for a long time - given one feature called out for devices on LoRa is long battery life 
) then they will likely be abandoned if not economic to make field visits to ‘fix’…
V3 is available now, but the default Console is still V2 indeed. We need to put a banner there. Also we need to show the cluster overview on thethingsnetwork.org so that it is clear what the host names are and where to go. There’s still quite some work to do on our side.
As said in the keynote, V2 will become readonly from April. So from then, it will not be possible anymore to add new applications and gateways. By then, we should have the right navigation and user experience in place to make sure that people go to the right place. That also means that by then, we need to have nam1 and au1 deployed, and potentially one is Asia Pacific too.
Thanks for clarifying/confirming Johan. Looks like its the apps/devices that is the killer for now given existing V2->V3 routing for GW’s already seem sorted (with packetbroker 
) I will hold new device/app deployment for a few days/weeks where I can whilst matters settle and use as excuse to force myself to look deeper into V3 (was hoping that migration would be a ~Q2 task but given April timing that accelerates matters from last Mods heads up!).
Please do amend Console Apps page to forewarn users with a Use V3 Banner ASAP as I can see much nashing of teeth ahead!
Regarding Packer Broker peering:
I understand that TTN gateways (V2 and V3) are already sending traffic to TTI devices.
Are also TTI gateways routing traffic to TTN V3 devices?
Hello, what is the workaround on eu1.cloud.thethings.network for a blank screen after login? I have tried changing my password and used Chrome on Windows and FF on Ubuntu, with standard security settings.
btw: I don’t get a blank screen (on oauth url) with our private instance of V3, login works as expected.
Thanks Mike.
We’re working on this!
That depends on the customer. Some do, some don’t. The basic rule is that there needs to be some balance; we don’t want leeching. For now, we show them the benefit of TTN coverage, and tell them that it doesn’t cost anything to allow offload (uplink) traffic back to TTN. Now, whether downlink will be supported is another issue. We support downlink prioritization in V3, so private TTI networks may support downlink but only if they have capacity left. We’ll see!
We are working on a fix that will be deployed shortly. cc @bafonins
I’m currently writing a number of scripts utilizing the Application Management API. Should I wait and see, or can I rely on V2/V3 compatibility?
How should we move “The Things Indoor Gateways” from V2 to V3?
The FAQ from the Gateway say:
Q. I want to delete and re-create (re-register) TTIG. Can I do that?
This is definitely not recommended since you cannot recreate a gateway with the same EUI on the same network. We do this to prevent violation of uniqueness on the EUI.
Do not delete at this time. Looks like no rush to migrate such GW’s yet as the data is being forwarded through to V3 infrastructure back end already Another good thing to do at time of migration is upgrade GW’s to using BasicStation - but the TTIG is already running that so no immediate imperative…
This is fundamental for the migration to be successful.
Does any of the popular stacks support detecting the need for a rejoin automatically? In particular, I assume most LMIC nodes do not do that.
There’s also the mention of migrate while keeping the security session but that breaks the suggested strategy of migrating apps first and gateways later, because keeping the security session only works if gateways are v3.
This is also what I’m unsure of, and I’d love to know what the community thinks. Unfortunately there’s no “LoRaWAN stack” indicator in the join-request message; we have no statistics about this.
Yep. Even if we were routing traffic back from V3 to V2, we wouldn’t make the RX1 delay of 1 second that is used in V2. Gateways would really need to be connected to the cluster where the end device is, to make that short roundtrip.
Also we discussed this internally again today, and what’s also going to be super helpful is a gateway map that shows to which cluster (and version) the gateway is connected.
For now, it’s not necessary to migrate gateways from V2 to V3, so I would suggest waiting with that. New gateways can go to V3 though.