Migrate from Opera 3 to Freshsales

Opera 3 Sales Ledger contact records export via CSV with fields for account code, company name, billing address, delivery address, payment terms, credit limit, and multi-currency settings. We map the Opera 3 account code to Freshsales Contact phone/email fields and create the Contact record with the full postal address stored in Freshsales' address compound field. Any Opera 3 contact without an email address is flagged for manual enrichment during migration.

Opera 3 Purchase Ledger supplier records use the same account schema as Sales Ledger but with supplier-specific fields. We map these to Freshsales Account records with the Account Type field set to Vendor for suppliers and Customer for any supplier records that also have outgoing sales invoices. This requires a dedupe check against any Sales Ledger accounts with matching company names.

Opera 3 multi-company configurations store separate company codes with individual Sales Ledger, Purchase Ledger, and Nominal Ledger instances. We export each company code as a separate entity and create a corresponding Freshsales Account. For inter-company transactions (where one Opera 3 company code invoices another), we flag these as internal and do not create duplicate Accounts; instead, we map the counterparty company code to a note field on the Account for reconciliation.

Opera 3 order headers and line items export with order number, order date, status (open/closed), customer reference, delivery address, and line-level pricing including discounts. We map these to Freshsales Deals with the order number stored as a custom field, order date as Deal creation date, and the delivery address as a custom address field on the Deal. Line items are not a standard Freshsales object; we store them as a JSON-formatted note attachment or as Deal Product records if the customer's Freshsales plan includes the Products module.

Opera 3 invoices export with header totals that must reconcile to the sum of line items (enforced by the SQL SE health checker). We map closed invoices to Freshsales Deals with stage set to Closed Won, invoice total as Deal Amount, and invoice date as close date. The invoice PDF (migrated from Opera 3's document folder) attaches as a note to the Deal. Invoice line items store as a JSON note on the Deal since Freshsales does not have a native invoice line item object.

Opera 3's built-in CRM module stores contacts with company association, activity notes (text-based), and custom fields from the OPUS add-on. Activity notes export as plain text and map to Freshsales Activity records (type = Note) linked to the Contact. OPUS custom fields are not standardised and require manual field-by-field review; we flag each one as unmapped in the written inventory.

Opera 3 activity logs are text-based notes rather than structured events with timestamps, attendees, or disposition codes. We extract the note body and creation date, then create Freshsales Activity records with type = Note attached to the corresponding Contact or Account. The original timestamp is preserved as the Activity Date. Call disposition, duration, and meeting attendee data (if present) map to Freshsales Call or Meeting activity types with the relevant fields populated.

The OPUS add-on stores customer-specific stock code variants outside the main stock schema — a different product code and description per customer for the same base product. We join the OPUS export to the main product export using the base stock code and customer account reference, then create Freshsales Price List entries tied to the Account. This requires the customer to confirm whether Freshsales Products or Price List entries are the preferred destination for variant pricing. We do not auto-create products; we deliver a mapping table for the admin to configure.

Opera 3 employee records export via CSV with name, email, start/end dates, bank details, and P45 data. RTI FPS XML files contain tax submission records and EPS files hold employer payment summaries. We map Opera 3 employees who are active sales or service users to Freshsales User records (for Owner assignment), and non-user employees to Contact records for reference. The customer's Freshsales admin provisions the User accounts and assigns role-based permissions before migration begins.

Custom fields added via the OPUS add-on or bespoke modifications to the Visual FoxPro schema are not standardised across installations. We do not automatically migrate bespoke custom fields. We deliver a written inventory of every OPUS custom field found in the export, including its data type, current values, and the objects it applies to, so the customer's admin can create equivalent custom fields in Freshsales and map them manually.