CRM migration
Field-level mapping, validation, and rollback between Opera 3 and Nutshell. We move data and schema; workflows are rebuilt natively in Nutshell.
Opera 3
Source
Nutshell
Destination
Compatibility
8 of 10
objects map 1:1 between Opera 3 and Nutshell.
Complexity
BStandard
Timeline
2-4 weeks
Overview
Migrating from Pegasus Opera 3 to Nutshell is an ERP-to-CRM scope reduction. Opera 3 is a UK mid-market ERP that bundles accounting, payroll, stock, and a basic CRM module; Nutshell is a focused sales CRM with no accounting or payroll module. We migrate the CRM layer (Contacts, Companies, Deals, and activity notes) from Opera 3's Sales Ledger CSV exports and built-in CRM module, but accounting ledgers, payroll records, stock items, and fixed assets do not have a destination in Nutshell and are flagged as out-of-scope. Opera 3 has no public API, so extraction relies on CSV exports and RTI XML files where payroll data is involved. Multi-company structures in Opera 3 require manual reassignment in Nutshell because Nutshell uses a single-account model per subscription. Workflows, automations, and custom fields in Opera 3 are scoped as write-only inventory for the customer's admin to rebuild post-migration.
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 Opera 3 object lands in Nutshell, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Opera 3
Sales Ledger Contact (Customer)
Nutshell
People (Contact)
1:1Opera 3 Sales Ledger contacts export via CSV with full name, address, payment terms, credit limits, and multi-currency flags. We map AccountName to People.name, email addresses to People.email, postal address fields to People.address fields, and payment terms to a custom People field. Multi-currency contacts are noted for the customer to configure currency settings in Nutshell post-migration because Nutshell's per-contact currency is a paid Advanced plan feature.
Opera 3
Sales Ledger Contact (Supplier)
Nutshell
People (Contact)
1:1Opera 3 Purchase Ledger supplier contacts export via CSV in the same format as Sales Ledger contacts. We map these to Nutshell People with a supplier_flag__c custom field to distinguish them from customer contacts. Suppliers with no sales-facing email are imported with email blank, which Nutshell permits for contacts without email activity tracking.
Opera 3
CRM Company record
Nutshell
Company
1:1Opera 3's built-in CRM module stores Companies as separate records from Sales Ledger contacts. We map CRM Company name to Nutshell Company.name, CRM address fields to Company.address fields, and CRM industry or type data to a custom Company field. Where a CRM Company record and a Sales Ledger contact share the same name, we link them via Nutshell's People-Company relationship during import.
Opera 3
CRM Contact record
Nutshell
People (Contact)
1:1Opera 3 CRM Contacts export from the built-in CRM module, which is separate from the Sales Ledger contact file. We use email address as the dedupe key and match CRM Contacts to existing People records (from the Sales Ledger import) by email. Orphaned CRM Contacts without a matching Sales Ledger record are imported as standalone People. Mobile and direct phone fields map to People.phone and People.phone_extension where present.
Opera 3
CRM Activity (text notes)
Nutshell
People Activity (Call, Email, Meeting, Note)
1:manyOpera 3 CRM Activities are stored as free-text notes with a timestamp and activity type code rather than structured event records. We parse the activity type code to assign each note to a Nutshell Activity type: task-like entries become Note, entries with a meeting duration or location become Meeting, entries with a phone number become Call, and entries with an email subject line become Email. Entries with no type code become Note. Original timestamps are preserved in Nutshell's ActivityDate field.
Opera 3
Sales Order header
Nutshell
Deal
1:1Opera 3 Sales Order headers export via CSV with order number, customer reference, order date, and order total. We map these to Nutshell Deals with the order number in Deal.name, the customer as a linked Company, and the order total as the Deal.value. Order status flags (open, closed, invoiced) map to Nutshell Deal status values. Note that Nutshell Deals do not have a native line-item sub-object, so order line items are stored as Deal notes or as a linked custom object depending on scoping.
Opera 3
Sales Invoice header
Nutshell
Deal (closed)
1:1Opera 3 Sales Invoice records export via CSV with invoice number, customer, invoice date, and total. We map invoiced orders to Nutshell Deals with status set to Won and the invoice total as the Deal value. The original invoice number is preserved in a deal.invoice_number__c custom field. Invoices that have been fully paid map to a separate Deal status if Nutshell supports a paid/won state, or are noted for the customer to mark manually post-migration.
Opera 3
Multi-company structure
Nutshell
Multiple Nutshell accounts or Companies
lossyOpera 3 supports multiple company codes within a single installation with inter-company transactions stored as normal invoices with a counterparty code. Nutshell uses a single-company account model. For multi-company Opera 3 customers, we recommend either separate Nutshell subscriptions per legal entity or a single Nutshell account with Companies representing each Opera 3 entity. Inter-company debtor/creditor balances are exported as reconciliation notes for the customer's finance team to resolve in their accounting tool post-migration.
Opera 3
Nominal Ledger (Chart of Accounts)
Nutshell
Not migrated (accounting out of scope)
1:1Opera 3 Nominal Ledger accounts and financial transactions are accounting records that have no destination in Nutshell, which is a CRM without an accounting module. We export the Chart of Accounts as a CSV file delivered alongside the migration for the customer's finance team to use if they select a separate accounting tool (Xero, QuickBooks, or Sage) as the post-migration finance system. The CSV is not loaded into Nutshell.
Opera 3
Employee records and RTI payroll
Nutshell
Not migrated (payroll out of scope)
1:1Opera 3 Employee records export via CSV with bank details, start/end dates, P45 data, and RTI FPS/EPS XML files for payroll submissions. Nutshell has no payroll module, and employee records are not CRM contacts by default. We export employee data as a CSV for the customer's HR or finance team to manage in a dedicated payroll system. RTI XML files are handed off as-is for re-filing if required.
| Opera 3 | Nutshell | Compatibility | |
|---|---|---|---|
| Sales Ledger Contact (Customer) | People (Contact)1:1 | Fully supported | |
| Sales Ledger Contact (Supplier) | People (Contact)1:1 | Fully supported | |
| CRM Company record | Company1:1 | Fully supported | |
| CRM Contact record | People (Contact)1:1 | Fully supported | |
| CRM Activity (text notes) | People Activity (Call, Email, Meeting, Note)1:many | Fully supported | |
| Sales Order header | Deal1:1 | Fully supported | |
| Sales Invoice header | Deal (closed)1:1 | Fully supported | |
| Multi-company structure | Multiple Nutshell accounts or Companieslossy | Fully supported | |
| Nominal Ledger (Chart of Accounts) | Not migrated (accounting out of scope)1:1 | Fully supported | |
| Employee records and RTI payroll | Not migrated (payroll out of scope)1: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.
Opera 3 gotchas
Visual FoxPro to SQL SE migration is mandatory and non-reversible
RTI FPS/EPS payroll files use cryptic renamed filenames after HMRC submission
Customer Products add-on stores customer-specific stock variants outside the main item schema
No public API — data export relies on CSV, XML RTI files, or bespoke WCF
Multi-company inter-company balances require cross-reference mapping
Nutshell gotchas
Contact tier limits enforced on import
No bulk API endpoint requires paginated extraction
Email sequences not exportable via API
Foundation plan disables key sales features
Pair-specific challenges
Migration approach
Discovery and export scoping
We audit the Opera 3 installation to identify which modules are in scope for CRM migration: Sales Ledger contacts, Purchase Ledger contacts, CRM module Companies and Contacts, CRM Activities, Sales Orders, and Sales Invoices. We confirm the Opera 3 edition (Visual FoxPro or SQL SE) to determine the extraction method and field-length constraints. We also identify multi-company structures, bespoke OPUS add-on fields, and any custom Visual FoxPro modifications that may affect export completeness. The discovery output is a written export plan listing every CSV file, its expected row count, and any field-level issues to resolve before extraction.
CSV extraction and health validation
For each module in scope, we run the built-in Opera 3 CSV export or read directly from SQL SE. We validate record counts against the Opera 3 on-screen totals and flag any export failures. For CRM Activities, we extract the full text-note history with timestamps and type codes. For multi-company structures, we split the export by company code so each legal entity maps to a separate Nutshell account or Company record. We deliver the raw CSV files with a field-level data dictionary mapping each Opera 3 column to its Nutshell equivalent.
Activity type parsing and transformation
We process the Opera 3 CRM Activity CSV by parsing the activity type code embedded in each record and assigning it to a Nutshell Activity type: Call, Email, Meeting, or Note. Records with no type code default to Note. The original free-text body is preserved as the Nutshell Activity content. We generate a type-coverage report showing what percentage of activities receive a typed assignment versus defaulting to Note, so the customer understands the resulting Nutshell activity timeline before cutover.
Sandbox migration and reconciliation
We run a trial migration into a Nutshell sandbox or a fresh Nutshell trial account using the extracted CSV files. The customer reconciles record counts across all object types, spot-checks 25-50 records against the Opera 3 source data (matching by name, email, and phone where available), and validates the activity timeline for a sample of contacts. Any mapping corrections, dedupe merges, or multi-company assignment changes are documented and applied to the production migration plan. This step cannot be skipped because CSV-based extraction does not support real-time validation during load.
Production migration in dependency order
We run the production migration in object dependency order: Companies first (to receive People-Company lookups), then People (Contacts and Suppliers with company assignments resolved), then CRM Activities linked to the correct People records by email or name match, then Deals (from Sales Orders and closed invoices), then any final activity delta. Each phase emits a row-count reconciliation report. Nutshell's REST API is used for the production load; we handle rate-limit responses with exponential backoff and chunking for large datasets.
Cutover, handoff inventory, and post-migration review
We freeze Opera 3 CRM writes during the cutover window, run a final delta migration of any records modified during migration, then enable Nutshell as the active CRM. We deliver a written inventory of Opera 3 CRM workflows, automation rules, and any OPUS add-on custom fields that require rebuild in Nutshell. The inventory lists each item with its trigger, conditions, and a brief Nutshell equivalent recommendation. We do not rebuild workflows or automations inside the migration scope; that is a separate engagement or an internal admin task.
Platform deep dives
Opera 3
Source
Strengths
Weaknesses
Nutshell
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 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 Opera 3 and Nutshell.
Object compatibility
1 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
Opera 3: Not publicly documented — no published API means no documented rate limits.
Data volume sensitivity
Opera 3 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 Opera 3 to Nutshell migration scoping. Not seeing yours? Book a call.
Walk through your Opera 3 to Nutshell migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Opera 3
Other ways to arrive at Nutshell
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.