How long does a The Service Manager to Twenty CRM migration take?

Most The Service Manager to Twenty CRM migrations complete within 48–72 hours for data volumes under 25,000 records. Complex migrations with Incident history, multiple custom objects, and extensive pick-list value mapping extend to 10–15 days. The longest single phase is schema preparation — creating custom fields in Twenty's workspace before data lands typically takes 3–5 business days depending on how many custom properties need to be mapped. Planning and sample migration validation add another 3–5 days. Full migration timelines are quoted against your specific record counts and schema complexity.

Will my The Service Manager workflows and SLA automations migrate to Twenty?

No. FlitStack AI migrates data and schema only — workflows, SLA escalation rules, approval chains, and timer-based automations do not have a migration path to Twenty CRM. These are ITSM-specific constructs that Twenty's workflow builder handles differently (event-based triggers rather than timer-based SLA engines). We export your workflow definitions as a structured JSON file that your Twenty admin can use as a rebuild reference. SLA tier names and target hours migrate as custom fields on tasks so historical SLA data is preserved even though active SLA enforcement must be rebuilt.

What do The Service Manager incidents and problems become in Twenty CRM?

Incident records from The Service Manager migrate as Twenty Tasks linked to the relevant People and Company records. The incident ID is stored in a Source_System_ID__c field for traceability. Problem records also become Tasks with a Problem_Related__c flag set to true, and related Incident IDs are preserved in a custom linked-records field. Change Requests migrate as Tasks with Change_Request__c and Change_Type__c flags. This approach preserves the full incident and problem history and lets your team recreate relationships using Twenty's task-linking capabilities. Active SLA timers, escalation chains, and approval workflows do not migrate — they require manual rebuild in Twenty's workflow builder.

Can I migrate custom entities from The Service Manager to Twenty CRM custom objects?

Yes, within limits. Twenty Pro allows up to 10 custom objects per workspace; the Organization tier removes this cap. The Service Manager's custom ITSM entities — service catalog items, knowledge articles, vendor records, asset types — can map to Twenty custom objects field-by-field. If your The Service Manager instance has more than 8 custom entity types and you are on Pro, we recommend collapsing related types (for example, merging asset records into the Companies object with a type flag) or upgrading to Organization before migration. We surface this decision in the migration plan during the audit phase so there are no surprises at cutover.

How does The Service Manager agent assignment work in Twenty CRM?

The Service Manager assigns incidents to agents individually or through assignment groups (queues). In Twenty, Workspace Members are the equivalent of system users. FlitStack AI resolves The Service Manager agent assignments by matching the agent's email address to a Twenty Workspace Member. Assignment groups map to collections of matched Workspace Members, and the assigned agent becomes the task assignee in Twenty. Any agent whose email does not match an existing Twenty user is flagged before migration — your team provisions the account or designates a fallback assignee before the run commits. Unassigned tasks are routed to a designated catch-all Workspace Member.

Does the migration affect my The Service Manager account during the cutover?

No. FlitStack AI uses scoped read access on The Service Manager — your team continues working in the system during the migration. We pull data via the REST or SOAP API in read-only mode, so there is no impact on active incident resolution, change approvals, or SLA timers in The Service Manager. A delta-pickup window of 24–48 hours after the initial bulk load captures any new or modified records created during the cutover period. After delta-pickup completes and your team validates the Twenty data, you switch primary user logins to Twenty as the go-live step.

What are Twenty CRM's API rate limits, and how does that affect the migration speed?

Twenty Pro allows 100 API requests per minute; Organization tier allows 200 requests per minute. FlitStack AI writes data using bulk-compatible batches that stay within these limits. For migrations exceeding 50,000 records, the API rate limit is the primary clock on migration duration — a 100,000-record migration under Pro-tier limits takes longer than the same volume under Organization. We quote migration timelines against your Twenty workspace tier and can recommend upgrading temporarily during the migration window if speed is critical. Webhook-based Change Data Capture is available for post-migration sync but is not used during the initial bulk load phase.

The Service Manager to Twenty CRM Migration — Field-Level Mapping & Rollback

Overview

What this migration involves

