Migrating from The Things Network to ChirpStack: Step by Step to Your Own LoRaWAN Instance

WZ-IT operates chirphost. Current hosting starts from €129.90 net/month; setup and service level follow the proposal. Former package prices, location lists and cost comparisons in this dated article describe the previous offer, not current WZ-IT terms. View current service scope.

The Things Network is the entry point into LoRaWAN for many teams, and rightly so: free, a worldwide community, up and running in minutes. But the Sandbox has clear limits: the Fair Use Policy allows an average of 30 seconds of uplink airtime per device per day and at most 10 downlinks [1][2], and it is officially intended only for non-commercial testing and experimentation [3]. Moving to The Things Stack Cloud solves that, but ties cost to device count: from 230 US dollars per month for 1,000 devices, as a USD list price as of August 2026 [4]. Switching to your own ChirpStack instance instead gives you full control and predictable costs. This guide shows in four steps how to export devices, switch gateways and avoid the typical pitfalls, and it says honestly when you are better off staying with TTN or The Things Stack.

Why operators are outgrowing TTN in 2026

The Fair Use Policy in numbers

The Fair Use Policy of the TTN Sandbox is not fine print, it is the business foundation of the community network. The TTN documentation states 30 seconds of uplink airtime per device per 24 hours and 10 downlink messages per device per day [1]. The official Fair Use Policy post by the TTN team clarifies both values: the 30 seconds apply on average, and the ACKs for confirmed uplinks explicitly count toward the 10 downlinks [2].

What 30 seconds mean in practice depends on the spreading factor. The following values are calculated (10 bytes of payload plus 13 bytes of LoRaWAN header, EU868, 125 kHz, coding rate 4/5) and can be verified with The Things Network's airtime calculator [16]:

The consequence: devices at the cell edge on SF11 or SF12 collide with the policy first, and the 10 downlinks disqualify confirmed-uplink designs and actuator-heavy applications. Your self-check before the migration decision: pull transmit intervals and spreading factors from the TTN console and hold them against the table.

Non-commercial means non-commercial

The second limit is the intended purpose. The Things Industries describes the Sandbox as a "free and limited version of The Things Stack" without guarantees and without an SLA, intended for "non-commercial, small scale testing and experimentation" [3]. A productive smart-metering project with customer contracts does not belong there, and an audit or a tender will ask exactly this question sooner or later. This is not a reproach against TTN: the community network made LoRaWAN big and remains the right choice for prototypes and community projects. It is just not a foundation for commercial operation.

The Things Stack Cloud: fair, but per device

The official graduation path leads to The Things Stack Cloud. The free Discovery tier covers up to 10 devices and 10 gateways, without an SLA [4]. Cloud Standard costs 230 US dollars per month including a license for 1,000 end devices, with a 99.9 percent SLA and unlimited gateways; beyond that, the price scales with device count [4]. The USD list prices with monthly billing, as of August 2026 [4]:

Annual billing is cheaper, with the base tier then equivalent to 190 dollars per month [4]. This is a fair cloud offering with an SLA, just a model in which costs grow with fleet size. The fundamental architecture and feature comparison is in ChirpStack vs. The Things Stack; this guide covers the move itself.

Before the migration: the inventory

A clean inventory determines how long the migration takes. These five points belong on the list:

• Device list with key material: DevEUI, JoinEUI (AppEUI) and application key per device, plus the network key for LoRaWAN 1.1. Request root keys that only the hardware manufacturer holds now, not on migration day.
• LoRaWAN versions per device type: MAC version (1.0.2, 1.0.3, 1.0.4 or 1.1.0) and regional parameters revision, as stored in the TTN console.
• Gateways including access: model, packet forwarder type (Semtech UDP or Basics Station) and whether the configuration can be changed remotely or only on site.
• Integrations: webhooks, MQTT subscribers, payload decoders and downstream systems that need to point to the new endpoints after the move.
• Downlink and rejoin reality: which devices can be rejoined via power cycle or command, and which hang hard to reach in the field? This answer determines whether the OTAA rejoin standard path is enough.

Step 1: Set up the target environment

The target platform is ChirpStack, an open-source LoRaWAN network server under the MIT license, written in Rust, supporting LoRaWAN 1.0.x and 1.1, device classes A, B and C, and multi-tenancy. The project ships at a high cadence: the current stable version v4.19.0 was released on 9 July 2026, including per-tenant DevAddr ranges and improved downlink gateway selection [9]. Whether you run the instance yourself (PostgreSQL, Redis, MQTT broker, updates, monitoring) or consume it as a managed instance is an operations decision; the trade-off is covered in depth in ChirpStack Hosting: Managed vs. Self-Hosted. Hardware fundamentals for gateway procurement and radio planning are in the guide Building a private LoRaWAN network.

