Podium to Unthread Migration: The CTO's Technical Guide

Last verified: July 27, 2026, against Podium API v4 and Unthread's public docs/API. (docs.podium.com)

Migrating from Podium to Unthread means moving data between two platforms that share almost no structural overlap. Podium is a customer interaction platform for local businesses built around SMS messaging, webchat, reviews, payments, and campaigns. Unthread is a Slack-native AI helpdesk that converts Slack conversations into tracked, routed, and resolved tickets. There is no native migration path between them. Every record requires deliberate schema translation.

The fastest viable path is a custom API-based ETL pipeline or a managed migration service. Podium's CSV exports cover contacts but miss conversation threading, message history, and relational context. Middleware tools like Zapier can forward new records but cannot handle bulk historical migration at scale.

This guide covers the technical architecture, data mapping rules, API constraints, edge cases, and step-by-step process for executing a high-fidelity migration from Podium to Unthread.

For related Unthread migrations, see:

• Freshchat to Unthread Migration: Covers Freshchat-specific extraction patterns and Unthread's API import behavior.
• Kustomer to Unthread Migration: For teams coming from a CRM-centric helpdesk.
• Gladly to Unthread Migration: Handles people-centric data model translation.

Why Teams Move from Podium to Unthread

The shift is architectural, not incremental. Teams migrate for these reasons:

• Channel realignment. Podium is built for external-facing SMS, webchat, and review management for local businesses. Teams whose support operations have shifted to Slack-based B2B customer communication or internal IT/HR support need a platform built for that workflow. Among Slack-native helpdesks (Halp, Thena, Foqal, ClearFeed), Unthread differentiates by offering full ticket lifecycle management with SLAs, AI agents, and native email/in-app chat channels — making it suitable as a primary helpdesk rather than a Slack add-on.
• Operational maturity. Podium has no concept of SLAs, ticket types, escalation paths, or structured routing. When support operations grow beyond "reply to texts" into tracked, prioritized ticket management, Unthread is purpose-built for that.
• AI-native support. Unthread's AI agents operate directly inside Slack channels for auto-classification, suggested responses, and ticket resolution. Podium's AI features are add-ons focused on review responses and receptionist functionality, not ticket resolution.
• Cost structure. Podium's published plans start at $399/month (Core) and scale to $599+/month (Pro) with per-location fees and add-ons. Unthread starts at $50/agent/month (Basic) or $75/agent/month (Pro). For a 5-agent team, that's $250–$375/month on Unthread vs. $399–$599+/month on Podium — a 35–60% reduction for teams that primarily need ticketing and conversation tracking. Verify current pricing directly with each vendor before planning, as both have changed pricing in the past 12 months.

Core Data Model Differences

Understanding how these platforms model data is the prerequisite for any migration plan.

Podium's data model is conversation-first and channel-agnostic (SMS, email, webchat, Apple Chat, Facebook). Unthread's model is ticket-first and Slack-native, with email and in-app chat as secondary channels. Reviews, payments, and campaign data have no native Unthread equivalent — plan to archive these before migration.

Migration Approaches

1. CSV Export + Manual Import

How it works: Export contacts from Podium as CSV (available via the Contacts tab or by requesting an export from Podium support). Manually create corresponding Customer and Account records in Unthread via the web UI or API. (podium.com)

When to use it: Small datasets (<500 contacts) where conversation history is not required.

Pros:

• No engineering effort for the contact portion
• Quick for contact-only migrations

Cons:

• Podium's CSV export only includes Name, Phone, Email, Contact Status, Address, Tags, and Date Added — no conversation history, no messages, no attachments
• Unthread has no bulk CSV import UI; you still need API calls to create Customer/Account records
• No relationship preservation between contacts and conversations

Complexity: Low (contacts only) / Not viable (full migration)

2. FTP Raw Data Export + Custom ETL

How it works: Request access to Podium's FTP raw data export (requires Account Owner approval). Podium exposes flat data tables: Messages, Contacts, Leads, Campaigns, Campaign Contacts, Reviews, Review Invites, Payments, Feedback, and Locations/Organizations. Download these tables, transform them into Unthread's schema, and load via the Unthread API.

When to use it: Mid-size to large datasets where you need conversation history and can invest engineering time.

Pros:

• Access to the full Podium dataset including message bodies, conversation metadata, and lead data
• Flat table structure is straightforward to parse
• No API rate limit concerns on the extraction side

Cons:

• FTP access must be requested and approved by Podium — budget 3–5 business days
• Data is denormalized; you need to reconstruct conversation threads from conversation_uid groupings
• Message attachments are not included in FTP exports — binary files require separate handling via the API
• Requires significant transformation logic to map Podium's continuous conversation model to Unthread's discrete ticket model