The Service Manager stores incident records, problem tickets, change requests, service catalog items, and configuration items in an ITSM-oriented schema built around ITIL workflows. Twenty CRM uses a CRM object model centered on People, Companies, Opportunities, Tasks, and Notes, with a PostgreSQL-backed custom object layer that your workspace admin extends at runtime. The migration maps The Service Manager's contact and request records into Twenty's People object, maps companies and business accounts into Twenty's Companies object, and converts incident and task records into Twenty's Tasks object — linked back to the relevant People or Company record. The Service Manager's custom fields, status pick-lists, and priority values require value-by-value mapping because Twenty stores these as workspace-specific field metadata rather than platform-level enumerations. Workflows, change advisory board records, and SLA timers do not have a migration path — FlitStack AI exports definitions as JSON for manual rebuild in Twenty's workflow builder. The migration uses Twenty's REST and GraphQL API with 100 requests per minute on Pro and 200 requests per minute on Organization tiers, sequencing bulk writes to stay within rate limits while preserving relational integrity between objects.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Object mapping

How The Service Manager objects map to Twenty CRM

Each row shows how a The Service Manager 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.

The Service Manager

Contact / End User (Requester)

maps to

Twenty CRM

People

1:1

Fully supported

The Service Manager's requester records map directly to Twenty's People object. Email, name, phone, and company association migrate as-is. The requester's internal SM user ID is stored as Source_System_ID__c for traceability and delta-run deduplication. Additional fields such as job title, department, and address can also be mapped when present, preserving relationships for reporting.

The Service Manager

Company / Account

maps to

Twenty CRM

Companies

1:1

Fully supported

Organizations stored in The Service Manager's Company or Configuration Item (Business Service) records migrate to Twenty's Companies object. Company name, domain, industry, and employee count fields map directly. Parent-company hierarchies migrate via the Parent Company field in Twenty. Address details, annual revenue, and any workspace-specific custom fields are also transferred, preserving the full corporate profile for sales and reporting.

The Service Manager

Incident Record

maps to

Twenty CRM

Tasks

1:1

Fully supported

Incident records from The Service Manager convert to Twenty Tasks. The incident ID becomes Source_System_ID__c. Title maps to Task name. Description and resolution notes merge into the Task body. Status, priority, and category map via value-mapping to Twenty's built-in select fields. Assignment maps to the Task assignee by email match.

The Service Manager

Problem Record

maps to

Twenty CRM

Tasks

1:1

Fully supported

Problem records migrate to Twenty Tasks with a Problem_Related__c flag set to true. The Problem ID is preserved as Source_System_ID__c. Related Incident IDs are stored in a custom linked-records field. Problem root-cause text migrates into the Task description field. This lets teams recreate the incident-problem relationship in Twenty via task linking.

The Service Manager

Change Request

maps to

Twenty CRM

Tasks

1:1

Fully supported

Change Request records migrate as Twenty Tasks with Change_Request__c set to true. The CR number, change type, risk level, and approval status map to custom fields on the task. CAB (Change Advisory Board) notes and implementation plan text migrate into the Task description. Approval workflow state does not carry over — FlitStack exports the workflow definition for manual rebuild.

The Service Manager

Configuration Item (CI)

maps to

Twenty CRM

Companies

1:1

Fully supported

Hardware assets, software instances, and business services stored as Configuration Items in The Service Manager map to Twenty's Companies object when they represent business accounts, or to a custom CI object when they represent technical assets. The CI class type determines whether it lands in Companies or a custom object. CI-to-CI relationships migrate as Company-to-Company relations in Twenty.

The Service Manager

Service Catalog Item

maps to

Twenty CRM

Custom Object

1:1

Fully supported

Service catalog entries (requested items, offerings) map to a custom Service_Offering__c object in Twenty. Category, description, and availability status migrate as custom fields. Catalog-to-item hierarchies are recreated via self-referential relation fields in Twenty's data model. Each catalog item also carries price, lead time, and any workspace-specific attributes, preserving the full service offering details for sales and order management.

The Service Manager

Attachment / File

maps to

Twenty CRM

Files

1:1

Fully supported

Attachments on Incident, Problem, or Change records in The Service Manager are downloaded, re-uploaded to Twenty's workspace storage, and linked to the corresponding Task record. File name and original upload timestamp are preserved in the Twenty file metadata. Inline images in notes are extracted and hosted separately.

The Service Manager

