Migrate from OctopusPro to Twenty CRM

OctopusPro Customer profiles (name, phone, email, address, notes) map directly to Twenty Person records. The primary email becomes the Twenty email field and serves as the dedupe key. Custom fields attached to the Customer profile in OctopusPro (vertical-specific data such as gate codes or pet health history) are migrated as Twenty custom fields on Person. The custom field schema is tenant-specific and must be requested from OctopusPro support during export discovery.

If OctopusPro Customer records include business entity data (company name separate from contact name), we create a Twenty Company record and link the Person as a relation (employee-of or contact-at). The mapping decision is confirmed during scoping by reviewing whether the OctopusPro export separates business and individual contact fields.

OctopusPro Bookings are the central object linking a Customer, Field Worker, Service, time slot, status, and Invoice. Twenty has no native booking or scheduling object, so we create a Booking Custom Object in Twenty with custom fields for customer (Person lookup), field worker (User lookup), service, scheduled date and time, status, and related invoice. Booking status history migrates as custom fields or as linked Task records if timeline tracking is needed.

OctopusPro Jobs are work order records that may exist independently of or alongside Bookings depending on the customer's workflow. We create a Job Custom Object in Twenty or, for simpler job tracking, use Task records with a custom job_reference__c field linking back to the parent Booking. Field-level job data (description, priority, tags, photos from forms) migrates as custom fields on the destination object. Form schema varies by service type; we flag any fields that require new custom field creation in Twenty during scoping.

OctopusPro Field Worker records (name, role, contact details, pay rate, location tracking preferences) map to Twenty User accounts. We resolve field workers by email match. GPS tracking preferences from the OctopusPro worker app are noted as custom fields in Twenty but do not activate live location sharing; that feature requires rebuild in Twenty using a third-party GPS integration.

OctopusPro Invoices (line items, tax, totals, payment status tied to a Booking) are reconstructed in Twenty as Opportunity records with custom fields capturing invoice_number__c, invoice_date__c, subtotal__c, tax_amount__c, total_amount__c, and payment_status__c. The Opportunity Stage maps to invoice payment status (Open, Won for paid, Closed Lost for written off). For businesses that need invoice documents, we attach the exported invoice PDF as a ContentDocument via ContentDocumentLink.

OctopusPro Payment records (amount, method, date, status against an Invoice) migrate as Task records linked to the parent Opportunity, with custom fields capturing payment_method__c, amount_paid__c, and payment_date__c. Partial payments and refunds are flagged as separate Task records with a payment_type__c custom field (full, partial, refund). This reconstructs the payment history against the Opportunity without requiring a native payment object in Twenty.

OctopusPro Quotes (pre-booking documents with line items, validity dates, and accept/reject status) migrate to Twenty as Opportunities with a quote_status__c custom field (pending, accepted, rejected, expired) and validity_date__c. Line items from the Quote migrate as OpportunityLineItem records if the Twenty workspace has a Pricebook2 configured; otherwise, they are stored as custom fields or a Note attachment.

OctopusPro Service definitions (name, description, pricing rules, duration, service area) migrate as a Service Custom Object in Twenty. This provides a reference catalog that can be linked from Booking or Job Custom Object records. Service pricing rules that drive invoice line items are stored as custom fields on the Service object. We create the Service Custom Object in Twenty's Data Model before any Booking or Job import.

OctopusPro allows custom fields on Customer profiles and Bookings to capture vertical-specific data. We discover the custom field schema by requesting a field inventory from OctopusPro support alongside the export. Each custom field is typed (text, number, date, picklist) and mapped to the corresponding Twenty object and field type. Custom fields that do not map directly (e.g., multi-checkbox in OctopusPro to multi-select picklist in Twenty) are flagged for transformation during scoping.

OctopusPro Forms and checklists capture structured field data at the job level (photos, tags, intake information). The form schema varies by service. We migrate available field data as custom fields on the Job or Booking Custom Object, with the raw form output stored as a Note attachment if the data does not fit a structured custom field. Any form field requiring a new custom field in Twenty is added to the Data Model before migration runs.

The OctopusPro Customer Portal is a configuration layer for self-booking, invoice viewing, and FAQ access. Portal settings, permission flags, and branded theme configurations do not migrate as data objects. We document the active portal features during scoping so the customer can configure equivalent functionality in Twenty or via a separate customer-facing tool post-migration.

OctopusPro Automations define trigger-action workflows for scheduling, notifications, and status changes. Twenty supports workflow automation from its Pro plan. We capture automation rules during scoping as part of the written inventory delivered to the customer. Automation logic is not migrated as code; the customer's admin rebuilds the relevant triggers in Twenty's workflow builder post-migration.

OctopusPro service-level FAQs are linked to specific Services and appear in the customer portal and email templates. FAQ content and service associations migrate as Note records linked to the corresponding Service Custom Object in Twenty, or as a long-text custom field on the Service object. Display configuration (portal placement, email inclusion) must be reconfigured in Twenty manually after migration.