Complexity: Medium–High

3. API-Based Migration (Podium REST API → Unthread REST API)

How it works: Extract data programmatically from Podium's REST API using OAuth 2.0 authentication, transform in-memory or via intermediate storage, and load into Unthread's API using service account API keys. (docs.podium.com)

When to use it: Full-fidelity migrations where you need conversation threading, message history, and relational context preserved.

Pros:

• Most granular control over what gets migrated
• Can preserve conversation→message relationships
• Real-time access to current data state
• Can handle incremental/delta migrations

Cons:

• Podium's API enforces rate limits (the docs specify HTTP 429 responses for exceeded limits but do not publish an exact requests-per-second ceiling — empirically, sustained extraction rates above ~2 requests/second trigger throttling). Extraction of 10K+ conversations with associated messages can take 2–4 days of continuous API calls. (docs.podium.com)
• Podium developer account requires application and multi-day approval
• OAuth 2.0 tokens need refresh logic (tokens expire; build automatic refresh before expiry)
• Unthread API pagination is capped at 100 records per page; Unthread's write endpoint rate limits are not published in the public docs — start conservatively at ~1 request/second and adjust based on 429 response frequency

Complexity: High

4. Middleware Platforms (Zapier, Make)

How it works: Use iPaaS connectors to bridge Podium triggers/actions to Unthread actions. Typically limited to forwarding new records as they arrive.

When to use it: Ongoing sync of new conversations during a transition period — not for historical data migration.

Pros:

• No code required for simple forwarding
• Useful as a bridge during cutover

Cons:

• Cannot migrate historical data in bulk
• No native Unthread connector on most middleware platforms as of mid-2026
• Limited transformation capabilities for schema translation
• Per-task pricing makes high-volume operations expensive
• Podium webhooks time out after 5 seconds and queued events live for around 10 days (docs.podium.com)

Complexity: Low (but limited scope)

5. Managed Migration Service

How it works: A migration partner handles extraction, transformation, loading, validation, and rollback planning end-to-end.

When to use it: When engineering bandwidth is limited, the dataset is large, or the migration is business-critical with zero tolerance for data loss.

Pros:

• Fastest time-to-completion
• Expert handling of edge cases (duplicate contacts, orphaned messages, encoding issues)
• Validation and QA built into the process
• No internal engineering hours consumed

Cons:

• External cost (typically $5K–$25K depending on dataset size and complexity)
• Requires sharing data access with a third party

Complexity: Low (for your team)

Migration Approach Comparison

Recommendations by scenario:

• Small business, contacts only: CSV export + Unthread API script
• Mid-size, full history needed, dev team available: FTP export + custom ETL pipeline
• Enterprise or business-critical: Managed migration service
• Ongoing sync during transition: Middleware bridge for net-new data + API migration for historical data

When to Use a Managed Migration Service

Building a Podium-to-Unthread migration pipeline in-house is straightforward to start and deceptively hard to finish. The common failure modes:

• Conversation thread reconstruction. Podium's FTP export delivers flat message rows keyed by conversation_uid. Reassembling these into threaded Unthread conversations with correct chronological ordering, sender attribution, and status mapping requires careful deduplication logic.
• Contact deduplication. Podium contacts are identified by phone number (channel_unique_identifier). The same person can have multiple contact channel entries across different channel types (phone, email, secure). Merging these into a single Unthread Customer or Account without creating duplicates requires fuzzy matching on name + phone + email combinations.
• Rate limit math. Podium's API throttle (~2 req/s empirically) combined with Unthread's 100-record pagination limit mean a dataset of 25K+ conversations with associated messages can take 3–5 days of continuous API calls. Most internal teams underestimate this by 3–5x because they calculate based on conversation count alone, forgetting that each conversation requires N+1 API calls (1 conversation + N messages).
• Accidental re-sending. Historical messages replayed into Unthread can trigger outbound notifications to customers if conversation type and note visibility are not configured correctly. This is a non-recoverable mistake — you cannot unsend a message that was delivered to a customer's Slack channel or email inbox. (docs.podium.com)
• Hidden engineering cost. Internal migrations consistently consume 80–160 engineer-hours for mid-size datasets (5K–25K conversations). At a fully-loaded engineering cost of $150–$200/hour, that's $12K–$32K in opportunity cost — often more than a managed service.

Do not build this in-house if: you need attachments, you have more than one Podium location, you rely on adjacent CRM relationships, or you need a short cutover window. The expensive part is not writing HTTP calls. It is identity matching, archive strategy, replay design, QA, and rollback.

