Migrating GPS devices without reflashing them

The assumption worth checking

Most operators assume that changing platform means touching every device. It usually does not. A tracker reports to a host and port it holds in configuration, and that configuration is normally changeable over the air with an SMS or a command from the existing platform.

If the new platform can decode the protocol the device already speaks, the migration is a redirect rather than a re-installation.

What has to be true

Three conditions, all checkable in advance:

• The device supports remote reconfiguration of its server endpoint — most commercial trackers do.
• You can reach it to send that command, via the incumbent platform or SMS to the SIM.
• The receiving platform decodes that protocol as it is, without asking the device to change how it speaks.

Migrate in waves, never all at once

Move a handful of devices first and let them report for several days. What you are looking for is not whether positions arrive — that is obvious in minutes — but whether the long tail behaves: ignition events, power loss, the once-a-week message that only appears under a condition you did not think to test.

Keep the old platform receiving until the new one has been correct for a full billing cycle. Running both is cheap. Discovering a decoding gap after decommissioning is not.

The devices that break a migration are rarely the common ones. They are the three units on old firmware nobody remembers deploying.

This is not hypothetical

AsiaTelco devices run on Nexara today because they were carried over from an earlier deployment rather than replaced. The hardware kept reporting through the change — no truck rolls, no reflashing, no re-installation.

That is the ordinary case, not a special one. If the receiving platform speaks the protocol the device already speaks, moving platforms is a configuration change to the device, and configuration changes travel over the air.

Send the command, then verify it landed

Redirecting a device is one command. Knowing it worked is the part people skip.

A device that accepts a server-change command and then fails to reach the new endpoint will often fall back to nothing at all rather than to its previous host — it is not lost, it is sitting there reporting into a socket nobody is listening on. From the old platform it looks migrated. From the new one it never arrived. Nobody notices until a customer asks where a vehicle is.

So the check is not "did the command send" but "did this specific IMEI appear at the new endpoint". Reconcile by device, not by count, and keep a list of the ones that have not shown up.

Migrate by IMEI reconciliation. A dashboard showing message throughput will look healthy while a tenth of the fleet is reporting into the void.

SIM, APN and the things that are not the tracker

A device redirect assumes the device can reach the new host. That assumption fails in ways that have nothing to do with the tracker.

Some SIMs are provisioned on private APNs that only route to the incumbent platform’s addresses. Some are locked to a carrier account controlled by the vendor you are leaving. In both cases the device will obediently accept a new endpoint and then be unable to reach it, which looks identical to a decoding failure and is not.

Check the connectivity path before the protocol path. If the SIMs travel with the incumbent, the migration is a SIM swap as well, and that does mean touching hardware.

Keep a way back

Until the last batch is confirmed, every device you move should be one command away from returning to where it was. That means keeping the old endpoint details, keeping the incumbent account open, and moving in batches small enough to reverse in an afternoon.

The cost of running both platforms for an extra month is a rounding error against the cost of discovering a systematic decoding gap with no route back.

A migration sequence that works

Order matters more than speed:

• Confirm the receiving platform decodes your protocol as the devices currently speak it — a packet capture settles this.
• Move three to five devices, chosen to include your oldest firmware, not your newest.
• Watch for a full week. Positions appear immediately; the interesting behaviour does not.
• Move a representative tenth of the fleet. Keep the incumbent receiving in parallel.
• Move the remainder in batches you can reverse.
• Decommission only after a complete billing cycle of correct behaviour.

What to watch in the first week

Position frequency against expectation — a device reporting every five minutes instead of every thirty is a configuration that did not carry over, and it will show up on the cellular bill before it shows up on the map.

Ignition and power events, which are the most commonly mis-decoded fields because they live in vendor-specific status bits.

Devices that went quiet. A tracker that stops reporting after a redirect usually has the old endpoint still in a secondary slot, or lost the command entirely.

A silent device is the failure mode that looks like success on a dashboard measuring throughput. Count reporting devices, not messages.

The incumbent is a party to this

Every step so far assumes the platform you are leaving will help, or at least not interfere. Worth confirming early, because two of the three preconditions depend on them.

Sending a server-change command usually means sending it through their console. Exporting history means using their export. Both are things a vendor can be slow about once they know why you are asking. None of that is sinister — it is simply not their priority — but it does mean sequencing matters: get the export and confirm command delivery works before the relationship becomes a notice period.

Check the contract too. Auto-renewal dates and minimum terms decide when the migration has to finish, not the engineering. A technically complete migration that lands a week after a renewal locks you into another year of paying for a platform nobody uses.

Read the termination clause before the protocol documentation. The contract sets the deadline; the decoder only sets the effort.

Decide what your customers are told

A migration is invisible to the end customer when it goes well, which tempts operators to say nothing at all. That is usually right, with one exception: anything that changes what they see.

If history does not come across, a customer who opens the platform expecting last quarter’s trips finds an empty screen and concludes the product broke. Told in advance that history starts fresh on a given date, the same screen is expected. The event has not changed; the framing has.

The same applies to a new login domain, a different app, or a re-branded portal. Decide the list of visible differences before the first batch moves, and send it once rather than answering it thirty times.

What you cannot take with you

Live positions move. History usually does not, or not easily — every platform stores it differently, and export formats range from a documented API to a CSV someone generates by hand.

Decide early whether history matters. If it does, treat the export as its own project with its own timeline, rather than an afterthought at cutover.