CRM migration
Field-level mapping, validation, and rollback between Shark Byte CRM and Twenty CRM. We move data and schema; workflows are rebuilt natively in Twenty CRM.
Shark Byte CRM
Source
Twenty CRM
Destination
Compatibility
4 of 10
objects map 1:1 between Shark Byte CRM and Twenty CRM.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Shark Byte CRM to Twenty CRM is a migration from a vertical-specific, connectivity-dependent field-service tool into a modern open-source CRM with full data ownership and self-hosting capability. Shark Byte has no documented public API, which makes the extraction phase the most time-sensitive and risk-heavy part of the engagement. We work with Shark Byte file exports and coordinate directly with their team for complete data extraction. In Twenty, we build a custom object schema to accommodate Shark Byte's estimating templates, service agreements by contract-term duration (1-3 year, 3-5 year, 10+ year buckets), and work order records. Shark Byte's Customers map to Twenty's Company object, Contacts map to Person, and all vertical-specific records (Estimates, Proposals, Service Agreements, Work Orders) require custom object creation in Twenty via the /metadata API. We do not migrate Shark Byte workflows or mobile surveying templates as code; we deliver a written inventory of active configurations and attachments for the customer's admin to rebuild. Timeline ranges from three to six weeks depending on data volume and the complexity of custom field mapping.
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 Shark Byte CRM object lands in Twenty CRM, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Shark Byte CRM
Customer
Twenty CRM
Company
1:1Shark Byte Customer records (representing end-client organizations or homeowners) map to Twenty Company. Standard fields including company name, address, and service history transfer as Company displayName, address fields, and custom fields. We use company name as the dedupe key during import and extract any service history as a custom field group on the Company record. Customer custom fields migrate to Company custom fields created via the /metadata API before import.
Shark Byte CRM
Contact
Twenty CRM
Person
1:1Shark Byte Contact records (individual points of contact at each Customer site) map to Twenty Person. Fields including name, phone, email, and role transfer directly. Note that Twenty's Person object has been flagged by the community (GitHub issue #13953) as missing standard fields like multiple phone types, job title, department, and social profiles out of the box. We create these custom fields via /metadata during schema setup if they exist in Shark Byte.
Shark Byte CRM
Estimate
Twenty CRM
Custom Object: Estimate
lossyEstimates are the core product object in Shark Byte CRM, built using the platform's estimating engine with line items, labor rates, and material costs. Because Twenty has no native estimating object, we create a custom Estimate object via the /metadata API with fields for line items, contract-term bucket (1-3 year, 3-5 year, 10+ year), pricing logic, and linked Company. We preserve the original Shark Byte estimate metadata as custom fields and link each Estimate to its originating Customer (now Company) and Contact (now Person).
Shark Byte CRM
Proposal
Twenty CRM
Custom Object: Proposal
lossyShark Byte Proposals are generated from Estimates and include pricing, scope, and terms. We create a custom Proposal object in Twenty linked to the custom Estimate object via a lookup relationship. Proposal status, scope description, terms, and associated Contact transfer as fields. Signed proposal PDFs migrate as attachments linked to the Proposal record via ContentDocumentLink.
Shark Byte CRM
Service Agreement
Twenty CRM
Custom Object: Service Agreement
lossyService Agreements in Shark Byte represent recurring contracts tied to maintenance programs, analyzed across 1-3 year, 3-5 year, and 10+ year term buckets calibrated to the customer's historical data. We create a custom Service Agreement object in Twenty with fields for contract-term classification, start and end dates, pricing structure, and linked Customer and Contact. This is the most schema-dependent mapping because Shark Byte's term buckets are customer-specific.
Shark Byte CRM
Work Order
Twenty CRM
Custom Object: Work Order
lossyWork Orders track individual jobs dispatched to technicians. Mobile building surveying tools in Shark Byte feed into Work Order creation. We create a custom Work Order object in Twenty with fields for status, assigned technician, line items, and linked Customer and Contact. Survey photos and site condition attachments migrate as ContentDocument records linked via ContentDocumentLink to the Work Order.
Shark Byte CRM
Attachments
Twenty CRM
ContentDocument / ContentDocumentLink
1:1Shark Byte CRM supports file attachments on Customer, Estimate, Proposal, and Work Order records. We extract all available attachments at original resolution where possible and migrate them as ContentDocument records in Twenty, linked to the appropriate parent record via ContentDocumentLink. Mobile survey images may have inconsistent compression levels and missing EXIF metadata depending on the device used; we note this during extraction and preserve filenames and upload timestamps as metadata on the ContentDocument record.
Shark Byte CRM
Custom Properties
Twenty CRM
Custom Fields
lossyShark Byte CRM supports custom fields on primary objects, particularly on Estimates and Service Agreements to accommodate industry-specific data like equipment specifications or contract classification. We create matching custom fields on Twenty's Company, Person, and custom objects via the /metadata API before data import. Each custom field is created with the correct field type (string, number, date, picklist) matched from the Shark Byte field definition.
Shark Byte CRM
Owner
Twenty CRM
User
1:1Shark Byte Owner records (technicians and sales users assigned to Estimates, Work Orders, and Proposals) map to Twenty User records. We resolve owners by email match where possible. Any Shark Byte Owner without a matching Twenty User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Owner assignments on Work Orders and Estimates transfer as custom owner fields or assigned-to relationships depending on the custom object schema.
Shark Byte CRM
Pipeline / Status
Twenty CRM
Custom Field or View Filter
lossyShark Byte's pipeline stages and status conventions for Estimates, Proposals, and Work Orders are custom to the account and do not map to any standard Twenty field. We create custom picklist fields on each custom object representing the relevant stage values (e.g., Estimate status: Draft, Submitted, Accepted, Lost; Work Order status: Scheduled, In Progress, Completed, On Hold). The customer approves the stage mapping during scoping.
| Shark Byte CRM | Twenty CRM | Compatibility | |
|---|---|---|---|
| Customer | Company1:1 | Fully supported | |
| Contact | Person1:1 | Fully supported | |
| Estimate | Custom Object: Estimatelossy | Fully supported | |
| Proposal | Custom Object: Proposallossy | Fully supported | |
| Service Agreement | Custom Object: Service Agreementlossy | Fully supported | |
| Work Order | Custom Object: Work Orderlossy | Fully supported | |
| Attachments | ContentDocument / ContentDocumentLink1:1 | Mapping required | |
| Custom Properties | Custom Fieldslossy | Mapping required | |
| Owner | User1:1 | Fully supported | |
| Pipeline / Status | Custom Field or View Filterlossy | 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.
Shark Byte CRM gotchas
No publicly documented API for programmatic data export
Estimating templates and contract-term mappings are custom to the account
Mobile survey attachments may have inconsistent file formats
Small vendor footprint complicates support coordination during cutover
Twenty CRM gotchas
Import order is enforced and critical
Export limited to 20,000 records and visible columns only
Soft-deleted records count toward uniqueness and trigger restores
API rate limits cap at 200 req/min on Organization tier
No native email sequences — follow-up cadences require external tools
Pair-specific challenges
Migration approach
Extraction scoping and Shark Byte coordination
We begin by auditing the Shark Byte installation to identify all Customer, Estimate, Proposal, Service Agreement, Work Order, Contact, and attachment records. Because Shark Byte has no public API, we work with the customer's team to request full data exports in whatever format Shark Byte supports (CSV, Excel, JSON). We coordinate directly with Shark Byte's small team to schedule export delivery and validate completeness before proceeding. Any manual extraction steps are documented with time estimates and added to the project schedule as an explicit extraction phase.
Twenty custom object schema design
We design the destination schema in Twenty using the /metadata API. This includes creating custom objects for Estimate, Proposal, Service Agreement, and Work Order, plus custom fields on Company and Person for any Shark Byte fields that don't map to Twenty standard fields. We define lookup relationships between custom objects and Company/Person, create picklist values for contract-term buckets and status fields, and validate the schema in a staging environment before any data loads. The customer reviews and approves the schema during this phase.
Data quality audit and cleansing
We audit the extracted Shark Byte data for duplicates, incomplete records, inconsistent formats (addresses, phone numbers, dates), and orphaned relationships (Estimates with no linked Customer, Work Orders with no assigned technician). We run data quality reports and share findings with the customer before migration. Any cleansing decisions (duplicates to merge, missing Customer links to resolve, date format normalization) are documented and executed as a separate transform step before import.
Sandbox migration and reconciliation
We run a full migration into a staging environment in Twenty using production-like data volume. The customer's admin reviews record counts, spot-checks 25-50 random records against the Shark Byte source, and validates that custom field values match the original data. The owner reconciliation queue (any Shark Byte Owner without a matching Twenty User) is resolved here. The customer approves the sandbox migration before production migration begins.
Production migration in dependency order
We run production migration in record-dependency order: Company records (from Shark Byte Customers), Person records (from Shark Byte Contacts), custom object schema deployment, then Estimates, Proposals, Service Agreements, and Work Orders with lookup relationships resolved. Attachments migrate as ContentDocument records linked via ContentDocumentLink. Owner assignments transfer by resolving Shark Byte Owner to Twenty User. Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, validation, and configuration handoff
We freeze Shark Byte writes during cutover, run a final delta migration of any records modified during the migration window, then enable Twenty as the system of record. We deliver a written inventory of custom object configurations, Shark Byte field-to-Twenty field mappings, and any manual steps the admin must complete (e.g., repointing integrations, setting Twenty user permissions). We support a one-week hypercare window for reconciliation issues. We do not rebuild Shark Byte surveying workflows or estimating templates as Twenty automations; those are documented for the customer's admin to configure.
Platform deep dives
Shark Byte CRM
Source
Strengths
Weaknesses
Twenty CRM
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 Shark Byte CRM and Twenty CRM.
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
Shark Byte CRM: Not publicly documented.
Data volume sensitivity
Shark Byte CRM 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 Shark Byte CRM to Twenty CRM migration scoping. Not seeing yours? Book a call.
Walk through your Shark Byte CRM to Twenty CRM migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Shark Byte CRM
Other ways to arrive at Twenty CRM
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.