Why ClonePartner: We have executed 1,500+ migrations across helpdesk platforms, including complex schema translation projects where source and target share no structural overlap. For Podium migrations specifically, we handle the FTP/API extraction, conversation threading reconstruction, contact deduplication, and Unthread API loading — with validation at every stage. If your migration involves more than 5,000 conversations or requires zero downtime, talk to us.

Pre-Migration Planning

Compliance and Data Residency

Before extracting any customer PII from Podium:

• GDPR: If you process data of EU residents, your staging database constitutes a new processing activity. Update your Records of Processing Activities (ROPA). If your staging environment is hosted outside the EU, ensure you have appropriate transfer mechanisms (SCCs or adequacy decisions) in place.
• CCPA/CPRA: California consumer data must be handled per your privacy policy's stated purposes. Migration is generally covered under "business purposes," but verify your specific disclosures.
• Data residency: Confirm where Podium stores your data (US by default) and where Unthread stores data. If your staging database is in a different region, you may be creating a cross-border transfer. PostgreSQL on a cloud provider in the same region as your Unthread instance minimizes risk.
• Data minimization: Only extract and stage what you intend to migrate. Purge the staging database within 30 days of migration completion.
• Third-party access: If using a managed migration service, execute a Data Processing Agreement (DPA) before granting access.

Data Audit Checklist

Before extracting anything, audit what exists in Podium and what matters:

Define Migration Scope

1. Date cutoff. Migrating all historical data is rarely necessary. Most teams migrate the last 12–24 months of conversations and all active contacts.
2. Channel filter. Podium supports SMS, email, webchat, Apple Chat, Facebook. Decide which channel conversations are worth migrating vs. archiving.
3. Status filter. Migrate only open/active conversations as live tickets. Closed conversations can be imported as closed tickets for reference or archived externally.
4. Identifier resolution. Podium relies heavily on phone numbers. Unthread uses emails and Slack IDs. Decide how to handle Podium contacts that lack an email address — options include enrichment from a CRM or generating deterministic placeholder emails (e.g., {phone}@podium-archive.local).

Migration Strategy

• Big bang: Extract everything, transform, load, cut over in one weekend. Best for datasets under 10K conversations.
• Phased: Migrate contacts and accounts first, then conversations in batches by date range or location. Best for 10K–100K conversations.
• Incremental: Migrate historical data in phases while running both platforms in parallel, using middleware or webhooks to sync new records. Best for enterprise datasets or zero-downtime requirements.

If you need a broader prep template, start with our Help Desk Data Migration Checklist.

Data Model and Object Mapping

Contacts → Customers + Accounts

Podium Contacts map to either Unthread Customers (channel-level entities tied to Slack channels) or Accounts (organization-level entities with support assignees and email domains).

Decision framework:

• If the Podium contact represents a company/organization → create an Unthread Account
• If the Podium contact represents an individual end-user → create an Unthread Customer linked to an Account
• If both → create an Account first, then associate the Customer

Locations → Accounts

Podium's Organization → Location hierarchy maps to flat Unthread Accounts. Each Podium Location becomes a separate Unthread Account with the location's name. The Podium Organization name can be stored in a custom field or tag.

Conversations → Conversations (Tickets)

A Podium conversation is a continuous thread. You must decide how to segment these into discrete Unthread tickets. Two common approaches:

1. Import the entire Podium thread as a single closed ticket — simplest, works for archival purposes.
2. Group messages by time decay (e.g., a gap of 7+ days creates a new ticket) — more useful if agents need to search by incident.

Key field mappings:

Messages → Messages

Each conversation_item in Podium's Messages table becomes a Message in Unthread:

Replay history as private notes for closed conversations. This prevents Unthread from accidentally sending historical messages as outbound customer-visible replies.

Tags → Tags

Podium contact tags and campaign opt-in tags map directly to Unthread Tags. Create tags in Unthread first via POST /tags, then associate them with conversations or customers using the link endpoints.

Custom Fields → Ticket Type Fields

Podium supports up to 8 contact custom fields with types including BOOLEAN, DATETIME, FLOAT, INTEGER, STRING, SINGLE_SELECT, and MULTI_SELECT. Unthread Ticket Type Fields support short-answer, long-answer, multi-select, single-select, checkbox, date, and user-select. Type mapping:

Map by type, not by label alone. (docs.podium.com)

Reviews, Payments, and Campaigns

Unthread has no equivalent for these Podium objects. Export them to a separate data store (S3, data warehouse, or spreadsheet archive) before migration. Do not attempt to force this data into Unthread's schema — if reviews, campaigns, or payments still matter to the business, leave them in Podium or another system of record.