Assignment Group / Queue

maps to

Twenty CRM

Workspace Member

1:1

Fully supported

The Service Manager assignment groups (support queues) map to groups of Twenty Workspace Members. Individual agent assignment in incidents maps directly to the matching Twenty user by email. Group-level assignment is surfaced as a custom Team__c field on the task for manual reassignment routing.

The Service Manager

SLA Definition

maps to

Twenty CRM

Custom Field on Task

1:1

Fully supported

SLA timers, breach thresholds, and escalation rules in The Service Manager have no native equivalent in Twenty's CRM model. We preserve SLA tier names and target hours as custom fields on Tasks (SLA_Tier__c, Target_Hours__c) for reference. Teams needing active SLA enforcement must implement this in Twenty's workflow builder post-migration.

The Service Manager

Workflow / Automation

maps to

Twenty CRM

None

1:1

Fully supported

The Service Manager workflows, escalations, and approval chains are ITIL automation constructs with no direct mapping to Twenty's CRM workflow builder. FlitStack AI exports workflow definitions as JSON for use as a rebuild specification. Teams must design replacement automations in Twenty's workflow editor targeting the migrated Task and custom object records.

The Service Manager

Survey / Satisfaction Rating

maps to

Twenty CRM

Custom Field on People or Task

1:1

Fully supported

Post-incident customer satisfaction scores and survey responses stored in The Service Manager migrate as custom fields on the associated Task record (CSAT_Score__c, Survey_Response__c). The survey configuration itself does not migrate — the response data becomes historical reference fields in Twenty.

The Service Manager	Twenty CRM	Compatibility
Contact / End User (Requester)	People1:1	Fully supported
Company / Account	Companies1:1	Fully supported
Incident Record	Tasks1:1	Fully supported
Problem Record	Tasks1:1	Fully supported
Change Request	Tasks1:1	Fully supported
Configuration Item (CI)	Companies1:1	Fully supported
Service Catalog Item	Custom Object1:1	Fully supported
Attachment / File	Files1:1	Fully supported
Assignment Group / Queue	Workspace Member1:1	Fully supported
SLA Definition	Custom Field on Task1:1	Fully supported
Workflow / Automation	None1:1	Fully supported
Survey / Satisfaction Rating	Custom Field on People or Task1:1	Fully supported

Gotchas + challenges

What specifically takes care here

Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.

The Service Manager gotchas

High

Dense service history causes export pagination failures

Medium

Custom fields on Work Orders differ by FSM version

Medium

Serialized asset cross-references break after migration

Low

Parts inventory snapshot staleness at cutover

Twenty CRM gotchas

High

Import order is enforced and critical

High

Export limited to 20,000 records and visible columns only

Medium

Soft-deleted records count toward uniqueness and trigger restores

Medium

API rate limits cap at 200 req/min on Organization tier

Low

No native email sequences — follow-up cadences require external tools

The Service Manager gotchas		Twenty CRM gotchas
Severity	Issue	Severity	Issue
High	Dense service history causes export pagination failures	High	Import order is enforced and critical
Medium	Custom fields on Work Orders differ by FSM version	High	Export limited to 20,000 records and visible columns only
Medium	Serialized asset cross-references break after migration	Medium	Soft-deleted records count toward uniqueness and trigger restores
Low	Parts inventory snapshot staleness at cutover	Medium	API rate limits cap at 200 req/min on Organization tier
		Low	No native email sequences — follow-up cadences require external tools

Pair-specific challenges

Twenty's workspace-level schema generation means custom field creation happens before data lands

The Service Manager stores custom fields as part of its form and CMDB definitions — these are defined in the SM7 database schema. Twenty CRM generates its workspace schema dynamically at runtime via the fieldMetadata table. Custom fields do not exist in Twenty until your workspace admin creates them in Settings before the migration run. If you have 15+ custom fields on Incident records (priority reasons, departments, business unit tags), those must be pre-created in Twenty before FlitStack AI can write data into them. We deliver a field-creation checklist as part of the migration plan so Twenty's schema is ready before data lands.
SLA breach timers and escalation rules have no native migration path in Twenty CRM

