Migrate from Orderry to Nutshell

Work orders have no native Nutshell equivalent and must be stored as custom fields plus linked activities

Orderry's Job object contains native fields for status, priority, assigned technician, line items, cost, and work order number that have no direct analogue in Nutshell's data model. FlitStack AI handles this by converting each Orderry job into a Nutshell Task activity linked to the Person record, while job-level attributes like status, priority, cost, and job ID are stored as Nutshell custom fields on that Person record. The linked Task preserves the job description, assigned user, and original timestamps. If your team relies heavily on work-order reporting and filtering in Nutshell, plan additional time with your admin to configure the custom field views and list filters that replicate Orderry's work-order dashboard.

Inventory stock levels and warehouse data cannot become live Nutshell inventory records

Orderry's product and inventory model includes warehouse locations, stock quantities, FIFO/FEFO costing, reorder points, and bundle configurations. Nutshell has no inventory management module — the product catalog and stock data have no native home. FlitStack AI maps Orderry product name, SKU, unit cost, and stock quantity to Nutshell Person or Company custom fields for reference, and preserves file attachments (product images, spec sheets) on the Person record. However, Nutshell will not calculate stock levels, trigger reorder alerts, or manage purchase orders. If your team needs live inventory tracking in Nutshell, that requires a separate inventory management tool or a custom Nutshell integration after the migration is complete.

Nutshell's Import2 sample migration limits to 100 random accounts — large datasets need bulk export fallback

Nutshell's built-in Import2 tool limits sample migrations to 100 random accounts with their linked contacts and activities. For Orderry datasets exceeding 5,000 records, the Import2 tool is insufficient for a full sample review. FlitStack AI uses Orderry's export tools and API endpoints to extract the complete dataset — including all jobs, estimates, invoices, and inventory — and writes directly to Nutshell via its JSON-RPC API with bulk operations. This approach bypasses the 100-record sample limit and provides a complete field-level diff before the full run commits. We validate API rate limits during the audit phase and throttle writes accordingly to avoid 429 errors during the migration run.

Orderry tier plan limits on employee seats and locations affect how the Nutshell user count is planned

Orderry's Hobby plan caps at 2 employees and 1 location, while Startup and Business plans unlock additional seats and locations for per-seat fees. Teams that have grown to the Business tier may have 10–25 active users in Orderry. Nutshell pricing is also per-seat, but with no bundled location or inventory features. During migration planning, FlitStack AI surfaces the Orderry employee roster and maps it to Nutshell user assignments by email. Any Orderry employee who does not yet have a Nutshell account is flagged for provisioning before the full migration begins. Over-provisioning in Nutshell should be avoided — only active CRM users need Nutshell seats; field technicians who exclusively used Orderry's job management features may not need a Nutshell license.

Orderry estimate and invoice PDFs must be re-hosted as Nutshell file attachments

Orderry stores estimates and invoices as documents linked to the client record. Nutshell's attachment model does not automatically re-host external file URLs from Orderry — each attachment must be downloaded from Orderry and uploaded to Nutshell's file storage. FlitStack AI's migration process includes a file-migration step that pulls PDF and image attachments from Orderry (where accessible via the API or export) and attaches them to the corresponding Person record in Nutshell. Attachments that are not accessible via the Orderry API (for example, files stored only in Orderry's document manager without a direct download URL) are flagged in the migration report with the original file name and URL reference preserved in a custom field so your team can manually upload them after go-live.