Migration Architecture

The architecture follows a standard Extract → Stage → Transform → Load → Validate pipeline. An intermediate database (PostgreSQL recommended) prevents data loss during API timeouts and provides a staging layer for joins and deduplication.

Extraction Layer

Option A: FTP Export

• Request FTP access from your Podium Account Owner (budget 3–5 business days for approval)
• Download all available tables as flat files
• Parse into a staging database

Option B: REST API

• Register an OAuth 2.0 app at developer.podium.com (requires approval — plan for several business days)
• Authenticate via OAuth 2.0 flow to obtain access tokens with refresh logic (set a timer to refresh tokens ~5 minutes before expiry)
• Podium's API returns 429 Too Many Requests when rate limits are exceeded but does not publish the exact threshold. Empirically, sustained rates above ~2 requests/second trigger throttling. Build a fixed-delay pacer (500ms between requests) or token bucket into your extraction script rather than reacting to 429 responses with retry logic. Proactive throttling creates predictable throughput — expect roughly 5,000–7,000 contacts/hour or 3,000–5,000 conversations/hour depending on payload size. (docs.podium.com)
• The contacts endpoint supports updated_at filtering for delta runs (docs.podium.com)

Critical for both approaches: Download all attachments during extraction. Podium attachment URLs are time-limited signed URLs that expire after 7 days. If you delay, you lose them. (docs.podium.com)

Transformation Layer

1. Deduplicate contacts by contact_uid — Podium contacts can have multiple channel entries (phone, email, secure) for the same person. Without deduplication, you'll create 2–3x the expected Customer/Account count.
2. Reconstruct conversation threads by grouping conversation_item rows by conversation_uid, ordered by conversation_item_inserted_at.
3. Map statuses from Podium's binary open/closed to Unthread's four-state model (open, in_progress, on_hold, closed).
4. Convert Podium Locations to Unthread Accounts.
5. Map inbox names to Unthread Ticket Types.
6. Strip or convert message formatting — Podium messages are plain text; Unthread expects Slack-compatible markdown (mrkdwn). Convert any HTML entities, strip unsupported formatting.
7. Generate placeholder emails for SMS-only contacts to satisfy Unthread's schema requirements (e.g., {phone}@podium-archive.local).

Loading Layer

Unthread API endpoints:

Authentication: X-Api-Key header with a service account key generated from Unthread's Setup > Service Accounts.

Idempotency: Unthread's create endpoints are not idempotent — calling POST /conversations twice with the same payload creates two conversations. To handle partial failures and script re-runs:

1. Maintain a source_id → target_id crosswalk table in your staging database
2. Before each create call, check the crosswalk — if a target ID already exists for that source ID, skip the create
3. Wrap each create + crosswalk-insert in a database transaction
4. On script restart, resume from the last uncommitted source ID

Error Handling

Both APIs return standard HTTP error codes. Key responses to handle:

Both Podium and Unthread return JSON error bodies. Podium's format: {"error": {"code": "...", "message": "..."}}. Log the full response body for every non-2xx response.

Delta Sync

If you are not doing a hard cutover, let Podium webhooks feed a queue and push only new or changed records into Unthread after the historical backfill completes. Note that Podium webhooks time out after 5 seconds and queued events live for around 10 days — if your migration takes longer than 10 days, events from early in the process may be lost. (docs.podium.com)

Step-by-Step Migration Process

Step 1: Extract Data from Podium

For FTP approach: Request FTP access through your Podium Account Owner. Download all tables. Load into a staging database.

For API approach:

import requests
import time
import json
 
PODIUM_BASE = "https://api.podium.com/v4"
RATE_LIMIT_DELAY = 0.5  # 500ms between requests (~2 req/s)
 
def get_podium_headers(access_token):
    return {"Authorization": f"Bearer {access_token}"}
 
def extract_contacts(access_token, staging_db):
    """Extract all contacts and persist raw JSON to staging DB."""
    url = f"{PODIUM_BASE}/contacts"
    page = 0
    while url:
        resp = requests.get(url, headers=get_podium_headers(access_token))
        if resp.status_code == 429:
            retry_after = int(resp.headers.get("Retry-After", 5))
            time.sleep(retry_after)
            continue
        resp.raise_for_status()
        data = resp.json()
        for contact in data.get("data", []):
            staging_db.upsert("raw_contacts", {
                "contact_uid": contact["uid"],
                "raw_json": json.dumps(contact),
                "extracted_at": "NOW()"
            })
        page += 1
        url = data.get("links", {}).get("next")
        time.sleep(RATE_LIMIT_DELAY)
    return page
 
