Migrate from FieldEdge to Nutshell

Work order history has no native Nutshell home — it migrates as Deal records with embedded descriptions

FieldEdge work orders are rich, multi-field records with line items, parts, labor rates, technician assignments, and sign-off timestamps. Nutshell Deals are simpler pipeline stage records without child line items or a native work-order counterpart. FlitStack AI maps each work order to a Nutshell Deal, concatenating the full work order description, parts used, and labor hours into the Deal description field, and the total amount into the Deal amount field. The limitation is that Nutshell cannot natively display work order line items as a sub-table inside a Deal — the detail lives in the description text block. Teams that rely on detailed parts-and-labor reporting from FieldEdge will need to run that analysis from the exported work-order reference file rather than from within Nutshell's reporting interface.

Invoice PDFs re-attach as files on Person records — there is no Nutshell billing object

FieldEdge generates and stores invoices with line-item detail linked to work orders. Nutshell has no native invoice, billing, or accounts-receivable object. FlitStack AI downloads each FieldEdge invoice PDF, re-uploads it as an attachment on the associated Nutshell Person record, and stores the invoice total, balance due, and payment status as custom fields on that Person. The custom fields enable basic AR tracking inside Nutshell (e.g., 'Does this customer have an outstanding balance?'), but Nutshell cannot generate invoices, track payment schedules, or handle partial payments the way FieldEdge does. If invoicing is a core part of your workflow, that process must continue in FieldEdge or be rebuilt in a separate accounting tool integrated with Nutshell.

Service agreement contract terms store as a long-text custom field — no native contract management in Nutshell

FieldEdge service agreements carry recurring billing schedules, contract start and end dates, frequency (monthly, annual, per-visit), and coverage scope. Nutshell has no native service-agreement or contract management module. FlitStack AI stores the full agreement terms — frequency, start/end dates, monthly billing amount, and coverage description — as a long-text custom field on the linked Nutshell Person or Company record, with the agreement PDF attached as a file. This makes the agreement visible when opening a customer record, but Nutshell cannot auto-renew agreements, generate renewal reminders, or enforce contract limits. Teams managing active service agreements will need a manual process or a separate contract management tool post-migration.

FieldEdge dispatch and scheduling data has no equivalent in Nutshell — it exports as a reference file

FieldEdge's core differentiator is its dispatch board with GPS tracking, route optimization, and multi-technician scheduling. Nutshell Activities (tasks and events) support individual appointments but lack a dispatch board, route optimization, or fleet scheduling capability. FlitStack AI exports the dispatch and scheduling data — technician-to-job assignments, route sequences, GPS coordinates, and scheduling windows — as a structured CSV and JSON file attached to the migration report. This data serves as an audit trail and a starting point for manual re-entry if you adopt a dedicated scheduling tool. The migration does not attempt to force-draw a dispatch board inside Nutshell's activity model, which would produce meaningless scheduling records.

FieldEdge custom fields require Nutshell custom field pre-creation before data lands

FieldEdge supports custom fields on customers, companies, work orders, and invoices. Nutshell requires custom fields to be created in the application UI before data can populate them via the API. FlitStack AI generates a Nutshell custom field creation plan based on the FieldEdge schema audit — listing each custom field's name, type (text, number, date, choice), and target object (Person, Company, Lead, or Deal). Your Nutshell admin creates these fields before the migration run commits. If custom fields are not pre-created, the migration engine skips those fields and logs them in the field-level diff report for post-migration remediation.