A connected pump comes back online after its gateway is replaced. The dashboard turns green, but its service history is attached to the old device identifier. Buffered readings arrive after newer ones. A maintenance rule interprets an old measurement as the machine's current condition.
For Swedish equipment operators, the mobile network transition is an opportunity to fix this fragile connection between hardware and software. Buying a compatible modem is one part of the work. Keeping the equipment understandable to dispatchers, technicians and customers requires an application migration plan as well.
Establish which transition applies to your fleet
In its May 2026 update on the network transition, Sweden's Post and Telecom Authority describes the principal 2G and 3G closures undertaken during 2025 and notes Telia's announced plan to retain its 2G network until the end of 2027. A national headline does not identify the network used by each device in your fleet.
Telia's own IoT migration guidance explains that equipment may require hardware, component or software changes, and that voice-dependent functions need separate attention. These are operator-specific statements reviewed on 12 October 2026. Confirm current support with the actual connectivity and equipment suppliers before selecting a replacement.
Build an inventory around operational responsibility: the asset, installation location, device model, firmware, subscription, owner and business function. An invoice for a mobile connection is not sufficient evidence that the equipment's complete service will continue to work.
Separate the machine from its communications hardware
The machine needs a stable identifier that survives a modem, SIM or gateway replacement. Each communications component should have a separate identity and an installation period. The platform then knows which component supplied a reading at a particular point in time.
This distinction also prevents accidental duplicates. A technician should be able to commission replacement hardware against the existing asset, with an explicit check that it is the correct installation. Automatically creating a new machine whenever an unfamiliar device connects fragments the maintenance record and can leave two active customer records for the same equipment.
Give the field team a practical commissioning screen. It should show the asset they are changing, the old connection, the replacement and the expected telemetry. Record who completed the work and which checks passed. A scanned label helps identify equipment; it does not prove that the wiring, measurements and account association are correct.
Give readings both an observation time and an arrival time
An application needs to distinguish when a measurement was taken from when the server received it. During a connection outage those times may be far apart. If the platform stores only the arrival time, historical data can look like a sudden change in current conditions.
Preserve the source timestamp, reception timestamp and any sequence information supported by the device. Define what happens when clocks are inaccurate or sequence counters reset. The interface should make uncertainty visible rather than silently invent a precise order that the available evidence cannot establish.
For an illustrative demonstration, disconnect a test gateway while it continues collecting measurements. Reconnect it after a newer reading has arrived through another permitted route. The historical chart should incorporate the late data appropriately, while the current-state view should follow the agreed freshness rules. These are distinct outputs with distinct purposes.
Design recovery before deciding how much to buffer
Local buffering can make intermittent connectivity more manageable, but it has limits. The device has finite storage, may lose power and may not retain every event. Ask the supplier what the supported hardware can actually preserve before designing an application around perfect replay.
The software should identify duplicate data and avoid processing the same business consequence twice. An uploaded reading and an instruction sent back to equipment also need separate treatment. A historical measurement may be useful after a delay; an old control instruction may no longer be appropriate to execute.
For an initial migration, keep automatic control outside the pilot unless its safety and operational requirements have been expressly scoped with the equipment owner. A visibility and commissioning project can deliver useful evidence without quietly assuming responsibility for every machine action.
Retire the old connection deliberately
An installed replacement does not automatically revoke the previous gateway's credentials. Keep a commissioning checklist that includes account permissions, device credentials and the status of the old connection. A retired device should not continue to submit trusted information simply because it remembers a valid secret.
Apply access by role. A technician may need to see installation details and current readings without accessing every customer's contract or all historical exports. Support should be able to investigate a connection problem through useful diagnostics that exclude device secrets and unnecessary personal information.
Also record which team owns the boundary between hardware, connectivity and application behaviour. When a device stops reporting, the customer should not be sent repeatedly between three suppliers who each claim that their own dashboard is green.
Buy a representative migration, then expand it
Choose a small group that exposes the important variations: older firmware, difficult reception, a long offline period and equipment with a different reporting pattern. The number should follow the diversity of the fleet, rather than an arbitrary promise that a handful of convenient devices represents everything.
Ask for a migration register showing each asset's readiness, prerequisites, completed checks and unresolved issues. Include an explicit fallback procedure for an unsuccessful installation. Preserve the existing platform's history and exports before changing mappings so the business can reconstruct what happened.
Acceptance should cover a gateway replacement, duplicate readings, clock drift, credential revocation and a device that stays silent. Check how the dashboard communicates stale information and how the support team identifies the next action. Track outcomes using your own baseline, such as unresolved commissioning cases and assets without a recent confirmed reading.
Our guide to IoT security for connected devices covers the access and lifecycle questions. The article on edge computing use cases helps evaluate which processing belongs near equipment and which belongs in the central service.
TuniCyberLabs can modernise the application and integration layer through custom software development. Describe your device families, current telemetry platform and migration constraint to define a pilot that preserves operational knowledge while the connectivity changes.