The Service Manager's core value for IT teams is its SLA engine — timers that automatically escalate priority, reassign owners, and trigger notifications when a ticket approaches breach. Twenty CRM's workflow builder handles object-event triggers but does not have a native SLA timer mechanism. We preserve SLA tier names, target hours, and breach history as custom fields on migrated tasks. Active SLA timers stop at migration cutover. If your team relies on automated SLA escalation, that logic must be rebuilt in Twenty's workflow builder using the exported workflow definition JSON as a specification. This is the most common post-migration gap for ITSM-to-CRM migrations.
Pro tier custom object limit of 10 may require collapsing ITSM entity types

Twenty Pro caps custom objects at 10 per workspace. Organizations with multiple ITSM entity types (Incidents, Problems, Changes, Service Catalog Items, Knowledge Articles, Assets, Vendors) may exceed this limit on the Pro plan. Each of these entity types might map to a separate custom object in Twenty. The Organization tier removes this cap. We surface this constraint in the migration plan: if you are on Pro and have more than 8 custom object types in The Service Manager, we recommend either upgrading to Organization or collapsing related ITSM entities (for example, merging Assets into the Companies object with a type flag). This decision affects pricing and schema complexity and must be resolved before migration.
Import order constraint: Companies must land before People, People before Tasks

Twenty's CSV import documentation explicitly requires a loading order: Companies first, then People (linked to Companies via companyId), then Opportunities and Tasks, then custom objects last. This reflects Twenty's PostgreSQL foreign-key model where the 'one' side of a one-to-many relationship must exist before the 'many' side can reference it. FlitStack AI respects this constraint by sequencing the migration run: accounts load first, then contacts with AccountId resolution, then tasks with assignee and company links. If your The Service Manager instance has orphaned contacts (requesters without an assigned company), those records require a fallback rule — we default them to an 'Unassigned' Company record or create a placeholder People record without a companyId link.
Attachment files re-hosted during migration may change URLs in Twenty

The Service Manager stores file attachments in its own attachment catalogue with internal references that are not portable URLs. When FlitStack AI migrates attachments to Twenty, each file is re-uploaded to Twenty's workspace storage bucket, which generates new URLs. Any links to The Service Manager attachments embedded in documentation, knowledge base articles, or external systems will break after migration. We provide a mapping table of original attachment IDs to new Twenty attachment URLs so your team can update any hard-coded references post-migration. Inline images in rich-text fields are extracted, rehosted, and the img src attributes updated to point to the new Twenty-hosted URL.

Migration approach

Six steps for a successful The Service Manager to Twenty CRM data migration

Audit The Service Manager data inventory and export

FlitStack AI connects to The Service Manager's REST or SOAP API and runs a discovery scan to enumerate all record types: Contacts, Companies, Incidents, Problems, Change Requests, Configuration Items, and any custom entities. We produce a data inventory report showing record counts per type, custom field counts, and attachment volumes. Any records without email addresses (which prevent owner resolution in Twenty) are flagged for remediation before the migration run begins. This audit phase typically takes 2–4 days depending on data volume and API pagination behavior.
Create Twenty workspace schema before data lands

Based on the audit, FlitStack AI delivers a schema setup plan: the list of custom fields to create in Twenty's Settings, the mapping of pick-list values, and the decision framework for collapsing ITSM entity types onto Twenty's standard or custom objects. Your workspace admin (or our team) creates these fields before the migration run. We also map Workspace Members in Twenty to The Service Manager agent accounts via email matching — users without a Twenty account are flagged for provisioning before cutover.
Run sample migration with field-level diff

A representative slice of 200–500 records spanning People, Companies, Incidents, and Problems migrates into Twenty first. FlitStack AI generates a field-level diff comparing source values against destination values for every mapped field. You verify that status value-mapping looks correct, that assignee resolution by email worked, that custom fields populated, and that attachment links are intact. This validation step catches mapping errors before the full run commits. Any field that mismatches gets corrected in the mapping plan and the sample re-runs.
Execute full migration with delta-pickup window

The full record set migrates into Twenty respecting the Companies → People → Tasks loading order. A delta-pickup window (typically 24–48 hours after the initial load) captures any records created or modified in The Service Manager during the cutover window. FlitStack AI uses The Service Manager's API to pull only records with a last-modified timestamp after the migration start time and upserts them into Twenty. After delta-pickup completes, your team does a final reconciliation check before switching user logins to Twenty as the primary CRM.
Deliver migration artifacts and rebuild reference package

