Edited by EishiFUN
I have a customer that is moving all devices and data over to a new database, including logs, data, and all configurations they have setup in their initial database, I am looking for a resource, step by step type of document to guide the customer through this process to effectively transfer and retain all data for assets, setups, drivers, etc. do we have an established guide for a customer on how to do this? if so, could this be shared with me, or clarified?
thank you in advance!
You need to be logged in to reply to this post and participate in the Geotab Community discussions.
Hi @Acarstensen-1553 ! This is a great question and one we hear fairly often when customers are consolidating or moving between databases. The honest answer is: there's no single automated "move everything" tool, but there is a structured way to approach it. Let me break it down.
What can be migrated
Configuration and setup data can be moved using a combination of official tools:
- Groups, Exception Rules, Reports, Dashboards, Map Providers, and remote-hosted Add-ins — use the https://github.com/Geotab/geotabRegistrationConfigExport add-in. Install it in the source database, export the config as a JSON file, then import it when setting up the target database. This is the most efficient step for getting the "skeleton" of the database rebuilt.
- Zones — export via CSV and re-import using the https://geotab.github.io/sdk/software/js-samples/importZones.html tool from the Geotab SDK samples.
- Users and Drivers — export and re-import via the https://geotab.github.io/sdk/software/js-samples/importUsers.html tool. Note: user passwords do not carry over — new credentials will need to be set.
- Routes — re-importable via the SDK import samples.
- Devices (GO devices) — use Data Sharing with Transfer Control to move operational control to the new database. In the source database: Assets →select the asset → Devices & Settings → Start Sharing → enter the target database name → enable "Grant Control." The target database then accepts the share. From that point, new trip and engine data flows into the target database.
What cannot be transferred
This is the most important part to set expectations on: historical data does not move. Trip logs, GPS records, engine/diagnostic status data, fault data, and historical exception events all remain in the originating database. This is a platform-level limitation — there is no API or tool that migrates historical records between databases. If the customer needs to retain access to historical data, the best option is to keep the source database active (or at minimum, read-only/archived) alongside the new one.
Recommended order of operations
1. Export configuration from the source database using the geotabRegistrationConfigExport add-in
2. Create/provision the target database with your reseller
3. Import the configuration JSON into the target database (groups, rules, reports, dashboards)
4. Import Zones via CSV
5. Import Users/Drivers via CSV and assign new credentials
6. Transfer Devices via Data Sharing with Transfer Control enabled
7. Reassign devices to the correct groups in the target database (group assignments don't carry through the share)
8. Verify exception rules, reports, and dashboards are referencing the correct groups
9. Re-authorize any third-party Marketplace integrations — these typically need to be reconnected manually
10. Keep the source database available for historical data reference — don't delete it right away
Hope this gives a solid framework to work from! If the customer has specific data types they're concerned about, feel free to drop them here and we can dig into whether there's a path for those specifically. I would also highly recommend talking with solution engineering to help with this when you go to do it as they may know better than me since they have done it many times before.
Have a good one!
Eishi FUN
Hi @Acarstensen-1553 ! This is a great question and one we hear fairly often when customers are consolidating or moving between databases. The honest answer is: there's no single automated "move everything" tool, but there is a structured way to approach it. Let me break it down.
What can be migrated
Configuration and setup data can be moved using a combination of official tools:
- Groups, Exception Rules, Reports, Dashboards, Map Providers, and remote-hosted Add-ins — use the https://github.com/Geotab/geotabRegistrationConfigExport add-in. Install it in the source database, export the config as a JSON file, then import it when setting up the target database. This is the most efficient step for getting the "skeleton" of the database rebuilt.
- Zones — export via CSV and re-import using the https://geotab.github.io/sdk/software/js-samples/importZones.html tool from the Geotab SDK samples.
- Users and Drivers — export and re-import via the https://geotab.github.io/sdk/software/js-samples/importUsers.html tool. Note: user passwords do not carry over — new credentials will need to be set.
- Routes — re-importable via the SDK import samples.
- Devices (GO devices) — use Data Sharing with Transfer Control to move operational control to the new database. In the source database: Assets →select the asset → Devices & Settings → Start Sharing → enter the target database name → enable "Grant Control." The target database then accepts the share. From that point, new trip and engine data flows into the target database.
What cannot be transferred
This is the most important part to set expectations on: historical data does not move. Trip logs, GPS records, engine/diagnostic status data, fault data, and historical exception events all remain in the originating database. This is a platform-level limitation — there is no API or tool that migrates historical records between databases. If the customer needs to retain access to historical data, the best option is to keep the source database active (or at minimum, read-only/archived) alongside the new one.
Recommended order of operations
1. Export configuration from the source database using the geotabRegistrationConfigExport add-in
2. Create/provision the target database with your reseller
3. Import the configuration JSON into the target database (groups, rules, reports, dashboards)
4. Import Zones via CSV
5. Import Users/Drivers via CSV and assign new credentials
6. Transfer Devices via Data Sharing with Transfer Control enabled
7. Reassign devices to the correct groups in the target database (group assignments don't carry through the share)
8. Verify exception rules, reports, and dashboards are referencing the correct groups
9. Re-authorize any third-party Marketplace integrations — these typically need to be reconnected manually
10. Keep the source database available for historical data reference — don't delete it right away
Hope this gives a solid framework to work from! If the customer has specific data types they're concerned about, feel free to drop them here and we can dig into whether there's a path for those specifically. I would also highly recommend talking with solution engineering to help with this when you go to do it as they may know better than me since they have done it many times before.
Have a good one!
Eishi FUN