Migrate from Timefold to Nutshell

Constraint logic and solver configurations cannot execute in Nutshell

Timefold's entire operational value lives in its constraint models — the DRL files, Constraint Streams, score annotations, and solver configuration that take a scheduling problem and find the optimal solution. Nutshell is a CRM with no constraint-satisfaction engine and no concept of a planning variable, score director, or solver. When migrating, we serialize constraint configuration as structured JSON in custom fields and export a human-readable constraint manifest, but this is documentation — it cannot be run inside Nutshell. Your team must decide whether to keep Timefold running in parallel for optimization, document constraints externally, or accept that the CRM will store scheduling context without driving optimization. Failing to address this gap before go-live means your Nutshell instance will have the data from Timefold but none of its intelligence.

Timefold exports come from Java domain objects and configuration files, not a standard CRM API

Timefold does not expose a standard object-oriented CRM export endpoint. Planning data lives in your own database or application, structured as Java domain objects annotated with @PlanningEntity and @PlanningVariable decorators. To extract migration-ready records, FlitStack AI either reads from the Timefold Platform REST API (which exposes input/output datasets per model) or parses your application-side domain exports. The structure varies by optimization model type (field service uses Visit entities; rostering uses Shift entities), and constraint configurations are spread across Java classes, XML files, and annotation metadata. We apply a multi-pass extraction: first to enumerate all model types and their entity schemas, then to export records per entity, then to consolidate constraint metadata. This multi-pass process adds discovery time compared to a standard CRM-to-CRM migration where the object schema is already known.

Scheduling objects (Shift, Visit, Route) have no native Nutshell equivalent and require custom fields

In Nutshell, the standard record types are People, Accounts, Leads, and Deals — with Tasks as the only temporal activity record. Timefold Shift records (employee, timeslot, skill requirements, location, shift type) must map to Nutshell Tasks with a significant number of custom fields to preserve scheduling context. Timefold Visit records (technician, customer, time window, travel time, visit outcome) similarly map to Tasks linked to the People record of the customer contact. Multi-day shift sequences must be decomposed into individual Task records. If your Timefold model includes chained dependencies between visits or shift handover logic, those dependencies cannot be natively expressed in Nutshell Tasks and must be reconstructed from the constraint manifest as manual notes or activity logs.

Nutshell's People/Account name collision with Timefold entity terminology

Timefold uses Java class names that may contain the strings 'Contact' or 'Account' as property names in the domain model (e.g., a Timefold Visit entity might have a field named 'contact' referencing the customer site). Nutshell's standard object model uses People for contacts and Accounts for companies. If your Timefold domain model references entities named 'Contact' or 'Account', the migration mapping must distinguish between Timefold's internal entity references and Nutshell's standard object names. We resolve this at the field level during the mapping phase: a Timefold Visit.contact field maps to a link to the Nutshell People record that corresponds to the customer at that service site, not to Nutshell's standard Contact object (which does not exist as a top-level object in Nutshell's API — the equivalent is People).

Skill and certification data type fidelity loss when stored in Nutshell custom fields

Timefold models skill requirements as typed entity properties — a technician's skill set is an ordered collection of Skill objects with attributes like proficiency level, certification expiry, and skill category. Nutshell custom fields support text, number, pick-list, and multi-select. When we migrate skill data, we must collapse the rich Timefold skill object into a simplified multi-select or text field. Proficiency levels, expiry dates, and skill categories that were structurally distinct in Timefold become flattened text values or separate custom fields in Nutshell. If you rely on proficiency-level routing (e.g., only assign 'Level 2 HVAC' technicians to certain visits), that logic lives in the Timefold constraint model and is not preserved by the field-level migration — it must be rebuilt either in Timefold's constraint rules or as a Nutshell workflow.