Migrate from Podio to Twenty CRM

Podio Contacts are user profiles containing name, email, title, and organization. We map them to Twenty's Person object, matching on email address as the dedupe key. Custom contact fields (Category fields, multi-value selects) map to multi-select or text fields on Person. If a Podio Contact has no email, we use name as the dedupe key and flag it for manual review. The Podio contact's workspace membership is not transferred as Twenty does not have an equivalent org-wide user role model outside of workspace invitations.

Podio apps used as organization or company tables map to Twenty Company. We identify these during schema discovery by checking for organization-name fields, address fields, and domain fields. The app's unique name becomes the Company name field. Apps with fewer than 5 text fields and no relational references to other apps are candidates for Company mapping; apps with relational references or complex multi-value fields become Custom Objects instead.

Podio apps with a currency field, stage/status category field, and close date field map to Twenty Opportunity. We identify deal-tracking apps during schema discovery by checking for monetary fields, date fields, and stage-category fields. The app's status values map to Twenty Opportunity stage options. Amount, close date, probability (if stored as a number field), and company reference all transfer. If the app has a multi-currency field, we store the raw amount and currency code separately for the customer's admin to configure the correct currency display in Twenty.

Podio standalone tasks map to Twenty Task. We preserve task title, due date, assignee (resolved via email match to Twenty workspace member), completion status, and linked item reference. Recurring task rules are not migratable as recurrence structures; we document each recurring task as a single Task entry with a note flagging the recurrence rule for manual rebuild in Twenty's workflow builder.

Comments attached to Podio items map to Twenty Note records linked via their target object (Person, Company, or Opportunity). We preserve comment text, author (resolved by email to Twenty workspace member), and timestamp. Rich-text formatting is simplified to plain text. If the destination Person or Company does not exist at import time, the comment is staged and linked after the parent record is created.

Podio files attached to items are downloaded to our staging storage via the Podio Files API (a separate endpoint from the Items API). We then re-upload each file to Twenty and attach it to the correct parent record using Twenty's attachment API. File names, upload timestamps, and file size are preserved. Podio's 100MB per-file limit is respected; files exceeding Twenty's attachment limit are flagged for the customer's admin to host externally and link via URL field.

Podio status messages are lightweight social-style posts shared within a space or workspace. We treat them as Note records attached to the relevant workspace-equivalent object in Twenty. They do not have a direct equivalent in Twenty's object model, so the migration approach is to preserve the message text, author, and timestamp as a Note on the associated record or workspace. If no associated record exists, the status message is attached to a general workspace Note record.

Podio conversations are private multi-user message threads. We export the full thread as a formatted transcript and attach it as a Note (with the transcript body as plain text) to the relevant workspace or associated Person record. Most destination platforms do not have a direct conversation equivalent, so the thread is preserved as an audit log rather than as an interactive messaging thread.

Podio tags applied to items, tasks, and other objects map to Twenty's Tag system. We capture all tag values during export and apply them to the corresponding Twenty record. If the destination Tag does not exist in Twenty, we create it during migration. Multi-value tags on a single Podio item map to multiple Tag assignments on the Twenty record.

Podio Category fields (single-value or multi-value option lists) map to Twenty select or multi-select fields. We preserve option labels and any color coding as text metadata on the field. If a Podio option value has no equivalent in Twenty, we flag it and either create a custom option or store the value as text. Category field dependencies (fields that are only visible when a specific category is selected) do not migrate; we document them for the customer's admin to reconfigure in Twenty.

Podio apps that do not fit the Person, Company, or Opportunity pattern map to Twenty Custom Objects. During schema discovery, we identify custom apps by checking for relational reference fields, multi-value fields, and unique field combinations not matching standard CRM patterns. We pre-create the Custom Object schema in Twenty (including all fields, field types, and lookup relationships) before any record import. Lookup relationships between custom apps map to Twenty Custom Object lookup fields if the target Custom Object exists; otherwise they are stored as text ID fields for post-migration resolution.

Podio reference fields create explicit links between items in different apps, similar to foreign keys. We capture all reference field values during export and remap them as Twenty lookup fields if both the source and target objects exist as standard or custom objects in Twenty. If the target object is not yet created or does not exist in Twenty, we store the original Podio item ID as a text field on the source record for manual link reconstruction after migration. We document every reference field mapping in the migration specification so the customer's admin knows which links require manual verification.