CRM migration
Field-level mapping, validation, and rollback between Zinc and HubSpot. We move data and schema; workflows are rebuilt natively in HubSpot.
Zinc
Source
HubSpot
Destination
Compatibility
10 of 11
objects map 1:1 between Zinc and HubSpot.
Complexity
BStandard
Timeline
48–72 hours
Overview
Teams migrate from Zinc Work to HubSpot when they want candidate reference data living alongside sales and marketing records in a single CRM platform. Zinc Work stores candidate profiles, reference-check request records, and reference-response logs as discrete objects. HubSpot's model uses contacts as the primary person record, deals for pipeline tracking, and custom objects for domain-specific data like background-check results. FlitStack AI extracts every candidate record from Zinc Work via the REST API — including all custom reference-check properties, verification timestamps, and reference-provider details. We map those into HubSpot contacts with a parallel custom object for reference-check records, linked via HubSpot's association model. Reference-response logs migrate as HubSpot engagement records (notes and calls) preserving the original reference name, relationship, and response content. What does not migrate: Zinc Work's automated request-trigger workflows, notification templates, and ATS/HRIS integrations must be rebuilt using HubSpot workflows and the HubSpot Connect integration framework. The migration runs on scoped read access — your recruiting team continues using Zinc Work throughout the cutover window.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Zinc object lands in HubSpot, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Zinc
Candidate
HubSpot
Contact
1:1Zinc Work Candidate maps directly to HubSpot Contact. We map first name, last name, email, phone, job title, and company name to their HubSpot equivalents. Candidates without email are flagged for manual review before import because HubSpot requires an identifier property for deduplication.
Zinc
Candidate.custom_properties
HubSpot
Contact (custom properties)
1:1Every Zinc Work custom property on Candidate requires a matching custom property in HubSpot created before the migration runs. We deliver a HubSpot setup plan listing each property name, type, and pick-list options so your admin creates them in the portal before data lands.
Zinc
ReferenceCheck
HubSpot
ReferenceCheck__c (custom object)
1:1Each Zinc Work ReferenceCheck record migrates to a HubSpot custom object (ReferenceCheck__c). The ReferenceCheck UUID is preserved as ReferenceCheck__c.Source_ID__c for delta-run deduplication. The object is associated to the Contact via HubSpot's association API after the contact record is created. The association uses HubSpot's Associations API (POST /crm/v4/objects/{Contact}/associations/{ReferenceCheck__c}) after the Contact is confirmed. If the Contact is missing, the ReferenceCheck record is queued for later linking.
Zinc
ReferenceCheck.status
HubSpot
ReferenceCheck__c.RefCheck_Status__c
1:1Zinc Work reference-check statuses (pending, in_progress, completed, verified, failed) map to a HubSpot custom pick-list field (RefCheck_Status__c) value-by-value. We preserve the status-change timestamps as datetime fields on the custom object for audit continuity. If a status value does not have a matching HubSpot pick-list option, we create the option on the fly or flag it for manual mapping before import, ensuring no status is silently dropped.
Zinc
ReferenceCheck.check_type
HubSpot
ReferenceCheck__c.Check_Type__c
1:1Zinc Work check-type labels (employment_verification, criminal, education, identity) transfer as a custom pick-list field on the ReferenceCheck__c custom object. Pick-list values are created in HubSpot portal settings before the migration maps them. During migration, any missing pick-list values are automatically provisioned via the HubSpot CRM API (POST /crm/v3/properties/{objectType}/pick-lists) so the import never stalls on an unrecognized check type.
Zinc
ReferenceCheck.request_date
HubSpot
ReferenceCheck__c.Request_Date__c
1:1The original reference-request creation date from Zinc Work is preserved as a custom datetime field (Request_Date__c) on the ReferenceCheck__c object. HubSpot's built-in createdate is set at migration time — the custom field preserves reporting continuity. If the request_date is null in Zinc Work, we set Request_Date__c to null, preventing a default date from skewing historical reporting.
Zinc
ReferenceCheck.completion_date
HubSpot
ReferenceCheck__c.Completion_Date__c
1:1The reference-check completion date maps to a HubSpot custom datetime field (Completion_Date__c) on the ReferenceCheck__c object. Null completion dates (checks still in progress) are preserved as null values rather than defaulting to a placeholder date. During import, any unexpected non-date strings in the source are coerced to null and logged in the migration audit file for manual review.
Zinc
Reference (child of ReferenceCheck)
HubSpot
Note / Call activity on Contact
1:manyZinc Work stores each reference provider as a structured sub-record with name, relationship, email, and response content. We split this into two HubSpot artifacts: structured fields (provider name, relationship, email) migrate as additional properties on the ReferenceCheck__c custom object; free-text response content migrates as a HubSpot engagement Note linked to the associated Contact.
Zinc
Candidate.integration_ids (Greenhouse, Bob)
HubSpot
Custom properties on Contact
1:1Zinc Work stores ATS and HRIS integration IDs linking candidates to external systems. HubSpot has no native field for external integration IDs beyond the built-in integrations. We preserve these as custom text fields (Source_ATS_ID__c, Source_HRIS_ID__c) for traceability — rebuild integration connectivity via HubSpot Connect separately.
Zinc
Candidate.hs_object_id (legacy HubSpot link)
HubSpot
Contact.Source_System_ID__c
1:1If candidates were previously synced from HubSpot to Zinc Work, the HubSpot contact ID is stored in Zinc Work's metadata. We capture this as Source_System_ID__c on the HubSpot Contact for deduplication logic in future delta syncs. The Source_System_ID__c field is indexed in HubSpot, enabling fast lookups during subsequent delta imports to avoid creating duplicate contact records.
Zinc
ReferenceCheck.attachment_url
HubSpot
Contact / ReferenceCheck__c file attachments
1:1Zinc Work stores PDF report URLs for completed background checks. We download each PDF and re-upload it to HubSpot Files attached to the associated ReferenceCheck__c record. File size limits (HubSpot default 25MB per file) are enforced; larger files are flagged for manual download-link storage in a custom URL field.
| Zinc | HubSpot | Compatibility | |
|---|---|---|---|
| Candidate | Contact1:1 | Fully supported | |
| Candidate.custom_properties | Contact (custom properties)1:1 | Fully supported | |
| ReferenceCheck | ReferenceCheck__c (custom object)1:1 | Fully supported | |
| ReferenceCheck.status | ReferenceCheck__c.RefCheck_Status__c1:1 | Fully supported | |
| ReferenceCheck.check_type | ReferenceCheck__c.Check_Type__c1:1 | Fully supported | |
| ReferenceCheck.request_date | ReferenceCheck__c.Request_Date__c1:1 | Fully supported | |
| ReferenceCheck.completion_date | ReferenceCheck__c.Completion_Date__c1:1 | Fully supported | |
| Reference (child of ReferenceCheck) | Note / Call activity on Contact1:many | Fully supported | |
| Candidate.integration_ids (Greenhouse, Bob) | Custom properties on Contact1:1 | Fully supported | |
| Candidate.hs_object_id (legacy HubSpot link) | Contact.Source_System_ID__c1:1 | Fully supported | |
| ReferenceCheck.attachment_url | Contact / ReferenceCheck__c file attachments1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Zinc gotchas
Integration settings do not migrate automatically
Custom check templates with bespoke rubrics require field-level mapping
Audit logs are not accessible for export
HubSpot gotchas
Marketing Contacts billing model is migration-critical
Feature tier gating is not visible until onboarding
Mandatory onboarding fees inflate year-one cost
HubSpot CSV importer cannot migrate engagements or attachments
Custom objects require Enterprise and a pre-existing schema
Pair-specific challenges
Migration approach
Deliver the HubSpot custom-object and property manifest
Before any data moves, FlitStack AI audits your Zinc Work instance for all custom properties on Candidate and ReferenceCheck objects. We produce a HubSpot setup manifest — every property name, type, and pick-list value that needs to be created in your HubSpot portal before migration. Your HubSpot admin creates these in Settings > Properties. We do not create HubSpot custom properties via API; this step requires an admin action. The manifest also includes the ReferenceCheck__c custom object schema if your HubSpot tier supports custom objects (Operations Hub Professional or Enterprise).
Extract all Zinc Work candidate and reference-check records via REST API
Using Zinc Work's REST API with your client token, FlitStack AI paginates through /candidates and /reference_checks endpoints with cursor-based pagination to extract every record. We capture the full object graph including custom properties, status history, reference-provider details, and attachment URLs. The extract runs on scoped read access — your team continues using Zinc Work normally. The extract output is written to a staging environment with an MD5 checksum per record for integrity verification before any load begins.
Map and transform records, then load candidates before reference-check objects
We apply the field-mapping rules from the mapping manifest: direct field maps, value mappings for pick-list status fields, and transformations for split objects (reference responses become HubSpot Notes). Candidates load into HubSpot Contacts first because the ReferenceCheck__c custom object links to Contact records via HubSpot's association API — Contacts must exist first. Reference-check records and their association links load second. Attachment PDFs download from Zinc Work URLs and re-upload to HubSpot Files in the third pass.
Run a sample migration with field-level diff across 200–500 records
A representative slice of candidates and reference checks migrates first — spanning different statuses, check types, and custom-property combinations. We generate a field-level diff comparing source Zinc Work values against the HubSpot destination values so you can verify: custom property mapping is correct, reference-check status values translated properly, association links resolved, and engagement notes contain the expected response content. You approve the sample before the full migration commits. This step typically runs 24–48 hours before the full cutover.
Cut over with delta-pickup for in-flight records
The full migration runs against your HubSpot portal. A delta-pickup window of 24–48 hours captures any Zinc Work records created or modified during the cutover — new candidates submitted while migration was running, status updates on in-progress reference checks. FlitStack's audit log records every create, update, and association operation. If reconciliation fails, one-click rollback reverts the HubSpot portal to its pre-migration state. After rollback, the delta records are re-extracted and merged into the next migration run.
Platform deep dives
Zinc
Source
Strengths
Weaknesses
HubSpot
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Zinc and HubSpot.
Object compatibility
1 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Zinc: Not publicly documented.
Data volume sensitivity
Zinc doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Zinc to HubSpot migration scoping. Not seeing yours? Book a call.
Walk through your Zinc to HubSpot migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Zinc
Other ways to arrive at HubSpot
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.