In the fresh instance, create the device profiles first; they define MAC version, regional parameters revision and activation type per device type. You can save manual work here: ChirpStack imports the lorawan-devices repository as device-profile templates via the command line [12], from which you derive the profiles for your device types.

Step 2: Export devices from TTN

There is an official tool for the export: ttn-lw-migrate exports individual devices, ID lists or entire applications as JSON, configured via environment variables and the cluster address, for example eu1.cloud.thethings.network:8884 [5]. The documentation recommends verifying commands first with --dry-run (add --verbose for more output) [5]:

export TTS_APP_ID="my-project"
export TTS_APP_API_KEY="NNSXS...."   # API key with device read permissions

# Dry run first:
ttn-lw-migrate application --source tts "my-project" --dry-run --verbose

# Then export as JSON:
ttn-lw-migrate application --source tts "my-project" > devices.json

# Export without active sessions (matching the OTAA rejoin):
ttn-lw-migrate application --source tts "my-project" --tts.no-session > devices.json

Since version 0.9.0 of October 2023, the tool supports exporting from The Things Stack; active sessions are exported by default and can be excluded with --tts.no-session [8]. One point belongs here honestly: ttn-lw-migrate was built by The Things Industries for migrations to The Things Stack or between TTS deployments. There is no official TTS-to-ChirpStack importer. On the way to ChirpStack, the exported JSON serves as a clean, complete data export (DevEUI, JoinEUI, keys, LoRaWAN and regional version); you handle the import via the ChirpStack web UI, or for larger fleets via the gRPC API or a small script.

Step 3: Switch the gateways

Gateways are packet forwarders, so the migration is a configuration change, not a hardware swap. The ChirpStack Gateway Bridge supports three backends: the Semtech UDP Packet Forwarder (default bind UDP port 1700), ChirpStack Concentratord and Basics Station with a WebSocket listener on :3001, optionally with TLS [10]. Concretely: with the Semtech UDP Packet Forwarder you enter the address of your Gateway Bridge as the server; with Basics Station you switch the LNS URI to the WebSocket endpoint. The Things Industries also provides its own gateway migration guide [7]; the principle is the same, the endpoint changes, not the radio behavior.

The order matters. As soon as a gateway moves, Sandbox devices in its area that have not yet migrated can only reach the TTN network through other community gateways, if any exist. So plan: target instance first, then the gateway, then the devices in waves. For critical fleets, a staggered move with a second gateway is worthwhile, so both networks have coverage during the transition phase.

Step 4: Create devices in ChirpStack and rejoin

The standard path is the OTAA rejoin. You create each device in ChirpStack with its DevEUI and matching device profile and store the application key under the "Keys (OTAA)" tab, plus the network key for LoRaWAN 1.1 devices [11]. Then you trigger a new join, via power cycle, a downlink command on the old network or the firmware's rejoin function. The result is a fresh session with clean frame counters and correct regional parameters from the join accept.

Special case: session migration

For devices that cannot rejoin, such as permanently installed sensors without a reachable rejoin mechanism, session migration remains: take DevAddr, session keys and frame counters from the export and set them in ChirpStack as the activation, analogous to ABP activation via the activation tab or the API [11]. The Things Industries itself puts it verbatim: "Please keep in mind that migrating active sessions is not recommended." [6] Treat this path as an exception with a heightened duty of care: frame counters must be continued exactly, the MAC state never matches one to one, and RX parameter differences lead to silent downlink failures.

The five most common pitfalls

1. MAC version and regional revision set incorrectly: The device profile must match the firmware. A wrong MAC version (1.0.2 instead of 1.0.4) or regional parameters revision shows up as failing joins or MIC errors and, in practice, costs the most debugging time.
2. Key mapping for 1.0.x vs. 1.1: LoRaWAN 1.0.x has one root key (AppKey), LoRaWAN 1.1 separates AppKey and NwkKey and splits the session keys [11]. Do not mix up the fields when transferring from the TTS export.
3. Frame counters during session migration: If the counters are not continued exactly, the server discards the frames. Devices with 16-bit counters and reset behavior are particularly error-prone, another argument for the OTAA rejoin.
4. Forgetting the JoinEUI/AppEUI: Some firmware only accepts join accepts with exactly the programmed JoinEUI. The values registered with TTN belong unchanged in the ChirpStack device setup.
5. RX1 delay difference: The Things Stack configures the RX1 delay to 5 seconds by default, according to the documentation to accommodate high-latency backhauls and peering with Packet Broker [13]. The ChirpStack region configuration for EU868, by contrast, sets rx1_delay = 1, configurable from 1 to 15 seconds [14]. Session-migrated devices keep transmitting with the old 5-second value while the new server responds after 1 second: downlinks and MAC commands go nowhere. Remedy: set the RX1 delay to 5 seconds in the ChirpStack region configuration, or simply let the devices rejoin.

