Migrate from Opera 3 to Salesforce Sales Cloud

Opera 3's Sales Ledger stores customer records as a single contact entity with company name, billing address, delivery address, payment terms, credit limit, and multi-currency settings. We split this into a Salesforce Account (the company entity) and a Contact (the primary billing or operations contact). Additional contact roles on the same company in Opera 3 map to additional Contact records under the same Account. The Account.Industry and Account.Type fields are populated from Opera 3's account classification codes.

Opera 3 Purchase Ledger suppliers map to Salesforce Account records with Type = Vendor. Supplier payment terms, bank details, and currency settings migrate to Account fields or custom fields. Purchase Ledger contacts do not map to Salesforce Contact records unless the supplier has a named purchasing contact that the business wants to track as a Salesforce Contact linked to the vendor Account.

Opera 3 Nominal Ledger accounts with cost-centre tagging map to a custom GL_Account__c object in Salesforce if the customer does not already have an ERP integration that manages the chart of accounts. Account codes, descriptions, and cost-centre assignments migrate as structured records. We do not replicate Opera 3's double-entry journal logic in Salesforce because Salesforce is not an accounting system — we preserve the chart as reference data for reporting and reconciliation purposes only.

Opera 3 Sales Orders map to Salesforce Opportunity. Order header fields (order number, date, status, delivery address) map to Opportunity fields and custom fields. Order status in Opera 3 (Quoted, Confirmed, Despatched, Invoiced) maps to Opportunity StageName, with a custom field o3_original_status__c preserving the source status for audit. The order-to-invoice linkage chain in Opera 3 is preserved as a custom Opportunity field linking to the related invoice Opportunity or Quote.

Closed invoices in Opera 3 (status = Invoiced) are mapped to Salesforce Opportunity records with StageName = Closed Won for sales invoices, or to a custom Invoice__c object if the customer needs line-item invoice detail preserved beyond the Opportunity summary. Invoice totals are validated against line-item sums before load — any mismatch is flagged for correction. Credit notes map to Opportunity records with StageName = Closed Lost and a custom type field distinguishing them from cancellations.

Opera 3 stock codes with bin locations, reorder levels, and BOM structures map to Salesforce Product2 records. ProductCode maps from the Opera 3 stock code. Standard Price Book entries are created during migration with the last purchase or selling price from Opera 3. Customer-specific product variants from the OPUS add-on (which stores a different stock code and description per customer) are mapped to Salesforce PricebookEntry records scoped per Account, preserving the customer-specific description as a custom field.

Opera 3 bill-of-materials structures map to a custom Product_Component__c junction object linking parent Product2 records to child Product2 components with quantity-per-assembly stored as a custom field. This preserves the BOM as reference data in Salesforce for quoting and product configuration use cases.

Opera 3 employee records export via CSV including name, start and end dates, bank details, and P45 data. Active employees with Salesforce seat licences map to User records with the employee number stored as a custom External_ID__c field for deduplication. Inactive employees and contractors without Salesforce licences are mapped to a custom Employee__c object to preserve HR audit data without consuming Salesforce user licences.

Pegasus Opera 3's RTI FPS (Full Payment Submission) and EPS (Employer Payment Summary) XML files contain tax period, pay, deductions, and NIC data submitted to HMRC. We parse the XML, map each FPS submission to a custom Payroll_Submission__c record linked to the corresponding Employee__c or User record, and preserve the submission date, tax period, and amounts as structured fields. The cryptic renamed filenames (Z_FPS.RTI to timestamped .BAK files after HMRC submission) are resolved by matching file timestamps to the tax period.

Opera 3 Projects with phase-level labour, purchase, and expense allocations map to Salesforce Opportunity records with a custom project flag. Phase-level tracking and cost-code allocations migrate to a custom Project_Phase__c object linked to the Opportunity. If the customer uses Salesforce Financial Services Cloud or a project management integration, we map to the relevant standard object instead and scope this during discovery.

Opera 3 fixed assets with acquisition date, cost, depreciation method, net book value, and disposal history map to Salesforce Asset records. Asset records are linked to the related Account (vendor for capital purchases or customer if leasing) and include custom fields for depreciation_method__c, nbv__c, and acquisition_cost__c. Disposal history is stored as Asset history records or custom disposal transaction records.

Opera 3 multi-currency settings, exchange rates at transaction time, and foreign-currency amounts migrate to Salesforce as custom fields on Account and Opportunity. Currency codes map from Opera 3 currency codes. The exchange rate used at transaction time is stored as a custom field on each transaction record rather than relying on Salesforce's own currency conversion, because Opera 3 historically uses contracted or locked rates that differ from daily market rates.

Opera 3 multi-company configurations store each legal entity as a separate company code with its own chart of accounts and inter-company debtor and creditor balances. We map each Opera 3 company to a Salesforce Account at the top of a hierarchy, with inter-company transactions remapped so the destination correctly identifies them as internal transfers rather than third-party transactions. Inter-company balance reconciliation reports are generated before cutover to ensure the consolidated view is accurate in Salesforce.

Opera 3 stores PDF invoices, statements, and remittance advices as binary files in document folders. We extract each PDF, map it to a Salesforce ContentDocument record, and attach it via ContentDocumentLink to the corresponding Account, Opportunity, or Asset record. File naming conventions in Opera 3's document archive determine the linkage — we parse the filename to extract the invoice number or account reference, then resolve the link in Salesforce. Files without a resolvable reference are attached to the related Account as orphaned documents for manual reconciliation.

Opera 3's built-in CRM module stores contacts, companies, and activity logs as text-based notes rather than structured event records. We map CRM contact records to Salesforce Contact under the related Account. Activity notes migrate to Salesforce Note records linked via ContentDocumentLink to the parent Contact or Account. Because Opera 3 CRM activities do not have structured event types or timestamps in a standardised format, we map the note body and creation date, and flag records where the activity type could not be determined for manual review.