Unfortunatelly, the LoRaWAN 1.0.x spec does not define any standard way for having end-devices rejoin the same or another LoRaWAN network and generate new session keys. This is a big operation issue. Just image what happened if your production Network Server lost (because of a datacenter disaster) all session keys. All devices would be disconnected without having any way to reconnect. (LoRaWAN 1.1 introduces a new message type: rejoin request, that solves this issue.)
Device manufacturers usually implement proprietary solutions in the application layer of their firmware to let devices join the same or a new network after session keys are lost. The most common technic is that upon detecting that the Network Server stops answering to LinkADRReq MAC commands (for a certain period: e.g.: for 6 hours) , the device sends new JoinRequests until the new or recovered NS replies with a new JoinAccept so that new session keys can be created.
According to my experience 90% of the device manufacturer (but not all of them) implement this technic. Therefore I suggest the following procedure to move end devices from the old NS to a new one.
- Perform lab tests with all types of devices connected to your current network server and check if they really try to rejoin after a certain period of time not being connected. (You can remove the device from your current NS, and immediately provision it again so that you can be sure that it's session keys are deleted.)
- Remove all your devices from your current Network Server
- Provision all your devices on your new Network Server
- Visit those devices (<10%) that do not automatically rejoin upon not receiving LinkADRAns messages and restart them manually. (You must have identified all these devices during lab tests before you started the migration procedure)
- Wait until the rest of the devices rejoin to the new network.
This procedure is far not ideal, but there is currently nothing better.
(In theory you could copy the session keys device by device, from the old NS to the new NS but in practice it would require additional integration effort with your old and new NS vendor that would bee too costly.)