Sandbox, tiers or flat rate: putting the costs in context

Agree scope and provisioning with WZ-IT. Provisioning and contract terms are agreed with WZ-IT in the proposal. There is no self-service portal or automatic trial subscription.

When you should not migrate

Three cases speak clearly against migrating:

• You need third-party community coverage. Wearables, asset tracking across cities, projects whose coverage lives on community gateways: only the TTN ecosystem provides that. Your own ChirpStack instance only sees your own gateways.
• You need roaming across network boundaries. If peering and cross-network roaming via the Packet Broker ecosystem are a must, The Things Stack Cloud is the right home; ChirpStack has no global settlement network.
• Your fleet is small. For prototypes, education and community projects, the Sandbox remains ideal, and up to 10 devices and 10 gateways the free Discovery tier of TTS Cloud is enough [4].

If none of these points apply and limits, intended purpose or the per-device tiers are hurting, there is a strong case for the move. The fundamental platform trade-off beyond the migration mechanics is covered in the comparison ChirpStack vs. The Things Stack.

GDPR and the EU Data Act in brief

For operators in the DACH region, the move has a compliance side. LoRaWAN payload data can be personal data, for example with smart metering or presence sensing. A dedicated instance in a German data center simplifies the documentation: a clear processor, a data processing agreement, no shared community network in the data path. This is not a compliance verdict on TTN or The Things Industries, which as a Dutch company operates EU clusters such as eu1; the point is control, tenant separation and contractual clarity. In parallel, the EU Data Act raises the requirements for data access and portability for connected products; the details including the deadline are covered in The EU Data Act and LoRaWAN. This section is a technical and organizational classification, not legal advice; binding assessments belong with your data protection and legal counsel.

Outlook: migration is becoming a standard feature

The network switch this guide describes is manual work today, but the industry has officially put the topic on its agenda. On 1 June 2026, the LoRa Alliance presented a 3-year roadmap that explicitly announces "new features for supporting migration of IoT-connected devices from one network to another" for 2026 [15]. Migration between LoRaWAN networks is thus set to turn from a project into a standard capability. A lot is happening on the target platform in parallel: after v4.18.0 of 11 May 2026 and v4.19.0 of 9 July 2026, testing of v4.20.0 was already underway at the end of July [9]. And the operator market is consolidating rapidly, as the Netmore-Actility acquisition shows; why that matters for the question of control is analyzed in Netmore Acquires Actility. If you plan the move cleanly now, you benefit twice later: from the coming standard features and from a stack that is already portable today.

Conclusion

Migrating from The Things Network to ChirpStack is no dark art, but a plannable process in four steps: inventory and target environment, device export with ttn-lw-migrate, gateway switchover to the Gateway Bridge, then OTAA rejoins in waves. The rejoin is the standard path; session migration remains the documented special case with RX1 delay caution. Those who need community coverage or Packet Broker roaming, or who do fine with 10 devices on the Discovery tier, should stay. Those who operate commercially, hit fair-use limits or prefer a flat rate over per-device tiers should migrate: with their own instance, their own keys and their own data.

What running your own instance covers day to day is on the rent a LoRaWAN network server page, and the compliance side under security and data locations.

The Things Network, The Things Stack, The Things Industries, LoRa, LoRaWAN and LoRa Alliance are trademarks of their respective owners. ChirpStack is an independent open-source project; chirphost is not affiliated with The Things Industries or the LoRa Alliance. References serve objective classification only.

Sources

1. The Things Network Docs: Duty Cycle and Fair Use Policy
2. TTN Forum: Fair Use Policy explained (official post by the TTN team)
3. The Things Industries Docs: The Things Stack Sandbox (concept and intended use)
4. The Things Industries: The Things Stack Plans (pricing and tiers)
5. The Things Industries Docs: Export Devices from The Things Stack (ttn-lw-migrate)
6. The Things Industries Docs: Migration FAQ (session migration not recommended)
7. The Things Industries Docs: Gateway Migration
8. GitHub: TheThingsNetwork/lorawan-stack-migrate, changelog (tts source since v0.9.0, --tts.no-session)
9. ChirpStack: GitHub releases (v4.19.0 of 9 Jul 2026, MIT license)
10. ChirpStack Gateway Bridge: documentation (backends and configuration)
11. ChirpStack Docs: Devices (OTAA/ABP keys and activation)
12. ChirpStack Docs: Device-profile templates (importing the lorawan-devices repository)
13. The Things Industries Docs: Device MAC Settings (RX1 delay default 5 s)
14. ChirpStack: region_eu868.toml (rx1_delay default 1 s)
15. LoRa Alliance: 3-Year Roadmap for Scaling LoRaWAN Globally (1 Jun 2026)
16. The Things Network: Airtime Calculator