Migrate your TalentFlow data

Talents are the core roster entries representing represented individuals. We migrate all standard fields (contact info, representation status, bio, headshot reference) and preserve the talent's linked submission history. Custom talent attributes require field-level mapping to the destination schema.

Client records represent the hiring companies or production entities. We map name, contact, industry, and associated job postings. Client notes and custom fields are migrated as-is with destination field mapping applied.

Jobs track open requisitions linked to clients. All standard fields including job title, description, location, pay range, and status are migrated. Pipeline stage definitions may differ between platforms and are mapped explicitly during migration.

Submissions link a Talent to a Job and track the hiring funnel stage. The platform stores submission metadata including submitted date, current stage, and rejection notes. We preserve all submission-to-talent and submission-to-job relationships and map the source stage names to the destination pipeline stages.

Contract records capture agreement terms between the agency and a client or talent. We migrate contract details, associated parties, commission rates, and effective dates. Contracts linked to specific deals carry forward the deal association in the destination system.

Deals track placement revenue and commission structures tied to successful hires. We migrate deal value, expected close date, associated talent, client, and contract linkage. Deal stage and status are mapped to destination pipeline conventions.

TalentFlow supports custom fields on both Talent and Job objects. These vary per account. We extract the full custom field schema during discovery, map each to equivalent destination fields where possible, and flag any that cannot be automatically mapped for manual review before import.

Resume files, headshots, and contract documents attached to Talent or Job records are exported and re-associated in the destination system. We handle file type detection and maintain the original filename for traceability. Large binary attachments may require chunked export to stay within API transfer limits.

User accounts for agents and admins are migrated with their roles and permission levels. Role naming conventions differ across platforms — we map TalentFlow roles to the closest equivalent in the destination system and flag any permission limitations that apply post-migration.

Free-text notes and feedback entries attached to Talent or Job records are migrated as-is. We do not transform note content but preserve the author and timestamp. Some destination systems treat notes as system-generated activity rather than standalone records, which affects how they display post-migration.

Interview schedules, callback appointments, and deadline events are typically managed in the platform's calendar view rather than stored as standalone data objects with a documented export schema. We do not migrate calendar events as structured records. Any associated dates on Jobs or Submissions are preserved through the Job and Submission migration.

The platform supports configurable pipeline stages for submissions. We capture the full stage definition including stage name, order, and any automation triggers. When migrating to a platform with a different stage model, we ask the customer to define the mapping before executing the import.

Tags applied to Talents, Jobs, or Submissions are migrated as label arrays. The destination system may use a different taxonomy — we map tag names where possible and preserve unmapped tags as custom label fields for manual cleanup.

Agency-level settings including branding, email templates, onboarding workflows, and billing preferences are platform-specific configuration and do not migrate between systems. We export the list of active settings for manual reconfiguration in the destination platform.

If the platform stores Equal Employment Opportunity data attached to candidates or submissions, we handle this as sensitive data requiring explicit customer consent before migration. We flag any EEO fields discovered in the schema and segregate them from the main data export per compliance requirements.