Migrate from Opera 3 to HighLevel

Opera 3 Sales Ledger contact records export via CSV with full address, payment terms, credit limits, and multi-currency flags intact. We map each contact to a GoHighLevel Contact record, preserving the account reference as an external ID and the primary email and phone as the dedupe keys. Sales person and territory assignments from Opera 3 map to custom fields or contact tags in GoHighLevel.

Opera 3 Purchase Ledger supplier records have no native GoHighLevel equivalent because GoHighLevel is CRM-focused rather than accounting-focused. We map suppliers to a Custom Object named Supplier with fields for company name, contact name, email, phone, payment terms, and account reference. This is a GoHighLevel Custom Object rather than a native Contact to keep supplier and customer data streams separate.

Opera 3 multi-company structures map to GoHighLevel Company records. The company code from Opera 3 becomes a custom field on the Company record. For customers with separate legal entities that need data isolation, we set up GoHighLevel Locations to partition the data; sub-accounts (available on SaaS Pro) are an option for full isolation but require a higher plan tier.

The Opera 3 Nominal Ledger stores the chart of accounts with cost-centre tagging. GoHighLevel has no native accounting module, so we cannot create a functioning GL. We map the account code hierarchy to a Custom Object (Nominal Account) with fields for account code, account name, account type, and cost centre. This provides a reference record for the finance team but is not a live accounting ledger.

Opera 3 Sales Order headers and line items export with pricing, discounts, delivery addresses, and status flags. We map the order header to a GoHighLevel Opportunity record inside a Pipeline, with order value and close date migrated. The line items migrate as Opportunity custom fields or a linked Custom Object (Order Line Item) to preserve product, quantity, unit price, and discount detail. We preserve the order-to-invoice linkage chain in a custom field for audit.

Purchase orders in Opera 3 contain supplier reference, line items, and status. Because GoHighLevel has no native purchase order module, we map these to a Custom Object named Purchase Order with fields for supplier lookup, order date, expected delivery, status, and a JSON-serialised line-item block. Status flags (live, closed, cancelled) become picklist values.

Sales and Purchase invoices with header totals and line detail export cleanly from Opera 3, but GoHighLevel has no native invoicing module beyond basic payment links. We map invoices to a Custom Object named Invoice with fields for invoice number, date, customer or supplier reference, total amount, status, and a line-item block. PDF invoice archives are extracted from Opera 3's document folders and attached to the corresponding Invoice Custom Object record as file attachments.

Opera 3 stock codes, descriptions, bin locations, reorder levels, and BOM structures export via CSV. We map stock items to GoHighLevel Products with product name, SKU (from stock code), description, and price. Customer-specific product variants from the OPUS add-on require additional mapping: we join the OPUS export to the main stock file by base stock code and customer reference, then create a Custom Object (Customer Product) linked to both the Product and the Contact to preserve the customer-specific pricing and description.

Opera 3 employee records export via CSV including bank details, start/end dates, and P45 data. RTI FPS XML files contain tax submission records and EPS files hold employer payment summaries. We map employees to GoHighLevel Contacts with a contact type tag of Employee, and map payroll data (NI number, tax code, annual salary, payment frequency) to a Custom Object named Payroll Record linked to the Contact. We do not migrate RTI submission logic; the finance team sets up payroll processing in a dedicated UK payroll tool post-migration.

Opera 3 fixed asset registers export with acquisition dates, cost, depreciation method, net book value, and disposal history as structured records. GoHighLevel has no fixed asset module. We map these to a Custom Object named Fixed Asset with fields for asset description, asset tag, acquisition date, original cost, depreciation method, accumulated depreciation, NBV, and disposal date. The finance team uses this as a reference register rather than a live depreciation engine.

Opera 3 project cost codes and phase-level tracking with labour, purchase, and expense allocations export linked to the Nominal Ledger. We map projects to GoHighLevel Opportunities in a dedicated Pipeline (Project Pipeline) with phase names mapped to stage values, and cost code totals mapped to custom fields on the Opportunity. If the project structure is complex, we use a Custom Object named Project with a one-to-many relationship to a Custom Object named Project Phase.

Opera 3's built-in CRM module stores contacts, companies, and text-based activity notes. Activities are free-text records rather than structured event objects, which limits how precisely they map to GoHighLevel's activity model. We map text notes from Opera 3 to GoHighLevel Activity records with the original timestamp preserved as ActivityDate, the contact linked via ContactId, and the note body in the description field. This gives a functional timeline view even though Opera 3 activities lack the structured type metadata (call, email, meeting) that GoHighLevel activity subtypes provide.