The strategic case for LTE-M is usually settled before anyone reads a piece like this: the legacy networks are going, LTE-M is the designated successor for most low-power IoT, and the framework-level planning is covered in our sunset migration guide and the case for LTE-M itself. What remains is the unglamorous layer where migrations actually succeed or stall: modules, antennas, power budgets, firmware behaviour, SIMs and per-market network reality. This piece is about that layer.
Hardware: the module swap is never just a module swap
Replacing a 2G module with an LTE-M one looks like a line-item change and behaves like a small redesign. The recurring considerations:
Module and certification selection. LTE-M modules are mature and economical, but variants matter: regional band support, fallback options (some modules pair LTE-M with NB-IoT or 2G fallback, which can be a useful transition bridge where networks still exist), and the certification load for your target markets. Certification timelines belong on the project plan from day one, because they are routinely the long pole.
Antenna design. LTE-M operates across different frequency bands than the legacy radio your enclosure was tuned for, and band support varies by market. Antenna performance that was adequate at 900 MHz does not automatically translate; budget for antenna review and, for marginal enclosures (metal, underground, body-worn), for testing in the real mounting environment rather than on a bench.
Power profile changes. LTE-M’s headline power advantage is real but conditional: it is delivered through PSM and eDRX, the sleep mechanisms, and realised only if firmware uses them and the network supports the requested timers. A device ported naively, holding sessions open as its 2G predecessor did, can consume more than it used to. Battery-life claims for the migrated device should be re-derived from measured behaviour, not inherited from datasheets.
Firmware: the behavioural port
The firmware work divides into mechanical and behavioural. Mechanical: AT command set differences, new module integration, configurable rather than hard-coded connectivity parameters (the audit finding that haunts migrations, covered in our switching guide). Behavioural is subtler: LTE-M’s value emerges from a different rhythm of operation, batching transmissions to maximise sleep, negotiating PSM/eDRX timers, handling the longer wake-to-transmit latency those timers imply, and managing retry behaviour so a network blip does not burn the power budget the migration was meant to win.
One behavioural item deserves special attention for any device class with voice or real-time alarm requirements: confirm the module’s and market’s support for the specific capabilities you need (VoLTE for voice on LTE-M where applicable), per market, in writing, before hardware commitment.
SIM strategy: the cheapest insurance in the project
The migration touches every device, which makes it the rational moment to settle SIM strategy for the next decade rather than carry the old one forward. Three properties earn their place on the specification:
Multi-network access. A single-network LTE-M SIM re-creates the original sin of the legacy estate: dependence on one operator’s coverage and roadmap. Multi-IMSI SIMs with non-steered network selection attach to the strongest available network per site, which matters doubly during LPWAN’s ongoing rollout, where coverage maturity varies by market and operator.
eUICC capability. Soldered or removable, eUICC-capable SIMs mean the next strategic change, provider, profile, commercial terms, happens over the air rather than through another field programme. Having just priced a field programme, the argument tends to make itself.
Form factor for the environment. Vibration, temperature and lifetime should drive the choice between removable and MFF2 embedded formats, decided jointly with the hardware revision since it affects the board.
OV’s IoT SIM proposition covers this specification as standard: Multi-IMSI with non-steered selection, eUICC and SGP.32 alignment, industrial form factors, and management through OV ONE with full API access for the bulk operations a migration consumes.
Network validation: per market, per band, in writing
LTE-M coverage is broad and still uneven: deployment maturity differs between countries and between operators within them, and roaming support for LTE-M specifically (not just 4G generally) is its own question. The validation discipline per deployment market: confirm LTE-M availability on the networks your SIM can access, confirm the bands in use against your module’s support, confirm roaming behaviour for LTE-M where devices cross borders, and identify the fallback story where coverage is immature, which may legitimately be 4G LTE for some classes or markets.
This is a conversation to have with your connectivity provider against your actual deployment map, with OV that means validating against coverage spanning 180+ countries and 600+ networks, and then to verify empirically: trial SIMs in migrated prototype hardware, at your hardest real sites, before the hardware order is signed. A free IoT SIM trial placed at exactly this point in the project is worth more than any coverage map.
The pilot wave: prove the whole chain
Before scale, run one wave that exercises the entire chain end to end: migrated hardware, production firmware, target SIMs, real sites, and the operational workflow, provisioning through OV ONE or your platform of choice, consumption monitoring against the re-derived forecasts, alerting, and a deliberate support escalation. The pilot’s exit criteria should be written before it starts: attachment success rates, measured power consumption against the new battery model, data consumption against forecast, and no unresolved behavioural surprises. Waves after the pilot then follow the sequencing logic of the framework piece, accelerated by everything the pilot taught.
The pitfalls, collected
For the project checklist, the failures that recur: certification discovered late; antennas inherited untested; power budgets copied from datasheets rather than measured with real timer negotiation; hard-coded APNs surviving into the new firmware; voice or alarm capability assumed rather than confirmed per market; single-network SIMs re-creating the dependency the migration existed to escape; and pilots judged on attachment alone while consumption and power surprises ship to the full estate. Every one is cheap at planning time and expensive in the field, which is the entire economics of doing migrations deliberately.
Frequently asked questions
Can existing 2G devices be upgraded to LTE-M with a firmware update?
No; the radio hardware differs, so migration requires an LTE-M module, which usually means a hardware revision or device replacement. The firmware then needs porting work beyond the mechanical, particularly around power-saving behaviour, since LTE-M’s efficiency depends on PSM and eDRX being used properly.
Does LTE-M use less power than 2G?
It can use substantially less, but the saving is conditional on firmware exploiting sleep modes and the network supporting the requested timers. A device ported without behavioural changes can consume as much or more than before, which is why battery models should be re-derived from measurement on migrated hardware.
Is LTE-M available everywhere 2G was?
Not uniformly; LTE-M deployment maturity varies by market and operator, and roaming support for LTE-M is a separate question from 4G roaming. Validate availability and bands per deployment market with your provider, and keep a per-class fallback position (often 4G LTE) where coverage is still maturing.
What SIM should a migrated LTE-M estate use?
The migration is the moment to specify multi-network, eUICC-capable SIMs: Multi-IMSI with non-steered selection for resilience across operators’ varying LTE-M maturity, and eUICC so future strategic changes happen over the air. Carrying a single-network SIM strategy into the new estate rebuilds the dependency the migration was meant to remove.
