Migrate from Bilr to Freshsales

Freshsales Growth plan caps custom fields at 10 — migration will be throttled by destination plan tier

Bilr setups with more than 10 custom properties (billing rate, practice area, responsible attorney, LEDES code, trust flags, etc.) exceed the Freshsales Growth plan limit of 10 custom fields per module. We flag every custom field and its destination object during the pre-migration audit. If the destination is on the Growth plan, we recommend upgrading to Pro before migration or consolidating non-essential Bilr fields into JSON-encoded text blobs. This is a migration-blocking decision if not resolved before data lands — Freshsales will reject records with unmapped custom field values.

Trust accounting has no Freshsales equivalent — ledger history must be preserved as a custom object

Bilr's trust accounting module tracks IOLTA and client trust ledgers with running balances. Freshsales has no trust accounting, no IOLTA, and no LEDES billing code structure. We create a Trust_Accounting__c custom object with ledger_type, amount, running_balance, and reference_number fields — but Freshsales cannot run trust reconciliation natively. The ledger data migrates as read-only historical records; actual trust accounting must be handled in a dedicated legal billing system post-migration. This is a material gap for law firms that rely on trust accounting as part of their compliance workflow.

Matter hierarchies require a custom module — Freshsales has no sub-opportunity structure

Bilr supports nested sub-matters where a parent matter can have child matters, each with their own billing records. Freshsales Opportunities have no native sub-opportunity or hierarchical opportunity structure. We handle this by creating a Sub_Matter__c custom object linked to the parent Opportunity via a lookup relationship. The custom object preserves the matter number, relationship type, and billing attribution. During the sample migration, we verify that the custom object and lookup field are correctly configured in the destination Freshsales portal before committing to the full load.

API rate limits constrain bulk migration speed — Growth plan is capped at 1,000 requests per hour

The Freshsales REST API enforces rate limits by plan tier: 1,000 requests per hour on Growth, 2,000 on Pro, and 5,000 on Enterprise. A migration with 50,000 Bilr records can require 15,000–25,000 API calls when accounting for read, create, and update operations. We batch records into chunks, throttle requests to respect the per-hour limit, and use the 429 (Too Many Requests) response to trigger automatic back-off. For large migrations on Growth plan, a dedicated migration window with night-time batching is recommended to avoid hitting limits during business hours.

Bilr workflows and automation templates do not transfer — manual rebuild required

Any automated processes, templated workflows, or billing automations configured in Bilr have no equivalent in Freshsales and cannot be migrated as data. We export the Bilr workflow definitions as a structured JSON document listing triggers, conditions, and actions. The Freshsales admin then rebuilds these in Freshsales under Admin Settings > Workflows, using the exported document as a functional specification. Freshsales Workflows support trigger-based automation (record creation, field update, stage change) and time-based delays, which cover most legal billing automation patterns — but LEDES-specific billing rules may require external tooling.