Moving a GPS service affects more than the map your customers see. Trackers may need new configuration, users need the right access and historical records may remain in a different system. Plan the transition around these dependencies before choosing a cutover date.
This checklist helps service providers and fleet operators prepare a migration discussion. The exact work depends on the current provider, device models, available exports and the agreed destination platform. Historical-data transfer and uninterrupted service should be assessed explicitly.
What to take into the discussion
- Inventory devices, users and essential workflows before changing a connection.
- Assess historical-data access separately from future device reporting.
- Use a representative pilot, staged rollout and agreed rollback criteria.
1. Map the service you are moving
List device models, approximate quantities, customer groups and the people who administer the service. Include the web and mobile experiences, event rules, reports and integrations customers rely on. Identify anything that would prevent normal work if it were missing after the move.
For each dependency, record who can change it and what information is needed. An installer may control device configuration, a customer may own a domain and a separate team may maintain an integration. Assign an owner to these tasks early so they do not become surprises during the cutover.
- Devices and configuration
- Exact models, variants, installed accessories and the authorised configuration owner.
- Users and customers
- Account groups, administrator contacts and the access each role requires.
- Operating workflows
- Essential events, reports, mobile apps and connected business systems.
2. Separate historical data from new reporting
Ask the current provider what you can export, in which formats and during which access period. Establish the records your business needs to retain, then check whether the destination can use those records in the intended way. Having a downloadable file does not establish that it can be imported into another platform’s history views.
Consider how users will consult older records if they remain in an archive or the previous system. Agree access, retention and the handover process with the relevant parties. Preserve the context needed to interpret exports, such as identifiers, time zones and units, without collecting unrelated customer data.
Record the decision before ending an existing service. A transition that changes where new positions are reported does not automatically migrate reports, attachments, event configurations or historical journeys.
3. Confirm how each tracker will connect
Validate the destination setup for the exact tracker models involved. Confirm who is authorised to change connection settings and whether a model can be reconfigured remotely or requires physical access. Obtain the correct instructions through the agreed setup channel.
Keep a record of the previous configuration through a secure operational process. Check the consequences of changing the destination: what will stop reporting to the old service, how the transition will be recognised and how the original settings could be restored if needed. Avoid assuming a device supports simultaneous reporting to two systems.
4. Prepare accounts and customer communication
Map the customer groups and permissions needed in the new service. Verify who should see each fleet and who can change configuration. Plan a secure account-provisioning or invitation process rather than moving passwords between systems or circulating them in ordinary messages.
Prepare clear instructions covering the verified sign-in address, app installation, access setup and the support contact. Explain which records will be available in the new platform and how users can access older information. If branding or app distribution changes, make those changes part of the communication plan.
5. Run a pilot that represents the real service
Choose authorised test objects that cover the relevant device types and important workflows. A pilot made only of one easy-to-configure model may leave the difficult part of the fleet untested. Agree acceptance checks before starting and assign someone to record the outcome.
Review actual received data, a sample journey, required reports, account permissions and configured notifications. For integrations, verify identifiers, authentication and error handling with the system owner. If a required result is missing or unclear, pause that part of the rollout and resolve it before adding more customers.
- Tracking and history
- Expected records arrive with interpretable timestamps and appear in the required views.
- Users and events
- Test users see the correct objects and configured events reach the intended recipients.
- Business continuity
- The people operating the service can complete the agreed essential tasks.
6. Agree rollout and rollback decisions
Group the move into manageable batches, for example by customer or validated device setup. Define the checks that must pass before the next batch begins. Keep an inventory of which objects have moved, which are still on the previous service and which require attention.
Agree when to pause, who makes that decision and what restoring the previous setup would involve. A rollback may depend on continued old-provider access, device configuration and customer communication. Make those dependencies explicit instead of treating rollback as a button that is always available.
7. Complete the operational handover
After the agreed checks pass, confirm customer access, unresolved items and the support process. Review any temporary accounts or integration credentials created for the transition and handle them through the approved access-management process. Confirm the retained records are accessible before closing the old arrangement.
For a CodeStation AI migration discussion, begin with your current platform, device models, approximate count and must-have workflows. Include historical-data needs and timing constraints. Migration feasibility, custom work and responsibility for each step belong in the agreed project scope.
Ready to apply this to your operation?
Discuss a platform transition