Migrate from Vryno CRM to Twenty CRM

Vryno Leads map to Twenty Person records. Lead scoring, source, and status fields migrate as custom fields on the Person object since Twenty's standard Person schema includes name, email, phone, and jobTitle but not a native lead scoring field. We preserve the original lead status value and the auto-assignment geography or product line in a custom field for segmentation after migration.

Vryno Contacts migrate to Twenty Persons. Standard fields (name, email, phone, address) map cleanly to Twenty Person fields. Vryno's contact-level custom fields migrate as custom fields on the Person object. We deduplicate on email address during import and flag any Vryno Contact that shares an email with an existing Vryno Lead already migrated as a Person to prevent duplicate records.

Vryno Accounts map to Twenty Companies. Company name, industry, address, website, and account-level custom fields migrate 1:1 to their Twenty Company equivalents. The Company object is created before any Person import so that the Person-to-Company relationship is resolved at insert time rather than patched afterward.

Vryno Deals map to Twenty Opportunities. Deal name, value, expected close date, stage name, probability percentage, and owner all migrate. Vryno's pipeline stages become Opportunity stage columns in Twenty. We reconstruct the probability mapping as stage probability values on each Opportunity stage definition.

Vryno's multiple pipelines (up to five on Essentials, up to fifty on Premium) map to Twenty's opportunity stage column definitions within a single pipeline per workspace. If the customer uses Vryno pipelines to separate business units, we create separate custom fields on Opportunity (e.g., business_unit as a picklist) to preserve the segmentation rather than relying on multiple pipeline objects which Twenty handles differently.

Vryno Activities (calls, emails, meetings, tasks) map to Twenty TimelineEntry records linked to the relevant Person or Company. Activity type, date, duration, notes, and outcome migrate as fields on TimelineEntry. We resolve the parent Person or Company reference at migration time using email and company name matching against the already-migrated records.

Vryno Products (name, SKU, unit price, tax codes) migrate to a Twenty custom object named Product if the customer uses product-linked Deals. We create the Product custom object via Twenty's metadata API before migration, then populate it using the GraphQL API or CSV import depending on record count. Tax code mapping requires review because Vryno's Products and Taxation module is gated to Essentials and above and the tax schema is country-specific.

Vryno Custom Modules are user-defined objects with instance-unique schemas—no two Vryno instances share the same field structure. We perform schema discovery on the source instance first by extracting the custom module definitions including field names, types, and relationships. We then create matching custom objects in Twenty via the metadata API and migrate the records field by field. If Twenty does not support an equivalent field type for a Vryno custom field, we fall back to a text field and flag the discrepancy in the migration report.

Vryno Custom Dashboards migrate as Twenty Custom Views with widget definitions and metric names preserved. Live data queries and aggregations do not transfer because they re-evaluate against the destination data. We document every dashboard widget so the customer's admin can recreate the filters and aggregations in Twenty's view builder. Note that dashboard widget recreation is outside standard migration scope and is delivered as part of the written rebuild inventory.

Vryno Owners (assigned to Leads, Contacts, Deals, and Activities) map to Twenty WorkspaceMember records by email address. We resolve owners during the migration preparation phase and flag any Vryno Owner without a matching Twenty user in a reconciliation queue. The customer's admin provisions any missing WorkspaceMembers before record import begins because OwnerId is a required reference on Opportunity and TimelineEntry records.

Vryno workflow automation rules including conditional follow-up emails, lead routing logic, and stage-change triggers are server-side configuration and do not export as data. We document every active workflow rule during the discovery call with its trigger, conditions, and actions, and deliver the inventory as a written guide for the customer's admin to rebuild in Twenty. Twenty's workflow capabilities are in active development; teams should verify current automation feature parity before committing to a rebuild timeline.