Migrate from The Case File to HubSpot

Case-to-deal mapping requires a go/no-go decision on case scope before migration

The Case File cases represent client matters of varying scope — some are short tasks, others are long-running engagements. Mapping all cases to HubSpot deals works for deal-centric teams, but creates pipeline clutter for high-volume case managers. We offer two paths: map cases as HubSpot deals with a custom case-type property, or create a HubSpot ticket-based custom object for case-history parity. The choice affects deal pipeline reporting and must be locked before field mapping begins. We surface this decision during the scoping call and document the chosen model in the migration plan.

Case status value mapping is manual and must cover every active status

The Case File case status pick-list values vary by implementation — Open, In Progress, Pending Review, Closed Won, and Closed Lost are common but not universal. HubSpot deal stages are pipeline-scoped pick-lists that require explicit value-by-value mapping. Any status value not mapped will default to the first stage or land unmigrated. FlitStack extracts the full active status list during discovery, presents the value map for confirmation, and flags any unmapped values before migration commits. Missing status mappings are a high-severity issue that delays go-live.

Document attachments require a separate upload and re-link step

HubSpot has no native equivalent to The Case File's document-attachment-on-case model. Documents must be downloaded from The Case File, uploaded to HubSpot Files, and manually associated to the migrated contact, company, or deal record. The original case-to-document link is preserved as a custom property on each HubSpot file, but the association does not render as a native attachment in the HubSpot UI. Teams should expect a brief period where documents are accessible in HubSpot Files but not embedded in the deal record — this is a known limitation of HubSpot's file model.

Case-to-contact associations must be reconstructed after contact migration

The Case File supports linking a case to one primary contact and zero-to-many secondary contacts. HubSpot deals have a built-in contact association model (primary contact + additional contacts via the association API), but the mapping must happen after contacts are created, not before. We run a post-contact-migration association step to attach secondary contacts to their respective migrated cases converted to deals. If The Case File uses a many-to-many contact-link table, we map it to HubSpot's deal-contact association API.

Custom fields with non-standard data types require HubSpot-side property creation before import

The Case File custom fields may include text areas, multi-select pick-lists, currency fields, or date-time fields that map directly to HubSpot custom property types, but the HubSpot property must exist in your portal before the import batch runs. FlitStack creates all required HubSpot custom properties during the setup phase, but property display order, required/optional flags, and default values should be reviewed by your HubSpot admin before the migration loads data. Custom properties that are missed require a re-run of the affected records.