def extract_conversations(access_token, staging_db):
    """Extract conversations with messages. ~3,000-5,000 conversations/hour."""
    url = f"{PODIUM_BASE}/conversations"
    while url:
        resp = requests.get(url, headers=get_podium_headers(access_token))
        if resp.status_code == 429:
            time.sleep(int(resp.headers.get("Retry-After", 5)))
            continue
        resp.raise_for_status()
        data = resp.json()
        for conv in data.get("data", []):
            staging_db.upsert("raw_conversations", {
                "conversation_uid": conv["uid"],
                "raw_json": json.dumps(conv),
                "extracted_at": "NOW()"
            })
            # Download attachments immediately - URLs expire in 7 days
            for item in conv.get("items", []):
                for attachment in item.get("attachments", []):
                    download_attachment(attachment["url"], staging_db)
        url = data.get("links", {}).get("next")
        time.sleep(RATE_LIMIT_DELAY)

Do not attempt to transform data on the fly during extraction. Store raw JSON in your staging database and download attachments immediately — attachment URLs expire.

Step 2: Transform Data

def transform_contact_to_account(podium_contact, location_map):
    """Map a Podium contact + location to an Unthread Account."""
    location = location_map.get(podium_contact.get("location_uid", ""), {})
    email = podium_contact.get("email")
    phone = podium_contact.get("phoneNumber", "")
 
    # Generate deterministic placeholder for SMS-only contacts
    if not email and phone:
        email = f"{phone.replace('+', '')}@podium-archive.local"
 
    return {
        "name": location.get("location_name", podium_contact.get("contact_name", "Unknown")),
        "emailsAndDomains": [email] if email else [],
        "customFields": [
            {"key": "podium_org", "value": location.get("organization_name", "")},
            {"key": "podium_contact_uid", "value": podium_contact.get("contact_uid", "")},
            {"key": "podium_phone", "value": phone}
        ]
    }
 
def transform_conversation(podium_conv, customer_id_map):
    """Map a Podium conversation to an Unthread conversation."""
    status = "closed" if podium_conv.get("conversation_is_closed") else "open"
    original_ts = podium_conv.get("conversation_inserted_at", "")
    contact_name = podium_conv.get("contact_name", "Unknown")
    first_body = podium_conv.get("first_message_body", "(migrated conversation)")
 
    # Embed original timestamp in message body since Unthread
    # does not support backdating
    markdown = f"**[Migrated from Podium | {original_ts}]**\n\n{first_body}"
 
    return {
        "type": "triage",  # No live channel for historical imports
        "markdown": markdown,
        "status": status,
        "title": f"[Migrated] {contact_name}",
        "customerId": customer_id_map.get(podium_conv.get("contact_channel_uid")),
        "metadata": {
            "podium_conversation_uid": podium_conv.get("conversation_uid"),
            "podium_channel_type": podium_conv.get("conversation_channel_type"),
            "podium_inserted_at": original_ts
        }
    }
 
def transform_message(podium_item, is_closed_conversation=True):
    """Transform a Podium message to an Unthread message.
    Replay as private note if conversation is closed to prevent
    accidental outbound delivery."""
    original_ts = podium_item.get("conversation_item_inserted_at", "")
    sender = podium_item.get("conversation_item_sender_name", "Unknown")
    body = podium_item.get("conversation_item_body", "")
    is_internal = podium_item.get("conversation_item_type") == "internal_note"
 
    return {
        "markdown": f"**[{original_ts} — {sender}]**\n{body}",
        "isPrivateNote": is_internal or is_closed_conversation
    }

Key transformation tasks:

• Cleanse invalid characters and format phone numbers to E.164 standard
• Resolve user mappings (Podium agent IDs → Unthread user IDs)
• Generate placeholder emails for SMS-only contacts
• Normalize picklist and custom field values by type

Step 3: Load into Unthread

Load in strict relational order to maintain referential integrity:

1. Accounts
2. Customers (linked to Accounts)
3. Tags and Ticket Types
4. Conversations (with initial message body)
5. Messages (replayed via POST /conversations/:id/messages)
6. Attachments

import requests
import time
 
UNTHREAD_BASE = "https://api.unthread.io/api"
WRITE_DELAY = 1.0  # ~1 req/s conservative start; increase to ~60-90/min after testing
 
def get_unthread_headers(api_key):
    return {
        "X-Api-Key": api_key,
        "Content-Type": "application/json"
    }
 
