Migrate from Comet Suite to Microsoft Dynamics 365 Sales

GPS location history has no native Dynamics 365 entity — custom fields are required

Comet Suite captures GPS coordinates at each check-in and stores last-known location on the worker profile. Dynamics 365 Sales has no native GPS, geofence, or location-history entity — the data must be stored as custom Decimal fields (new_lastlatitude, new_lastlongitude) on Contact. These fields do not appear in Dynamics 365 maps or geospatial dashboards natively; they require Power Apps canvas integration or a third-party geolocation component to visualize. FlitStack preserves the raw coordinate data for reference, but teams expecting a live worker-tracking map in Dynamics 365 Sales should plan a separate Power Platform build post-migration.

Comet Suite team/crew structures require a custom Dataverse table

Comet Suite models crew assignments and team hierarchies as flat properties on worker records. Dynamics 365 Sales has no native concept of a crew or field team — the built-in Team entity in Dataverse controls security roles and queue membership, not operational groupings. FlitStack creates a custom new_Crew table with lookups to Contact for each member. If your team uses crew-level scheduling in Comet Suite, that scheduling logic cannot migrate to Dynamics 365 Sales without Dynamics 365 Field Service (a separate license tier) or a Power Automate-based scheduling rebuild. We surface this distinction in the pre-migration schema plan so your team can decide on licensing before data lands.

Dynamics 365 StateCode/StatusCode picklist values must be mapped from Comet Suite status strings

Comet Suite worker_status and attendance_status store free-form or semi-structured strings (e.g., 'Active', 'On Leave', 'Checked In'). Dynamics 365 StateCode and StatusCode on Contact and Task use OptionSet integers that are set at the organization level. Migration requires building a value-mapping table between Comet Suite status strings and Dynamics 365 integer codes before records load. If your Comet Suite instance uses custom status strings not in the default mapping, custom OptionSet values must be created in Dynamics 365 first — a step that requires a solution publisher and solution import. FlitStack generates the complete value map during the pre-migration discovery phase and validates it against your Dynamics 365 OptionSet configuration.

Comet Suite custom fields create schema divergence risk when naming conventions collide

Comet Suite custom field names like 'region', 'department', or 'status' may conflict with existing custom fields or system fields in your Dynamics 365 instance. Dynamics 365 enforces unique schema names per table with the new_ prefix for custom fields, but Display Name collisions (the friendly name shown in forms) are allowed and can cause user confusion. FlitStack pre-scans both systems for naming collisions and prepends a source-system prefix (e.g., new_comet_region) to any ambiguous custom fields during migration. This keeps the data intact while preventing form-layout conflicts when records load into Dynamics 365.

API rate limits require pagination strategy during Comet Suite bulk export

Comet Suite's export API applies per-tenant daily request limits that vary by subscription tier. Large worker databases (50,000+ records) require paginated API calls with cursor-based pagination or offset pagination, and retry logic for 429 responses. FlitStack implements exponential backoff and concurrent worker threads to maximize export throughput within rate limits. The export phase typically runs 2–4x longer than the Dynamics 365 import phase for large datasets. We surface the estimated export duration during the discovery call so your team can plan the cutover window accordingly.