But clearing, not changing, will mean we don’t have a fall net (v2) if the migration failed.
Currently I have an issue with my device experiencing packet loss on V3, while the same packets are received on V2.
One way migration makes it very difficult to debug.
Okay, that makes sense. I just deployed a quick change that should allow you to change the AppKey.
Tried changing AppKey again tonight (just now) and still seeing cant be saved error message 
Enquiring minds would like to know why you don’t have a handful of devices & a couple of gateways running on a login that’s not directly connected to a staff level account so you can try this stuff yourself? Surely as quick to try as it is to type a request for someone who may then not test it as you expect & then give you duff information …
Asking for a friend who’s trying to rip me a new lower waste orifice as their frustration levels with migration make an outbreak of the T-Virus in the Hive at the Umbrella Corporation look like a company picnic. I think they are alluding to all the zombie devices they anticipate owning in Jan '22.
All of my test devices have been migrated to V3 a long time ago, so no, I don’t have anything left on V2.
…And of course he cant add any more now! 
That’s a bit unfortunate - how did you plan to test the migration after going read-only?
Surely TTI has a test setup still?
Just tried an un-used device on V2 and I can swap the octals in the last byte of the AppKey for an OTAA device 
Can we have the same ability for ABP devices please.
Ah good to know - will go try shortly…
Also discovered cant edit general info (I typically give a general location indicator in description - 1st part or post code etc - helps me scanning list when I only have anonymized eui-blahblah to work of quickly),
and worst still as you know I often relocate GW’s for trials and test deployments, community or client loans etc. and whilst I dont always change location in settings if I remember I like to change description and location on Map for longer term deployments - more than a few days…location cant be changed either. Not adding a new GW just ‘updating’ where in the world it might be, ah well (confuses the hell out of TTN Mapper! with some crazy links shown ;-)) 
As here:
Editing that worked! Changing front failed but selective edit possible…save failed initially as I also edited description to remind myself what I has changed, Dhoh! Removed reminder and all good, now see repeatedly able to trigger V3 joins and get stream of data. Integration added (Cayenne for now MQTT and other Webhooks later per ttsa! 
), and device deployed for collaborator/client who’s happy with a quick dashboard monitoring bulk water system:-)
Will nuke original V2 device/app reg later…
Changing the last two characters means it’s easy to change them back - don’t need to remember them.
Whatever I try, I really can’t change the AppKey in https://v2console.thethingsnetwork.org/applications/.../devices/.../settings. I aways get hit by the read-only error. Tried to strip down the call using curl, like:
curl 'https://v2console.thethingsnetwork.org/api/applications/st-production/devices/18000263306' \
-X 'PATCH' \
-H 'accept: application/json' \
-H 'authorization: Bearer ...' \
--data-raw '{"app_key":"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"}'
But I always get:
{"reason":"permission denied: V2 clusters are now read-only. Migrate your devices to a The Things Stack (V3) cluster now! V2 clusters will permanently shut down in December 2021."}
Also I tried ttnctl, same problem.
It looks like deleting the device in v2 is the only option possible currently. Which is a pain as I wanted to issue a rejoin downlink to get them on the v3 network.
I cannot change the AppKey. I cannot swap octals in the last byte or anything like that. I can only set to all zeros (clear). My application is using meshed-handler (Australia).
So it seems like the Meshed handler is running a slightly older version that does not contain a fix that allows this.
I’ve updated this now. Can you check and let me know if you can update the keys?
Yes, it is working now. Thanks!
OK, so I admit I am one of those who “forgot” to migrate several of my OTAA devices in really remote areas. Mainly because I couldn’t execute a rejoin remotely.
So… Thanks @htdvisser for the last reminder and your excellent The Things Network V2 Take-Out Tool!
Just to make sure: Since V2 is disabled now, the only steps necessary to migrate should now be to:
I have the same question as @tinubettler , since I tried simply creating new devices in V3 and it didn’t work.
I have 14 SenseCAP Temperature and Humidity sensor nodes that were previously used in TTN v2, and AppEUI, DevEUI and AppKey for each. SenseCAP sensor device’s AppEUI and AppKey have been flashed into the device by SEEED, and retrieved using their HTTP API. When I enter this information in V3 console, and try to register a new device, I get the following error:
" Submit failed
An end device with JoinEUI 8000000000000008 and DevEUI 2CF7F1212100024B is already registered as rufll-temp-5 in application rufll-temp-humidity,
which corresponds to the device and application previously registered in V2, with the following details:
{
“code”: 6,
“message”: “error:pkg/identityserver:end_device_euis_taken (an end device with JoinEUI 8000000000000008 and DevEUI 2CF7F1212100024B is already registered as rufll-temp-5 in application rufll-temp-humidity)”,
“details”: [
{
“@type”: “type.googleapis.com/ttn.lorawan.v3.ErrorDetails”,
“namespace”: “pkg/identityserver”,
“name”: “end_device_euis_taken”,
“message_format”: "an end device with JoinEUI {join_eui} and DevEUI {dev_eui} is already registered as {device_id} in application {application_id}",
“attributes”: {
“application_id”: “rufll-temp-humidity”,
“dev_eui”: “2CF7F1212100024B”,
“device_id”: “rufll-temp-5”,
“join_eui”: “8000000000000008”
},
“correlation_id”: “0ae288d518b54075ab690a831770746b”,
“code”: 6
}
]
}
With V2 disabled, does anyone have a suggestion on how to register these devices in V3?
Thank you