def create_with_crosswalk(api_key, endpoint, payload, source_id, entity_type, crosswalk_db):
    """Idempotent create: check crosswalk before creating to handle re-runs."""
    existing = crosswalk_db.get(entity_type, source_id)
    if existing:
        return existing  # Already created in a previous run
 
    resp = requests.post(
        f"{UNTHREAD_BASE}/{endpoint}",
        headers=get_unthread_headers(api_key),
        json=payload
    )
    if resp.status_code == 429:
        time.sleep(int(resp.headers.get("Retry-After", 5)))
        return create_with_crosswalk(api_key, endpoint, payload, source_id, entity_type, crosswalk_db)
    if resp.status_code >= 500:
        time.sleep(5)
        resp = requests.post(f"{UNTHREAD_BASE}/{endpoint}",
                           headers=get_unthread_headers(api_key), json=payload)
    resp.raise_for_status()
    result = resp.json()
    crosswalk_db.insert(entity_type, source_id, result["id"])
    time.sleep(WRITE_DELAY)
    return result
 
def create_account(api_key, account_data, source_id, crosswalk_db):
    return create_with_crosswalk(api_key, "accounts", account_data, source_id, "account", crosswalk_db)
 
def create_conversation(api_key, conv_data, source_id, crosswalk_db):
    return create_with_crosswalk(api_key, "conversations", conv_data, source_id, "conversation", crosswalk_db)
 
def add_message(api_key, conversation_id, message_data):
    resp = requests.post(
        f"{UNTHREAD_BASE}/conversations/{conversation_id}/messages",
        headers=get_unthread_headers(api_key),
        json=message_data
    )
    if resp.status_code == 429:
        time.sleep(int(resp.headers.get("Retry-After", 5)))
        return add_message(api_key, conversation_id, message_data)
    resp.raise_for_status()
    time.sleep(WRITE_DELAY)
    return resp.json()

Replay closed conversations as private notes to prevent Unthread from sending historical messages as outbound replies to customers.

Error handling that matters:

• Checkpoint every page cursor and every created target ID in the crosswalk table
• Retry 429 and 5xx with exponential backoff (initial delay 1s, max 60s, max 3 retries for 5xx)
• Keep a dead-letter queue for failed records — log the full request payload and response body
• Store source-to-target ID crosswalks in a durable PostgreSQL table, not in-memory
• Checksum or size-check attachments after upload (compare source file size to uploaded file size)

Step 4: Rebuild Relationships

After creating all Accounts, Customers, and Conversations:

1. Link Customers to Accounts using customerId references
2. Apply Tags to Conversations via POST /tags/:tagId/conversations/create-links
3. Apply Tags to Customers via POST /tags/:tagId/customers/create-links
4. Set support assignees on Accounts via PATCH /accounts/:accountId

Step 5: Validate

See the Validation section below.

Step 6: Delta Sync and Cutover

Run a final sync to capture any messages created in Podium during the migration window. Push them to Unthread before switching your routing rules, DNS, and webhooks. If your migration window exceeds 10 days, use the API for delta extraction rather than webhooks (webhook events expire after ~10 days).

Edge Cases and Challenges

Duplicate Contacts

Podium contacts can have multiple channel entries (phone, email, secure) for the same person. Podium can also automatically merge contacts, so merged UIDs need alias handling in your crosswalk — when a contact is merged, the old UID becomes an alias that should resolve to the surviving UID. (docs.podium.com) Deduplicate by matching on contact_uid before creating Unthread records. Without this step, expect 2–3x the expected Customer/Account count.

Multi-Channel Conversations

A single Podium conversation can span SMS and webchat. Unthread conversations are typed (slack, email, triage). You must choose one type per migrated conversation — use triage for historical imports since there is no live channel to connect.

Attachments

Podium's FTP export does not include binary attachments. The API exposes attachment URLs, but these are time-limited signed URLs that expire after 7 days. (docs.podium.com) Your script must download binary files during extraction and re-upload them to Unthread as multipart form data. Unthread limits attachments to 20MB per file and 10 files per Slack message — split oversized payloads accordingly. If a single Podium message has >10 attachments, split across multiple Unthread messages with a [continued] marker.

Conversation Threading

Podium stores messages as flat rows. To reconstruct a threaded conversation in Unthread:

1. Group all conversation_item rows by conversation_uid
2. Sort by conversation_item_inserted_at
3. Use the first message as the conversation's markdown body
4. Replay subsequent messages via POST /conversations/:id/messages

Internal Notes vs. Customer Messages

Podium's conversation_item_type distinguishes between customer-facing messages and internal notes. Map internal notes to Unthread's isPrivateNote: true parameter. For historical messages on closed conversations, replay all messages as private notes to prevent accidental outbound delivery.

