Migrate from Asanify to Crelate

Asanify employee records map to Crelate Contact records. Core fields migrate directly: full name, personal email, phone, address, employment status, and job title. Employment start date and department migrate to custom Contact fields (cf_employment_start_date, cf_department, cf_job_title) that we configure in Crelate before import. We confirm the destination Crelate plan's custom field limit: Basic = 0 fields, Business = 10 fields, Enterprise = expanded. If the plan is Basic, salary and employment date fields cannot migrate into typed fields and are instead exported as a supplemental CSV with the employee export.

Asanify company and org structure records map to Crelate Company records. The primary company record migrates as a Crelate Company with the business legal name, address, and industry. Sub-departments from Asanify's org hierarchy migrate as child Company records with a parent_company relationship, preserving the reporting structure as a Company hierarchy rather than a flat list.

Asanify's org chart and department hierarchy are available in all plans and migrate as a Company hierarchy in Crelate. Each department in Asanify becomes a child Company record under the parent organization Company, with the department head's Contact record linked via a custom field. We export the full org tree as a parent-child mapping table for the customer to validate before Crelate import.

Asanify salary revision history maps to Crelate custom fields on the Contact record: cf_base_salary, cf_salary_currency, cf_last_revision_date, cf_salary_revision_reason. The current salary value is the primary import; historical revision log is stored as a JSON blob in a long-text custom field cf_salary_history_json. Crelate Basic plan cannot accommodate these fields; Business (10 fields) accommodates current salary only; Enterprise accommodates full history. We confirm the plan during scoping and scope revision history accordingly.

Leave balances (current accrual state, carry-forward, entitlement) have no equivalent field type in Crelate's recruiting data model. We export the current leave balance snapshot per employee as a supplemental CSV file delivered alongside the Contact migration. The customer can use this file for HR reference, load it into a separate HRMS tool, or accept that leave entitlement is not tracked in Crelate. Leave policy configuration is not migrated.

Payslip records, payroll runs, TDS deductions, PF contributions, ESIC, and professional tax withholding amounts have no Crelate equivalent and cannot migrate as operational records in a recruiting ATS. We export payslip summaries as a supplemental CSV keyed by employee email, including earnings, deductions, and net pay per pay period. The customer retains these records for payroll audit purposes; Crelate does not generate or store payslip documents.

Employees onboarded via Asanify's EOR service are legally employed by an Asanify-owned entity in each country, not by the customer directly. We flag every EOR Contact in Crelate with custom fields: cf_eor_employer_entity, cf_eor_country, cf_eor_legal_entity_name. We do not migrate EOR records to a non-EOR destination without explicit customer sign-off on a compliance review. If the customer continues using an EOR provider post-migration, the EOR flag on the Contact allows the new provider to identify the relationship. If the customer is moving to self-employment in that country, the customer must establish a local legal entity before updating the Contact's employment status.

Asanify contractor records map to Crelate Contact records with contractor-specific custom fields: cf_contractor_type (1099 vs W-2), cf_contract_rate, cf_contract_currency, cf_contract_end_date, cf_contracting_entity. Multi-currency payout preferences migrate as a text field. The $18/contractor/month Asanify module data migrates as Contact records rather than a separate contractor object because Crelate does not have a native contractor record type separate from Contact.

Geo-tracked attendance logs have no native equivalent in Crelate. We export attendance records as a supplemental dataset keyed by employee email and date, including clock-in time, clock-out time, and geo-coordinates where captured. If the customer needs attendance data accessible within Crelate, we can store a summary note (total hours, attendance rate) on the Contact's activity timeline. Biometric device integration data (VIP-only) does not migrate.

Performance management and 360-degree feedback are VIP-tier features in Asanify. If the source account is on VIP, we export review cycles, ratings, and free-text feedback as custom fields on the Crelate Contact: cf_last_review_date, cf_overall_rating, cf_review_notes. Review question responses that are free-text require a manual mapping decision during scoping. If the source is on Essential tier, no performance data exists and there is nothing to migrate.

OKR goal tracking is a VIP-tier feature. If the source account is on VIP, company-level and individual OKR records migrate as a JSON blob in a long-text Crelate Contact custom field cf_okr_json, with a summary (current quarter objective, progress percentage) in a short-text field cf_current_objective. Key results and historical OKR records are preserved in full fidelity in the JSON export for the customer's admin to reference or import into a dedicated OKR tool post-migration.

KPI tracking is a VIP-tier feature tied to employee records. If the source is on VIP, KPI definitions and current values migrate as custom fields on the Crelate Contact: cf_kpi_definition, cf_kpi_current_value, cf_kpi_target_value, cf_kpi_unit. Historical KPI snapshots are not migrated as they require a separate extraction and have no equivalent activity model in Crelate's recruiting timeline.

Employee documents (offer letters, contracts, ID scans) are stored in Asanify on VIP and Enterprise tiers. Document files migrate as file attachments on the corresponding Crelate Contact record via Crelate's file import mechanism. Document naming conventions and folder structure in Asanify map to Crelate's document type categories. We export documents that are UI-accessible; programmatically inaccessible or encrypted documents are flagged and excluded from the export with a manifest entry.