Migrate from Swivl Tech to Nutshell

Swivl Tech Customers map directly to Nutshell Companies. The customer's primary service address becomes the Nutshell Company address. Billing addresses from Swivl Tech migrate as a custom address field on the Nutshell Company record. Swivl Tech customer IDs are stored as a custom Source_System_ID__c field for traceability.

Swivl Tech contact records (service requestors, site managers, billing contacts) map to Nutshell People. Multiple contacts per customer collapse to individual Person records in Nutshell, each linked to the mapped Company. The primary contact role in Swivl Tech becomes a Person custom field indicating role type.

Work orders are the closest Swivl Tech equivalent to a Nutshell Deal. The work order name becomes the Deal name, the total work order value becomes the Deal amount, and the work order status maps to a Nutshell pipeline stage. However, work orders carry a richer lifecycle (scheduling, dispatch, arrival, completion, invoicing) that Nutshell Deals do not natively represent — this requires custom fields for status transitions and timestamps.

Swivl Tech line items (parts, labor rates, service fees) with quantity, unit price, and total map to Nutshell Product entries on the associated Deal if the Nutshell plan supports Products. If Products are not available, line items serialize into a custom multi-line text field on the Deal record. Part numbers and SKUs from Swivl Tech are preserved as text in the mapping.

Swivl Tech work order statuses (Scheduled, En Route, In Progress, Completed, Invoiced, Cancelled) map to Nutshell Deal stage values via a value-by-value mapping. Status transitions with timestamps (e.g., En Route at 09:15, Completed at 11:42) are preserved as custom datetime fields on the Deal because Nutshell Deal stage history does not capture individual timestamp entries.

Swivl Tech service types (HVAC, Plumbing, Electrical, Cleaning, etc.) have no Nutshell native equivalent. FlitStack AI creates a custom pick-list field (Service_Type__c) on Nutshell Deals and maps each Swivl Tech service type value to it. If Nutshell plan limits apply to custom fields, the migration plan identifies this constraint before the migration run.

Swivl Tech technicians are users who own and execute work orders. They map to Nutshell Users by email address — the technician's Swivl Tech email becomes the Nutshell User identifier. Skill tags, certifications, and service-radius data from Swivl Tech migrate as custom fields on the Nutshell User record or as a note attachment, since Nutshell has no native skill-set construct.

Swivl Tech work order notes and site-level observations map to Nutshell Notes attached to the corresponding Deal or Company record. Original timestamps and the creating technician's name are preserved in the Note record. Rich-text formatting from Swivl Tech is downloaded and rehosted as plain text with inline image links re-attached.

Swivl Tech file attachments (photos, signed forms, invoices) migrate to Nutshell's file attachment model. Files are re-uploaded to Nutshell and linked to the corresponding Deal or Company. Nutshell's file size limits (25MB per file) apply — larger files are flagged for manual review.

Swivl Tech invoices and payment records have no direct Nutshell equivalent — Nutshell does not have a native billing or accounts-receivable module. Invoice totals and payment status migrate as custom fields on the Deal. For teams needing full invoice history, FlitStack exports the Swivl Tech invoice records as a separate data file for import into a billing tool.

Swivl Tech custom fields on Customer records (internal IDs, contract tier, service agreement dates) map to custom fields on Nutshell Company records. These must be created in Nutshell before migration — FlitStack generates the schema plan listing each custom field name, type, and pick-list values so the Nutshell admin can pre-create them.

Swivl Tech scheduling windows, dispatch assignments, and real-time GPS tracking data do not map to any Nutshell construct. Technician assignment is preserved as a User reference on the Deal; scheduling windows are stored as a custom datetime range field on the Deal. GPS route data and geolocation are not migratable and are documented as lost.