Agent Attribution

If an agent has left the company and does not exist in Unthread, their historical messages will fail to import unless mapped to a fallback "System User" or "Archived Agent" account. Establish these fallback mappings before starting the load phase. Create a dedicated Unthread user named "Archived Agent" and use it as the default assignedToUserId for any unresolvable Podium agent UIDs.

Deprecated Webhook Fields

Podium marks contact and sender in the message object as deprecated in webhook payloads. Parse stable IDs from the currently documented fields, not fields scheduled for removal. (docs.podium.com)

SMS-Only Contacts

Unthread expects B2B identifiers (email or Slack ID). Use a deterministic email generation pattern for SMS-only contacts: {e164_phone_without_plus}@podium-archive.local (e.g., 14155551234@podium-archive.local). This satisfies schema requirements while remaining clearly distinguishable from real email addresses. Document this convention so agents understand what these addresses mean.

Multi-Level Relationships

The same person can interact across multiple Podium locations and channels. If you key only on phone or only on email domain, you will over-merge contacts. Use contact_uid as the primary deduplication key. (docs.podium.com)

Character Encoding

Podium SMS messages may contain emoji, non-ASCII characters, or special Unicode sequences. Ensure your staging database uses UTF-8 encoding and that your transformation layer handles emoji correctly — Slack's mrkdwn format supports standard Unicode but not all HTML entities.

Limitations and Constraints

Podium-Side

• FTP access requires Account Owner request and Podium approval — budget 3–5 business days
• API rate limits apply — empirically ~2 requests/second sustained; 429 responses when exceeded; no published ceiling (docs.podium.com)
• Developer account approval takes several business days per Podium's documentation
• No bulk export API — data must be extracted record-by-record or via FTP
• Custom fields limited to 8 per contact
• OAuth tokens expire — build automatic refresh logic

Unthread-Side

• No native historical import from external platforms — all ingestion goes through the API
• Slack channel history backfill covers 6 months of Slack-native messages only — not useful for Podium data
• Pagination capped at 100 records per page on all list endpoints
• File attachments limited to 20MB per file and 10 per Slack message
• Conversation types are fixed (slack, email, triage) — historical Podium conversations should use triage
• No true custom objects — custom data lives in Ticket Type Fields, not arbitrary entities
• No timestamp override — the public docs do not show fields for backdating imported conversations or messages; original timestamps must be embedded in message body text (docs.unthread.io)
• Email connector is forward-only — Unthread only creates tickets from new inbound email after setup, not historical email
• Write endpoint rate limits not published — empirically sustains ~60–90 writes/minute before throttling
• Create endpoints are not idempotent — duplicate records will be created if a script is re-run without crosswalk checking
• Bulk delete not available via public API — rollback requires record-by-record DELETE calls, which at 100 records/page listing + individual deletes can take hours for large datasets

Structural Data Loss

• Reviews, payments, campaign data, and feedback surveys have no Unthread equivalent — structurally lost if not archived separately
• Podium's channel type granularity (phone, email, secure, Apple Chat, Facebook) collapses into Unthread's three conversation types
• Podium's lead-specific fields (conversation_first_response_sent_at, time_to_convert_seconds) have no mapping in Unthread
• Historical messages imported via API are accessible in the Unthread web dashboard but cannot be retroactively injected into Slack channels
• Original message timestamps are lost — Unthread auto-timestamps at import time; original timestamps can only be preserved as text within message bodies
• If using HubSpot or Salesforce sync, account changes can take up to an hour to reflect inside Unthread (docs.unthread.io)

Validation and Testing

Record Count Comparison

After loading, verify counts at each level:

Field-Level Validation

Sample 5–10% of records across each entity type (minimum 50 records per entity, maximum 500). For each sampled record:

• Compare contact name, email, and phone against source
• Verify conversation status mapping (open/closed)
• Confirm message body text integrity (character-for-character comparison of first 500 chars)
• Check that tag associations are correct
• Validate custom field values in Ticket Type Fields
• Verify attachment accessibility — open files, check sizes match source within 1%
• Confirm metadata.podium_conversation_uid matches the source conversation UID

UAT Process

1. Pilot migration: Run the full pipeline against a test Unthread project with 100–500 records. Verify end-to-end before touching production.
2. Agent walkthrough: Have 2–3 support agents review 20+ migrated conversations for completeness, readability, and correct attribution.
3. Edge case spot-check: Specifically verify multi-message conversations (10+ messages), conversations with attachments, conversations with internal notes, and SMS-only contacts with placeholder emails.
4. Rollback test: Verify that migrated records can be deleted via DELETE endpoints without affecting native Unthread data. Note: Unthread does not offer bulk delete — deletion is record-by-record. For a 10K conversation migration, full rollback via API takes approximately 3–5 hours at sustained delete rates.

