Migrate from RAMM to Twenty CRM

RAMM contact records map directly to Twenty People objects with one-to-one field alignment. Standard fields such as name, email address, phone number, and job title transfer without transformation. The companyId foreign key in RAMM must reference a Company record that already exists in Twenty, so the import sequence enforces Companies to load first. This prevents foreign-key validation failures during the People import and ensures each contact record links to its correct parent company upon insertion.

RAMM client and site records map to Twenty Companies. Company name, domain, industry, employee count, and address fields migrate directly. Multi-site RAMM setups may have multiple company records per client — all import as separate Twenty Company records with unique domain identifiers.

RAMM does not have a native deal object, but many RMM instances track upsell opportunities or MRR expansion as custom Opportunity-type records. These map to Twenty Opportunities with amount, stage, close date, and linked Company. Pipeline and stage values require pre-migration pick-list configuration in Twenty before import.

RAMM technician activity logs, call records, and email threads map to Twenty Tasks. Original timestamps, task type (call, email, meeting), and assigned WorkspaceMember are preserved. Parent record links to People or Companies are retained via the Twenty task relationship fields.

RAMM notes attached to contacts, companies, or tickets migrate as Twenty Notes. Rich-text formatting such as bold text, hyperlinks, and bulleted lists is preserved where the RMM export format supports those elements. During the import phase, notes attach to the correct People, Company, or custom object record via the relation-mapping step, ensuring each note lands adjacent to its parent record rather than as an orphaned entry.

RAMM ticket records have no native equivalent in Twenty CRM. We create a Ticket__c custom object in Twenty with fields for ticket number, status, priority, assignee (WorkspaceMember), companyId, created date, and resolved date. Status pick-list values map value-by-value from RMM ticket states to Twenty custom pick-list values configured before import.

RAMM device and asset records (server names, workstation IDs, IP addresses, last-seen timestamps) have no Twenty equivalent. We create a Device__c custom object linked to the parent Company record via companyId. Fields include device name, type, status, IP address, operating system, lastSeen timestamp, and linked contact (technician) as WorkspaceMember.

RAMM monitoring alerts and threshold events are preserved as Alert__c records in Twenty, linked to the related Device__c record. Fields include alert type, metric name, threshold value, triggered value, severity level, acknowledged status, and acknowledged-by WorkspaceMember. This allows historical alert context to survive the migration even though active alerting must be rebuilt in Twenty's workflow builder.

RMM SLA configurations (response time tiers, contract value, service scope) have no direct equivalent in Twenty. We preserve SLA tier as a custom pick-list field (SLA_Tier__c) on the Companies object, with value-by-value mapping from RMM tier names. Contract value and renewal dates migrate as custom number and date fields on the same Companies record.

RAMM owner and technician assignments store a user ID. Twenty has no OwnerId field — records are assigned to Workspace Members. We resolve RMM owner IDs to Twenty Workspace Members by email address match. Unmatched owners are flagged before migration so you can invite them to Twenty first or assign records to a fallback Workspace Member.

RAMM file attachments (screenshots, exported reports, contract PDFs) linked to tickets or contacts are downloaded and re-uploaded to Twenty, attached to the corresponding People, Company, or Ticket__c record. File size limits from the RMM export are preserved. Inline images in notes are extracted and re-hosted as Twenty file attachments.

RMM platforms with vendor-specific custom objects (e.g., product modules, add-on tracking) map 1:1 to Twenty custom objects. Custom object relationships in RMM that use N:N linking require a junction custom object in Twenty. The migration plan surfaces these before data lands so the schema is ready in the correct import order.