Migrate from Court Clerk to Nutshell

Nutshell has no native Case object — case data must live in custom fields on Deal

Court Clerk's core record is a Case with a rich schema of case-type, bond amount, restitution, and status fields. Nutshell has no built-in Case or Matter object — it uses Deals as its primary tracked records. FlitStack creates Nutshell custom fields (Case_Type__c, Filing_Date__c, Court_Name__c, Bond_Amount__c, Case_Status__c, etc.) on the Deal object to hold all court-specific metadata. Before migration, your Nutshell admin must create these custom fields in the Nutshell settings UI; FlitStack provides the exact field-name and type specification as part of the pre-migration schema plan. Courts with more than 15 case-specific fields should budget extra time for custom-field creation and value-mapping.

Party-to-case associations require a custom link structure that Court Clerk handles natively

Court Clerk stores party roles on a case as a first-class relationship (each case has a list of parties with roles like Plaintiff, Defendant, or Witness). Nutshell has no native many-to-many Person-Deal junction object — a Person can be associated with a Deal only through the Deal's linked People list, which does not natively support role labels. FlitStack resolves this by storing the party role as a custom field (Party_Role__c) on the Person record and applying Nutshell Tags per role (Plaintiff, Defendant, Expert Witness) so your team can filter the Deal's People tab by role. Alternatively, a Nutshell custom object can serve as a junction if your workflow requires structured role tracking.

On-premise Court Clerk deployments may require county IT coordination for database access

Tyler Technologies Court Clerk is deployed as on-premise software in many county and circuit court environments. API access may be restricted or unavailable, and direct database queries require coordination with county IT staff and DBA access. FlitStack typically extracts from Court Clerk via the available API endpoint; for on-premise deployments without API access, we work with your IT team to run a SQL export script and deliver the CSV or JSON file for ingestion. This adds 3–5 business days of coordination time before migration planning begins. We surface this in the discovery call and include IT coordination time in the project schedule.

Nutshell's per-user pricing means court staff who only need read access still require Nutshell licenses

Court Clerk offices often include non-sales staff (clerks, administrative assistants, judges' chambers) who need to view case records but do not manage a pipeline. Nutshell's pricing is per named user with full read/write access. Read-only access requires either full-user Nutshell seats or an external reporting tool (Power BI, Metabase) connected via Nutshell's API for read-only data access. FlitStack's migration does not solve the read-access licensing question — this is a Nutshell billing question that must be resolved before go-live so all staff who need case visibility have appropriate access provisioned.

Status-history logs on cases require a custom text field or Note append strategy

Court Clerk tracks each case's status transitions with timestamps and reasons (e.g., Case Opened → Discovery → Motion Filed → Closed). Nutshell Deal Stage History is scoped to Nutshell Stage changes only and does not store Court Clerk status-transition metadata. FlitStack preserves the full Court Clerk status-change log as a JSON-formatted custom text field (Status_History_JSON__c) on the Deal and appends a human-readable Note to the Deal. Courts with complex multi-step status histories (e.g., family court cases with numerous hearing continuances) should flag this for extra validation during the sample migration phase.