CRM migration
Field-level mapping, validation, and rollback between MiniCRM and Freshsales. We move data and schema; workflows are rebuilt natively in Freshsales.
MiniCRM
Source
Freshsales
Destination
Compatibility
7 of 9
objects map 1:1 between MiniCRM and Freshsales.
Complexity
BStandard
Timeline
2-4 weeks
Overview
Moving from MiniCRM to Freshsales is a structural migration that requires handling a significant tooling asymmetry: MiniCRM has limited documented API export endpoints and relies on manual CSV exports in many cases, while Freshsales exposes a well-documented REST and Bulk API. We extract MiniCRM data through available export channels, clean and deduplicate records during staging, then load into Freshsales using its Contacts, Accounts, Deals, and Tasks objects. The primary mapping challenge is MiniCRM's Card-centric model (Karty), which is a hybrid record container combining contact details, deal associations, and custom fields. We split Card fields to their correct Freshsales objects (Contact, Account, Deal) during transformation. Custom fields on Cards require explicit type mapping because Freshsales requires lead-field conversion mapping for any custom field on a Lead to survive the convert action. We flag MiniCRM automation rules as non-migratable and deliver a written inventory for rebuild in Freshsales Workflows.
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 MiniCRM object lands in Freshsales, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
MiniCRM
Card (Karta)
Freshsales
Contact or Lead (split required)
1:manyMiniCRM Cards are hybrid containers holding contact details, company associations, deal associations, and custom fields simultaneously. We split Card fields during transformation: primary contact fields (name, email, phone, address) map to Freshsales Contact; any fields the customer designates as prospect-specific (prior to deal qualification) map to Freshsales Lead. We preserve the original Card ID in a custom field mini_crm_card_id__c on both Lead and Contact for reconciliation. The split rule is defined during scoping based on the customer's MiniCRM pipeline usage and business process.
MiniCRM
Company (Firma)
Freshsales
Account
1:1MiniCRM Company records map to Freshsales Account. Company name becomes Account Name; available fields (industry, website, address) map to Freshsales Account fields. Where MiniCRM Company records are sparse (MiniCRM supports fewer normalized fields than typical CRM Account objects), we map the available fields and note any gaps in the scoping report. Account is created before Contact import so the AccountId lookup is satisfied at Contact insert.
MiniCRM
Deal / Interest (Interes)
Freshsales
Deal
1:1MiniCRM Deals are called 'Interests' and are associated with Cards. Deal name, value, stage, and close date map to Freshsales Deal fields. MiniCRM pipeline stage names (often in Polish) are mapped to Freshsales Deal stage values during scoping. The customer configures the Freshsales pipeline stages before migration so that deal stages land in the correct positions.
MiniCRM
Task (Zadanie)
Freshsales
Task
1:1MiniCRM Tasks linked to Cards migrate to Freshsales Tasks with due date, status, assignee (resolved via email to User), and description preserved. Task recurrence patterns and reminder settings in MiniCRM require explicit mapping; these do not have direct Freshsales equivalents and are documented in the scope for admin rebuild in Freshsales Workflows if needed.
MiniCRM
Note (Notatka)
Freshsales
Note
1:1Free-text notes attached to Cards migrate as long-text Note records in Freshsales, linked via ContentDocumentLink to the parent record (Contact, Account, or Deal). Note body migrates as-is; we preserve the association to the original Card record via mini_crm_card_id__c.
MiniCRM
Custom Field (Pole dodatkowe)
Freshsales
Custom Field (on Contact, Account, Deal, or Lead)
lossyMiniCRM custom fields on Cards (text, number, date, choice types) require pre-creation in Freshsales before migration begins. Choice fields require value mapping: MiniCRM picklist values must be matched to Freshsales picklist values. For Lead custom fields specifically, Freshsales requires explicit field mapping in Admin Settings > Leads Module > Field Mapping or data is lost during Lead conversion. We configure this mapping during Freshsales setup before any Lead records import.
MiniCRM
User / Worker (Pracownik)
Freshsales
User
1:1MiniCRM user records (name, email, role) map to Freshsales User by email match. Role distinctions in MiniCRM may not map directly to Freshsales' permission model; we document the gap in the scoping report and the customer's Freshsales admin configures role-based access post-migration.
MiniCRM
Tag / Label
Freshsales
Tag
1:1Tags applied to MiniCRM Cards for segmentation migrate to Freshsales Tag fields on the corresponding Contact or Account. We deduplicate tags during import to avoid carrying over messy taxonomy from the source system.
MiniCRM
Attachment reference
Freshsales
Attachment or ContentDocument
1:1File attachments stored against MiniCRM Cards migrate where the platform exposes them via export. We flag any attachment size limits during scoping and handle file references to ensure records point to the correct attachments in the destination. Full file binary transfer depends on MiniCRM's export capability for the specific account.
| MiniCRM | Freshsales | Compatibility | |
|---|---|---|---|
| Card (Karta) | Contact or Lead (split required)1:many | Fully supported | |
| Company (Firma) | Account1:1 | Fully supported | |
| Deal / Interest (Interes) | Deal1:1 | Fully supported | |
| Task (Zadanie) | Task1:1 | Fully supported | |
| Note (Notatka) | Note1:1 | Fully supported | |
| Custom Field (Pole dodatkowe) | Custom Field (on Contact, Account, Deal, or Lead)lossy | Fully supported | |
| User / Worker (Pracownik) | User1:1 | Fully supported | |
| Tag / Label | Tag1:1 | Fully supported | |
| Attachment reference | Attachment or ContentDocument1: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.
MiniCRM gotchas
Automation rules do not export via API
Pricing tier boundaries are opaque
API export tooling is limited and undocumented
Acquisition by group.one may affect product continuity
Polish-language interface and documentation
Freshsales gotchas
Freddy AI is Pro-tier only despite heavy marketing
Post-migration emails and sequences are disabled
Bot session credits are a one-time 500-session allocation
Phone credits charged per minute with no cap
File storage limits scale with plan tier
Pair-specific challenges
Migration approach
Discovery and MiniCRM export sourcing
We audit the MiniCRM account for all object types in scope: Cards, Contacts, Companies, Deals (Interests), Tasks, Notes, Custom Fields, Users, Tags, and attachment references. We confirm the export method available for this specific account (CSV export, manual export request, or API-based if accessible). We also document active automation rules, pipeline stage names (in Polish), and custom field configurations. If MiniCRM's export tooling is constrained, we plan for manual export assistance and adjust the timeline accordingly.
Freshsales schema setup and lead-field mapping configuration
We configure Freshsales before any data import. This includes provisioning custom fields (with types matched to MiniCRM field types), configuring pipeline stages and Deal statuses, setting up Account and Contact record types if needed, and configuring the Lead custom field mapping under Admin Settings > Leads Module so that any custom fields designated as prospect-level survive Lead conversion. We also set up the User records or confirm User provisioning for the owner reconciliation step.
Data extraction, cleaning, and transformation
We extract data from MiniCRM using the available export method, stage it in a working environment, and perform cleaning: deduplication (particularly for Contacts with identical email addresses), standardization of date and phone formats, and resolution of Polish-language labels via the customer's confirmation during scoping. We apply the Card-to-object split: contact fields to Freshsales Contact or Lead, company fields to Freshsales Account, deal fields to Freshsales Deal. Custom fields are mapped and validated against the Freshsales schema created in step two.
Owner reconciliation and User provisioning
We extract every distinct MiniCRM user referenced on Cards, Tasks, Notes, and Deals and match by email against the Freshsales destination org's User table. Owners without a matching User go to a reconciliation queue. The customer's Freshsales admin provisions any missing Users before record import resumes. OwnerId references must be valid on import or records are rejected or assigned to the running user.
Production migration in dependency order
We run production migration in record-dependency order: Accounts (from MiniCRM Companies), Contacts and Leads (with AccountId resolved for Contacts, and the lead-field mapping validated), Deals (with AccountId, OwnerId, and stage resolved), Tasks and Notes (via Freshsales API or CSV import with parent-record lookups), and Tags. Custom fields are loaded after the base objects are confirmed. Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, validation, and automation rebuild handoff
We freeze MiniCRM writes during cutover and run a final delta migration of any records modified during the migration window. We validate a random sample of records against the MiniCRM source for field accuracy. We deliver the automation rules inventory document to the customer's admin team with recommended Freshsales Workflow equivalents. We support a brief post-migration check window for reconciliation issues. We do not rebuild MiniCRM automation rules as Freshsales Workflows inside the migration scope; that is a separate engagement or an internal admin task.
Platform deep dives
MiniCRM
Source
Strengths
Weaknesses
Freshsales
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 2 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 MiniCRM and Freshsales.
Object compatibility
2 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
MiniCRM: Not publicly documented.
Data volume sensitivity
MiniCRM 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 MiniCRM to Freshsales migration scoping. Not seeing yours? Book a call.
Walk through your MiniCRM to Freshsales migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave MiniCRM
Other ways to arrive at Freshsales
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.