For a comprehensive post-migration testing framework, see our Post-Migration QA Checklist.

Post-Migration Tasks

Rebuild Automations

Podium's automations (review invites, campaign triggers, data feed workflows) do not transfer. Rebuild in Unthread using:

• Automations API (POST /automations) for event-triggered workflows
• Ticket Type Fields with conditions for dynamic form behavior
• Support Steps on Customers for escalation paths and SLA enforcement

Configure Slack Channels

Unthread's primary intake is Slack. After migration:

• Connect customer Slack channels to Unthread Customers
• Configure autoresponder settings per customer
• Set up triage channels for internal routing
• Enable AI agents on appropriate channels

Update External Integrations

• Update your website widgets and SMS webhooks to point to Unthread instead of Podium
• Reconnect CRM integrations (HubSpot, Salesforce) and verify account/domain matching — note the documented sync lag of up to one hour
• Revoke Podium API tokens and OAuth credentials to secure your legacy environment
• If using Podium for payments or reviews, confirm those systems remain operational independently

Purge Staging Data

Delete your staging database within 30 days of successful migration completion. If it contains customer PII, treat this as a compliance requirement, not a best practice.

User Training

Podium users are accustomed to a web/mobile inbox for SMS and webchat. Unthread operates primarily in Slack. Plan for:

• Slack workflow training for agents (1–2 hours)
• Ticket type and custom field usage
• SLA and escalation path awareness
• Explanation of migrated data format (embedded timestamps, [Migrated] prefixes, placeholder emails)

Monitor for Data Inconsistencies

Run validation queries daily for the first two weeks post-migration. Watch for:

• Orphaned conversations (no customer linked)
• Missing messages in long conversation threads (compare message counts per conversation against source)
• Incorrect tag assignments
• Duplicate accounts created by parallel processes
• Placeholder emails being treated as real contact information by agents

Best Practices

1. Back up everything. Export Podium's full FTP dataset and store it in a separate archive (S3, GCS) before starting any migration work. This is your rollback insurance.
2. Never mutate the source. Treat Podium data as read-only throughout the migration.
3. Run a test migration first. Create a separate Unthread project for testing. Migrate 500 records, validate, iterate on your transformation logic, then run the full migration.
4. Validate incrementally. Don't wait until the end to check data quality. Validate after each entity type is loaded (Accounts → Customers → Conversations → Messages).
5. Preserve source IDs. Store Podium UIDs in Unthread's metadata field on conversations and customFields on accounts. This creates an audit trail and simplifies debugging.
6. Log everything. Maintain a crosswalk table of Podium_UID → Unthread_ID for every entity type. If a script fails, you need this table to resume exactly where you left off without creating duplicates.
7. Handle rate limits by construction. Build a token bucket or fixed-delay pacer into your script. Reacting to 429 responses with retry logic creates unpredictable throughput. Start at 500ms delay (Podium) and 1s delay (Unthread), then tune.
8. Set a date cutoff. Unless there's a compliance reason, migrate only the last 12–24 months of conversations. Older data rarely justifies the engineering cost.
9. Make creates idempotent. Since Unthread's API is not natively idempotent, implement crosswalk-based idempotency in your loading script. This is the single most important engineering decision for migration reliability.
10. Communicate. Warn your support team that historical tickets will look structurally different — timestamps are embedded in text, conversations are typed as triage, and placeholder emails replace phone numbers for SMS-only contacts.

Sample Data Mapping Table

Making the Right Call

A Podium-to-Unthread migration is a platform architecture change, not a data copy. You are moving from an SMS-and-reviews platform designed for local businesses to a Slack-native ticketing system designed for B2B and internal support.

If your team has fewer than 1,000 conversations and a developer available for a week, the API approach outlined above is viable. For datasets above 10K conversations, multi-location organizations, or teams that cannot dedicate 80–160 engineer-hours, a managed service will get you there faster and with fewer data integrity risks.

If you only need active contacts and a clean cutover, keep it simple: export contacts, rebuild workflow settings in Unthread, and don't pretend you migrated history when you didn't. If you need real history, the safest pattern is API extraction, immediate attachment capture, staged transformation with crosswalk-based idempotency, closed-conversation import as private notes, then a short webhook delta window before final cutover. If reviews, campaigns, or payments still matter to the business, leave them in Podium or another system of record.

For more migration planning resources, see our Help Desk Data Migration Checklist and How We Run Migrations at ClonePartner.