Plain to Tidio is a data-model translation project: flatten companies and tenants, map GraphQL to REST, respect strict rate limits, and validate aggressively.
Migrating from Plain to Tidio requires a full custom-built data pipeline, as no native migration path exists between the two platforms. Plain is an API-first, GraphQL-native support platform built around a hierarchical data model — Companies, Tenants, Customers, Threads, and Timeline Entries — while Tidio uses a flat, REST-based model centered on Contacts, Conversations, and Tickets with no native equivalent for Company or Tenant objects. Every record must be extracted from Plain's GraphQL API, structurally transformed to reconcile these fundamental model differences, and loaded into Tidio via its REST OpenAPI or file-based importers. The primary technical risk is in the transformation layer, where Plain's multi-dimensional relational context must be deliberately flattened or externalized to fit Tidio's simpler schema without silently losing reporting and segmentation fidelity.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Do not assume a one-to-one model
Plain supports one company per customer, multiple tenants per customer, hierarchical labels (up to three levels), multi-assignee threads, and threads that can contain multiple email threads and participants. Tidio's model is much flatter. If you skip the design step, you will lose reporting context even if every row technically imports.
Tidio's CSV import only handles contact data
There is no CSV import path for tickets, conversations, or message history. For ticket history, you need the JSONL import (Plus plan required) or the API.
Company and Tenant data loss risk
Plain organizes customers under Companies (one per customer) and Tenants (multiple per customer). Tidio has no equivalent entities. You must flatten company and tenant data into contact properties or accept that this hierarchy is lost. If B2B reporting depends on company grouping, keep an external CRM as the source of truth.
Custom timeline entries
Plain allows highly flexible custom timeline entries via its API, often containing structured JSON payloads. Tidio tickets are strictly conversational. You must parse any JSON-based custom timeline entries in Plain and convert them into human-readable text blocks appended as internal notes in Tidio.
Rate limits are strict
At 120 req/min on Premium, you get 2 requests per second. A migration of 10K contacts + 10K conversations + 50K messages requires ~70K API calls minimum — roughly 10 hours of sustained API time assuming zero retries. In practice, expect 12–15 hours accounting for retries, dedup lookups, and error handling. Build retry logic with exponential backoff for 429 responses. Track the X-RateLimit-Remaining header proactively and throttle before hitting the limit.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Establish why you are moving, what "done" means, and who signs off.
Objective A written scope with agreed success criteria, a named owner per workstream, and a budget approved by finance.
Keep these open
-
Pull the real numbers out of Plain
Export counts for tickets (open and closed separately), contacts, organisations, attachments, macros, triggers, automations, views and SLA policies. Note the oldest ticket date — history depth drives the whole timeline. Estimating from memory is the single most common cause of a blown migration window.
Data Profiler Get real record counts instead of estimating from memory -
Decide what history actually moves
Agree a cut-off with the support lead: all history, last 24 months, or open tickets plus a read-only archive. Every extra year of closed tickets adds API time and cost without adding much agent value. Get this in writing — it is the decision people relitigate mid-cutover.
A "move everything" default is what turns a two-week migration into a two-month one.
COI & ROI Calculator Build the 36-month business case you will need for sign-off -
Confirm Tidio can hold your support model
Walk your current workflow through Tidio: multi-brand, business hours, SLA targets, CSAT, side conversations, public vs internal notes, and any channel you depend on (voice, chat, WhatsApp, social). List anything with no native equivalent — those are project risks, not configuration details.
-
Build the business case
Model licence delta, migration effort, agent retraining, and the cost of staying put (Cost of Inaction). Executives approve a number, not a plan, and you will be asked for it again at the go/no-go.
Helpdesk Migration Planner Turn ticket volume into a dated Plain → Tidio timeline -
Name owners and set the go/no-go date
One named owner each for data, configuration, integrations, and agent enablement, plus a decision-maker who can call a rollback. Put the go/no-go meeting in calendars now, 48 hours before the freeze.
-
Create all Operators manually
Tidio's API does not support Operator creation. Each agent must log into Tidio at least once to generate their operator ID.
-
Define all Contact Properties
that correspond to Plain's custom customer attributes, company data, and tenant fields. Critical: Tidio contact property types cannot be changed after creation, and existing properties cannot be deleted — only hidden. Define your schema on a test project first and validate before creating in production. (help.tidio.com)
-
Confirm your Tidio plan includes API access
OpenAPI requires Plus ($749/mo) or Premium ($2,999/mo).
Plain → Tidio specifics
- Business model shift
- Moving from technical B2B SaaS (where Plain's API-first model fits) to high-volume B2C or e-commerce where live chat, AI chatbot deflection, and marketing automation (Tidio's Lyro AI, chatbot flows, email campaigns) are more valuable than deep API extensibility.
- E-commerce stack alignment
- Tidio has native Shopify, WooCommerce, and WordPress integrations. Plain is built for developer-tool companies and B2B SaaS with no e-commerce connectors.
- Team composition change
- Support teams without dedicated engineering resources find Plain's API-first model requires ongoing development investment that Tidio's visual configuration eliminates.
- Small team, contacts only
- CSV import and start fresh with tickets.
- Small team, full history
- Managed migration service or JSONL import.
Don't move on until
- Record counts confirmed for tickets, contacts, organisations and macros
- Success criteria signed off by the support lead
- Freeze window provisionally booked with the business
02 Data Audit Find out what is actually in the data before you try to move it.
Objective A profiled, cleaned export with every quality defect either fixed at source or explicitly accepted.
Keep these open
-
Take a full Plain export and profile it
Export to CSV or JSON and profile every file: row counts, null rates per column, distinct values, and type consistency. Compare row counts against the API totals from Discovery — a gap here means your export is silently truncated, usually by pagination.
Data Profiler Profile the Plain export for nulls, outliers and type drift -
Validate file structure before anyone writes a transform
Check delimiters, quoting, encoding (expect UTF-8, watch for BOMs and Latin-1), duplicate headers, and embedded newlines in ticket bodies. Ticket descriptions with raw newlines and commas break naive CSV parsers and silently shift columns.
A single unescaped quote in one ticket body can shift every subsequent column without any error.
CSV Validator Catch broken headers and ragged rows in the raw export -
Inventory PII and set retention
Scan for emails, phone numbers, payment card fragments, national IDs and anything else regulated in ticket bodies and custom fields — support tickets are where customers paste things they should not. Decide what gets migrated, masked, or dropped, and record the legal basis.
Ticket bodies and attachments routinely contain card and ID data that never appears in a structured field.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Quantify duplicates, orphans and dead references
Count duplicate contacts (same email, different casing), tickets whose requester no longer exists, organisations with no members, and attachments whose parent ticket is gone. Fix these in Plain where you can — migrating them just moves the mess.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Clean and normalise the export
Trim whitespace, drop empty rows and columns, normalise casing on emails and tags, and standardise every timestamp to UTC ISO 8601. Timezone drift is invisible at load time and shows up weeks later as SLA reports nobody can reconcile.
-
Produce a masked copy for sandbox work
Generate a realistic but fake version of the export for testing and for any vendor who needs sample data. Loading real customer PII into a sandbox is a breach in most jurisdictions, and sandboxes are rarely covered by your DPA.
PII Masker Generate a safe copy for sandbox and vendor testing
Don't move on until
- Export parses cleanly with no ragged rows or encoding errors
- PII inventory complete and retention decisions recorded
- Duplicate and orphan records quantified and triaged
03 Field Mapping Turn two schemas into one signed-off mapping spec.
Objective A reviewed field-level mapping covering every object, with an explicit decision for every field that has no target.
Keep these open
-
Generate the first-pass Plain → Tidio field map
Start from an automated match on both schemas, then review every row by hand. Automated matching gets the obvious 70% right and is confidently wrong on the rest — especially anything named "type", "status" or "custom_field_1".
Schema Mapper Opens pre-loaded with the Plain → Tidio field pair -
Map status, priority and channel values, not just field names
Enumerate every value in each picklist on both sides and map them explicitly. Value-level mismatches are the defect class that survives all the way to production because the field itself mapped fine — a ticket that should be "Pending" arriving as "Open" reopens SLA clocks.
Statuses with no target equivalent (on-hold, pending-customer) need a policy decision, not a best guess.
-
Decide how custom fields land
Create the target custom fields first, matching type exactly (a dropdown mapped to free text can never be mapped back). Where Tidio has no equivalent, decide between a new custom field, a tag, or a note appended to the ticket body — and record which.
-
Resolve identity and threading
Decide how source IDs are preserved — most platforms will not let you set the primary key, so keep the original ID in a custom field. Without it, reconciliation becomes fuzzy matching and every future support question about an old ticket is unanswerable.
Losing the original ticket ID makes reconciliation and rollback effectively impossible.
-
Plan attachments, inline images and threading order
Confirm size limits, allowed MIME types, and whether inline images survive as attachments or need rehosting. Decide the comment ordering and author attribution rules: comments loaded out of order, or all attributed to the API user, destroy the conversation history agents rely on.
-
Freeze and sign off the mapping spec
Version the spec, walk the support lead through it row by row, and get explicit sign-off. Any change after this point goes through change control — mid-flight mapping edits are how partial loads happen.
-
Define Ticket Custom Fields
where needed (limited to text and dropdown types).
Plain → Tidio specifics
- Status mapping
- TODO → open, DONE → solved, SNOOZED → pending. Preserve Plain's statusDetail (e.g., WAITING_FOR_CUSTOMER, IN_PROGRESS) in a custom field if you need analytics granularity.
- Company/Tenant flattening
- Extract company name and tenant memberships into contact-level properties.
- Label → Tag conversion
- Flatten nested label hierarchies into discrete tag names. For a three-level hierarchy like billing > refunds > disputes, decide between: (a) three separate tags, (b) a concatenated tag billing__refunds__disputes, or (c) both approaches with the full path stored in an internal note for searchability.
- Markdown to HTML
- Plain stores messages in Markdown or raw text. Tidio expects HTML for rich text rendering. Use a library like marked (Node.js) or markdown2 (Python) to convert. Sanitize output to prevent XSS if your Tidio instance is customer-facing.
- CustomEntry parsing
- For CustomEntry timeline items, extract the title and components fields. Convert the structured JSON components into a readable text block: [Custom Event: {title}]\n{formatted components}. Append as an internal note.
Don't move on until
- Every source field is mapped, deliberately dropped, or parked in a custom field
- Status, priority and channel value maps agreed with the support lead
- Mapping spec version-controlled and signed off
04 Test Migration Prove the pipeline on a small, representative slice.
Objective A pilot load into a Tidio sandbox that reconciles cleanly and has been reviewed by real agents.
Keep these open
-
Stand up a Tidio sandbox that matches production config
Create the custom fields, groups, brands, business hours and SLA policies first. A pilot into a default sandbox tests nothing, because the failures you care about are all configuration mismatches.
-
Pick a deliberately nasty pilot sample
Take 500-1000 records chosen for difficulty, not convenience: the longest ticket threads, tickets with the most attachments, non-Latin character sets, merged and split tickets, deleted requesters, and every status value. A clean random sample proves only that easy records are easy.
-
Run the load with masked data and instrument everything
Log every API request and response with its source record ID. When 40 records fail out of 10,000 you need to know exactly which ones and why, without re-running the whole batch.
PII Masker Never load real customer PII into a sandbox -
Measure real throughput against the rate limit
Record achieved records-per-hour under Tidio's actual rate limits, including retries and backoff. Extrapolate to the full volume: if the maths says the full load exceeds your freeze window, you fix that now, not on cutover night.
Published rate limits are ceilings, not throughput. Assume real-world rates are meaningfully lower once retries and backoff are counted.
-
Reconcile the pilot and triage every failure
Diff source against target on record counts and field-level values. Every discrepancy gets a root cause and a fix — "probably fine" at pilot scale becomes thousands of broken records at full scale.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Put real agents in front of the pilot data
Have two or three agents work sample tickets end to end in the sandbox. They find the things reconciliation cannot see: unreadable threading, missing context, macros that no longer make sense. Fix the mapping, then re-run.
-
Set up a test project
to validate scripts before running against production.
Plain → Tidio specifics
- Attachment staging
- Download files from Plain's signed URLs during extraction. Re-upload to a stable public URL (S3 bucket with public read, GCS signed URL with long expiry). For JSONL import, Tidio downloads from these URLs during processing. For API import, Tidio's documented ticket reply endpoint does not expose attachment fields — use the JSONL path for attachment-heavy history.
Don't move on until
- Pilot batch reconciles to 100% on record counts
- Agents have reviewed sample tickets and confirmed they are workable
- Measured throughput extrapolates to a viable full-load window
05 Cutover Execute the switch inside a controlled, reversible window.
Objective All in-scope data live in Tidio, agents working in the new system, and a rollback path that stayed available throughout.
Keep these open
-
Pre-load history before the freeze
Load closed tickets and contacts days or weeks ahead while Plain stays live. Only open tickets and the final delta need to move inside the freeze — this is the single biggest lever on window length.
Helpdesk Migration Planner Size the freeze window from Tidio's real API limits -
Publish the runbook with times, owners and abort criteria
A timed sequence: freeze start, final export, delta load, channel switch, smoke test, go/no-go, agent switch. Name who does each step and the explicit condition that triggers a rollback. Decide the abort criteria before the night, when nobody wants to be the one to call it.
-
Freeze Plain and take the final delta
Stop new ticket creation, let agents finish in-flight replies, then export everything changed since the pre-load. Announce the freeze to the whole business, not just support — someone always tries to raise a ticket during it.
Tickets created during an unenforced freeze land in the old system and are the most common source of permanently lost data.
-
Load the delta and open tickets
Run the delta load, then reconcile counts before touching any channel. Do not repoint email until the delta has verified — an inbound ticket arriving mid-load is far harder to untangle than a few extra minutes of freeze.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint channels and verify with live traffic
Switch email forwarding and MX or connector settings, update chat widgets and web forms, and re-authorise integrations. Then send real test tickets through every channel and confirm each lands, routes and triggers the right automation.
Email forwarding changes can take up to a full DNS TTL to propagate — check the TTL days in advance and lower it if needed.
Cron Expression Builder Schedule the delta syncs that run through the freeze -
Run the go/no-go and switch the agents
Walk the exit criteria with the decision-maker, call it explicitly, then move agents over with a named person on hand for the first few hours. Keep Plain read-only rather than cancelled — cancelling the old contract on day one removes your only fallback.
Don't move on until
- Full historical load complete and counts matched
- Inbound channels repointed and verified with live test tickets
- Rollback decision point passed explicitly, not by default
06 Validation Prove the migration is complete, then close it out.
Objective Documented evidence that data, workflow and reporting all survived, and a signed acceptance.
Keep these open
-
Run the full reconciliation
Compare source and target on every object: total counts, counts by status, counts by group, attachment counts, and field-level spot checks on a random sample. Produce one report you can hand to an auditor.
Migration Validation Tool Reconcile Plain and Tidio record-for-record -
Verify field completeness, not just record counts
Re-profile the loaded data and compare null rates per field against the source profile. Matching record counts with a field that silently arrived empty is the failure mode counts alone will never catch.
Data Profiler Prove field completeness held up through the load -
Rebuild reporting and compare against baselines
Recreate your core dashboards — volume, first response time, resolution time, CSAT — and compare to pre-migration figures for the same period. Explain every variance; a changed SLA calculation is a real finding, not a rounding error.
SLA and first-response metrics are usually recalculated from the loaded timestamps, so they will differ if any timestamp mapping was approximate.
-
Test the workflow layer end to end
Fire every trigger, automation, SLA escalation, macro and notification with a live ticket. Workflow does not migrate — it gets rebuilt — so it is untested until someone has actually watched it run.
-
Confirm compliance and produce the audit trail
Re-scan the loaded data for regulated fields, confirm retention and deletion policies are configured in Tidio, and file the evidence with your PII decisions from the audit phase.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Sign off, then decommission on a schedule
Get written acceptance against the Discovery success criteria. Keep Plain read-only for an agreed period (30-90 days is typical), take a final archive export, and only then cancel. Diarise the decommission date so it does not quietly renew.
Plain → Tidio specifics
- Ongoing sync post-migration
- Middleware (Make/Zapier) for new records.
Don't move on until
- Full reconciliation report attached to the project record
- Reporting baselines match pre-migration figures within agreed tolerance
- Formal acceptance signed and archive retention scheduled
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
Object Equivalent
| Plain field | Tidio field | Notes |
|---|---|---|
| Customer | Contact | Direct mapping. Email is the primary key in both. |
| Company | _(No direct equivalent)_ | Store as Contact Property (company_name). Tidio has no Company/Organization object. |
| Tenant | _(No direct equivalent)_ | Store tenant memberships as Contact Property (tenant_ids). Customers can belong to multiple tenants. |
| Thread | Ticket | Map 1:1. Store Plain Thread ID in a Tidio custom field for audit trail and cross-reference. |
| Thread Timeline (messages) | Ticket Messages | Flatten timeline entries to messages. Exclude system events (see entry type list above). Map emails to public messages, notes to internal messages. |
| Labels | Tags | Map label names to Tidio tags. Flatten hierarchy: a Plain label billing > refunds > disputes becomes three Tidio tags or one concatenated tag billing__refunds__disputes. Create tags in Tidio before import. |
| Thread Fields | Contact Properties or Ticket Custom Fields | Tidio ticket custom fields are limited to text and dropdown types. Move thread-level metadata to Contact Properties or append to ticket notes for richer field types. |
| Users (agents) | Operators | Must be created manually in Tidio. The API does not support Operator creation. |
| SLA Policies | _(Manual rebuild)_ | No API migration path. Rebuild in Tidio settings. |
Plain Tidio
| Plain field | Tidio field | Notes |
|---|---|---|
| customer.fullName | contact.name | Direct |
| customer.email.email | contact.email | Primary dedup key. Query GET /contacts?email= before POST /contacts to prevent duplicates. |
| customer.phone | contact.phone | Direct |
| customer.externalId | contact.distinct_id | Direct — but distinct_id is limited to 55 characters. Truncate with logging if exceeded. |
| customer.company.name | contact.properties.company_name | Requires pre-creating the property in Tidio (type: text). |
| customer.tenants [].name | contact.properties.tenant_names | Concatenate with delimiter (e.g., `Tenant A |
| thread.title | ticket.subject | Direct |
| thread.status | ticket.status | TODO → open, DONE → solved, SNOOZED → pending |
| thread.statusDetail | ticket.properties.status_detail | Preserve WAITING_FOR_CUSTOMER, IN_PROGRESS, etc. for analytics granularity. |
| thread.priority | ticket.priority | 0 → urgent, 2 → normal, 3 → low. Plain's 1 (high) has no Tidio equivalent — map to urgent or preserve original value in a custom field plain_priority. |
| thread.labels [].name | ticket.tags | Flatten nested labels. A label path billing > refunds becomes tag billing__refunds or two separate tags. |
| thread.createdAt | ticket.created_at | Must explicitly set this via the API. If omitted, Tidio stamps the current date, destroying historical timeline accuracy. |
| thread.assignee.email | ticket.operator_id | Look up Tidio operator ID by email. Build a lookup table during Step 1. |
| timeline.EmailEntry (inbound) | ticket.message | Extract body text. Convert Markdown to HTML. Set type: "public". |
| timeline.EmailEntry (outbound) | ticket.message | Map sender to operator. Set type: "public". |
| timeline.ChatEntry | ticket.message | Direct body extraction. Set type: "public". |
| timeline.NoteEntry | Internal ticket message | Set type: "internal". Preserve author attribution. |
| timeline.CustomEntry | Internal ticket message | Parse JSON payload into human-readable text block. Append as internal note with prefix [Custom Event]. |
| Thread Field (custom) | contact.properties.{key} | Type conversion required: Plain boolean → Tidio text ("true"/"false"), Plain enum → Tidio dropdown (values must be pre-defined). |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Contacts / Customers | medium | Customer records map reasonably well to Tidio Contacts by email, but the absence of automatic deduplication in Tidio's API requires explicit pre-check queries to prevent duplicate contact creation at scale. |
| Companies | high | Tidio has no native Company object, so Plain's Company-level data must be encoded as Contact Properties or Tags, resulting in a structural demotion that permanently flattens account-level context and may break downstream reporting. |
| Tenants | high | Plain's Tenant construct — allowing multiple tenants per customer — has no Tidio equivalent whatsoever, and all tenant membership data must either be discarded or approximated through tag schemes that cannot preserve the original relational structure. |
| Threads / Tickets | medium | Plain Threads map to Tidio Tickets or Conversations with reasonable fidelity when using the JSONL import or API, but status mapping (Todo/Done/Snoozed → Open/Pending/Solved) requires explicit business logic decisions that may not be reversible. |
| Messages / Timeline Entries | medium | Plain's thread timeline contains not just messages but also events and assignment changes, which have no Tidio equivalent and will be silently dropped unless explicitly converted to internal notes before import. |
| Labels | low | Plain's hierarchical labels (up to three levels deep) can be migrated to Tidio Tags, though the hierarchy will be flattened, and label names must be de-duplicated and sanitized to conform to Tidio's tag format. |
| Thread Fields / Custom Attributes | medium | Plain's per-thread custom fields and customer custom attributes must be mapped to Tidio's Contact Properties or Ticket Custom Fields, requiring a field-by-field mapping exercise with potential loss of fields that have no compatible type in Tidio. |
| Attachments | high | All Plain-hosted attachments must be re-hosted to publicly accessible CDN URLs before migration, and Tidio's API does not expose attachment fields on ticket reply endpoints, making attachment preservation unreliable outside the JSONL import path. |
| Operators / Assignees | low | Agent accounts must be pre-created in Tidio before migration and mapped by email to Plain assignees, but this is a straightforward manual prerequisite with low risk of data loss if completed correctly. |
| Historical Timestamps | medium | Preserving original creation and reply timestamps requires using Plain's importThread and importThreadMessages mutations on extraction and passing created_at fields explicitly on import; standard API creation endpoints on either side will overwrite timestamps with the current time. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
No Native Migration Path
There is no built-in export or import bridge between Plain and Tidio, requiring custom scripting to extract data from Plain's GraphQL API and load it into Tidio's REST API or file importers.
GraphQL to REST Translation
Plain's GraphQL schema requires complex query construction with pagination and complexity-budget management, while Tidio's REST API enforces separate rate limits (60–120 req/min by plan), meaning both extraction and loading must be independently throttled.
Hierarchical Model Flattening
Plain's multi-level object hierarchy — Companies containing Tenants containing Customers — has no native equivalent in Tidio, requiring deliberate design decisions to encode organizational context as Contact Properties or Tags without losing reporting structure.
Duplicate Contact Prevention
Tidio's POST /contacts endpoint always creates a new contact and does not perform email-based deduplication, so the migration script must explicitly query for existing contacts by email before every write to avoid duplicate records.
Plan-Gated API and Import Access
Tidio's ticket JSONL import and full REST API access require a Plus ($749/mo) or Premium ($2,999/mo) plan, meaning teams on lower tiers must upgrade before any ticket or conversation history can be migrated.
Attachment URL Accessibility
Plain-hosted attachments must be re-hosted to publicly accessible URLs before JSONL import, as Tidio's importer downloads attachment files at processing time and cannot reach authenticated or private storage endpoints.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can I migrate conversation history from Plain to Tidio?
Yes, but only via Tidio's REST API or JSONL ticket import — not CSV. You need to extract threads and timeline messages from Plain's GraphQL API, transform them to match Tidio's ticket structure, and load them through Tidio's OpenAPI endpoints or JSONL import. The JSONL import path requires a Plus plan or higher. There is no native one-click migration path between the two platforms.
What are Tidio's API rate limits for migration?
Tidio's OpenAPI rate limits are 60 requests per minute on the Plus plan and 120 requests per minute on Premium. Free and Starter plans do not include OpenAPI access. At maximum rate, migrating 10K conversations with associated messages can take 10+ hours of sustained API time. Implement exponential backoff for 429 responses and track the X-RateLimit-Remaining header proactively.
Does Tidio support companies or tenants like Plain?
No. Tidio has no Company, Organization, or Tenant object. Plain's Company-to-Customer and Tenant-to-Customer hierarchies must be flattened during migration. The typical approach is to store company name and tenant memberships as custom Contact Properties in Tidio, which preserves the data but loses the relational grouping.
How are attachments handled when moving from Plain to Tidio?
Plain secures attachments with expiring signed URLs. Your migration must download files from Plain and either re-upload them to Tidio or stage them at stable public URLs for the JSONL import path. Tidio's documented ticket reply endpoint does not expose attachment fields, so the JSONL import is the more reliable path for attachment-heavy history.
What Tidio plan do I need for API-based migration?
Tidio's OpenAPI requires a Plus plan ($749/month) or Premium plan ($2,999/month). Standard Starter and Growth plans do not include OpenAPI access. Confirm your plan includes API access before building any migration scripts.