FlitStack AI delivers the full migration audit report, the field-level mapping specification, the attachment URL mapping table, and a JSON export of The Service Manager workflow definitions. The workflow JSON is designed for use as a rebuild specification in Twenty's workflow builder. An audit log captures every insert, update, and skip operation during the migration run. One-click rollback is available for 72 hours post-migration if reconciliation uncovers unexpected gaps — this reverts Twenty to its pre-migration state so the run can be corrected and restarted without data loss.

Platform deep dives

Context on both ends of the pair

The Service Manager

Source

Strengths

Work Order lifecycle management from creation through invoicing and closure.
Mobile application for field technicians with offline capability on many platforms.
Asset-centric data model linking equipment history to service records.
SLA and entitlement engine tied to service contract coverage rules.
Territory and routing management for multi-dispatcher field operations.

Weaknesses

Export tooling is often ad-hoc—custom SQL queries or manual CSV exports are common, with no guaranteed schema consistency across versions.
Large service history volumes create API pagination challenges; extracting five or more years of records requires batching and reconnection logic.
Custom fields proliferate in mature FSM deployments, increasing mapping complexity during migration scoping.
Billing integrations vary significantly by FSM platform; invoice-line detail preservation is not always guaranteed.
Licensing models are typically per-technician, meaning migration scoping must account for active versus inactive technician counts to avoid over-provisioning the destination.

Twenty CRM

Destination

Strengths

AGPL-3.0 open-source license with full source code on GitHub — no vendor lock-in, no sunset risk.
Unlimited users and unlimited custom objects on self-hosted, with no feature gating based on headcount.
REST and GraphQL APIs available on all paid tiers, not locked behind an enterprise add-on fee.
MCP server and webhooks shipped as standard features, not premium upgrades.
Modern PostgreSQL-backed data model that developer teams can query, extend, and self-host.

Weaknesses

Recent v1.0 release means limited production hardening compared to CRMs with multi-year operational track records.
No native email sequencing or sales engagement tools — follow-up cadences require a separate platform.
No native two-way email sync or inbox integration, requiring third-party connectors for full activity logging.
Self-hosting 'free' pricing hides real infrastructure and DevOps costs that stack up over time.
Workflow automation is functional but lacks the complexity needed for sophisticated multi-step sales motions.

	The Service Manager Source	Twenty CRM Destination
Strengths	Work Order lifecycle management from creation through invoicing and closure. Mobile application for field technicians with offline capability on many platforms. Asset-centric data model linking equipment history to service records. SLA and entitlement engine tied to service contract coverage rules. Territory and routing management for multi-dispatcher field operations.	AGPL-3.0 open-source license with full source code on GitHub — no vendor lock-in, no sunset risk. Unlimited users and unlimited custom objects on self-hosted, with no feature gating based on headcount. REST and GraphQL APIs available on all paid tiers, not locked behind an enterprise add-on fee. MCP server and webhooks shipped as standard features, not premium upgrades. Modern PostgreSQL-backed data model that developer teams can query, extend, and self-host.
Weaknesses	Export tooling is often ad-hoc—custom SQL queries or manual CSV exports are common, with no guaranteed schema consistency across versions. Large service history volumes create API pagination challenges; extracting five or more years of records requires batching and reconnection logic. Custom fields proliferate in mature FSM deployments, increasing mapping complexity during migration scoping. Billing integrations vary significantly by FSM platform; invoice-line detail preservation is not always guaranteed. Licensing models are typically per-technician, meaning migration scoping must account for active versus inactive technician counts to avoid over-provisioning the destination.	Recent v1.0 release means limited production hardening compared to CRMs with multi-year operational track records. No native email sequencing or sales engagement tools — follow-up cadences require a separate platform. No native two-way email sync or inbox integration, requiring third-party connectors for full activity logging. Self-hosting 'free' pricing hides real infrastructure and DevOps costs that stack up over time. Workflow automation is functional but lacks the complexity needed for sophisticated multi-step sales motions.

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

Migrate from The Service Manager to Twenty CRM

What this migration involves

Field-level fidelity

Schema-aware mapping

Relationships preserved

Full activity history

Attachments & notes

Two sides of the same decision