Migrate from Mobile Worker to Nutshell

Nutshell's contact-tier limits can cap migration mid-run

Nutshell pricing is organized by contact-tier caps — plans range from 100 contacts at the $13/user Foundation tier up to Enterprise tiers with higher limits at $79/user/month. A migration that lands on a Foundation or Starter plan can hit the cap before all Worker and Customer records are imported, causing subsequent API inserts to fail silently or return a tier-exceeded error. FlitStack validates the target Nutshell plan's contact tier before migration begins. If the tier cap is lower than the total record count, we surface a plan-upgrade recommendation before committing to the migration scope. This is a billing-level constraint, not a data-error — the fix is a Nutshell plan upgrade, not a re-migration.

Time entries have no native Nutshell home and require Activity chaining

Mobile Worker's time-tracking module is a first-class data object — each Time Entry has hours_logged, date, worker_id, and job_id as structured fields. Nutshell's data model has no native time-entry object. Activities exist as Tasks and Notes but are not structured for labor-hour reporting by default. FlitStack migrates Time Entries as Nutshell Activities with hours_logged stored in a custom numeric field (Time_Hours__c). The worker_id and job_id custom fields on each Activity form a chain linking back to the Person and Deal records. Reports built in Nutshell on top of this structure require the custom field to be included in any Activity report type — a configuration step your Nutshell admin completes post-migration.

Nutshell's custom fields do not attach to Deals by default — job-level metadata needs a workaround

Nutshell supports custom fields on Company, Person, and Lead objects natively through its field management UI (Settings > Fields). Deal custom fields are not exposed through the same UI path — Deal-level metadata in Nutshell is typically stored as a Note attached to the Deal or requires a custom Deal object setup. Fields like job_type, estimated_hours, and service_address that exist as custom fields on Mobile Worker Jobs must be stored as a structured Note on the corresponding Nutshell Deal, or your admin must request Deal custom fields through Nutshell support. FlitStack creates a formatted Note on each Deal containing all job-level custom field values in a structured key:value layout readable by your team.

Nutshell's JSON-RPC API uses basic-auth impersonation which requires careful key scoping

Nutshell's API is JSON-RPC over HTTPS with basic authentication (username:api_token). API keys can be scoped to allow impersonation — meaning actions are logged as the impersonated user — or scoped to disallow impersonation, where all API actions log under the key owner. Migration scripts must use an API key with impersonation enabled to attribute migrated records to the correct Nutshell user matched by email from the Mobile Worker worker record. If the key has impersonation disabled, all migrated records show the API key owner as the creator rather than the assigned worker. FlitStack requests impersonation-enabled keys during scoping and validates the key permissions before migration begins.

Scheduling and geofencing data cannot be stored as actionable CRM records

Mobile Worker's shift-assignment, route-order, and geofencing configurations are workflow-level constructs — they define how workers are dispatched, not what data is stored about customers or jobs. Nutshell has no scheduling engine, no geofencing capabilities, and no shift-assignment model. FlitStack exports Mobile Worker's schedule data as a JSON-formatted custom field (MW_Schedule__c) on the Nutshell Person record for administrative reference. This preserves the raw data but does not recreate the dispatch workflow — teams must rebuild scheduling logic in Nutshell's automation tools (Tasks and Activities) or a separate scheduling add-on post-migration.