--- title: "How to Migrate from Help Scout to Front: Complete Guide" slug: how-to-migrate-from-help-scout-to-front-complete-guide date: 2026-07-14 author: Roopi categories: [Migration Guide, Help Scout, Front] excerpt: "How to migrate from Help Scout to Front without losing internal notes. Covers API limits, object mapping, timelines, and edge cases for lossless migration." tldr: "Migrating Help Scout to Front requires the API, not Front's native importer, which drops internal notes. Budget 5 to 12 business days and plan for Front's 50 to 200 RPM rate limits." canonical: https://clonepartner.com/blog/how-to-migrate-from-help-scout-to-front-complete-guide/ --- # How to Migrate from Help Scout to Front: Complete Guide # How to Migrate from Help Scout to Front: Complete Guide > [!NOTE] > **TL;DR: Help Scout to Front Migration** > > Migrating from Help Scout to Front is a moderate-to-high complexity project because Help Scout's thread-based conversation model must be translated into Front's message-and-comment structure. Front's built-in Help Scout importer is not actively maintained and does not import internal Notes or Comments — that data is permanently lost. Help Scout's UI export only produces reporting CSVs with no message bodies, so every full-fidelity migration path requires the Help Scout Mailbox API v2. A realistic timeline is 5 to 12 business days for 10,000 to 100,000 conversations, including mapping, testing, and cutover. Teams with fewer than 5,000 conversations and no need for internal notes can try the native importer. Everyone else should plan an API-led migration or use a managed service. > > *Written July 2025. Targets Help Scout Mailbox API v2 and Front Core API. Before starting, verify whether Front has added a `created_at` parameter to the [Add comment endpoint](https://dev.frontapp.com/reference/add-comment) or updated its native Help Scout importer — either change would materially simplify the process described here.* ## What Is a Help Scout to Front Migration? A Help Scout to Front migration moves help desk history — conversations, threads, customers, tags, custom fields, and attachments — from Help Scout's mailbox-and-conversation model into Front's inbox-and-message model. It is not a lift-and-shift. Front reconstructs historical conversations by importing individual messages, not by accepting a single ticket object with every event attached. ### Why Teams Move from Help Scout to Front Teams migrate from Help Scout to Front for three platform-specific reasons: 1. **Omnichannel shared inbox architecture.** Front unifies email, SMS, WhatsApp, social media, and live chat into a single inbox with native per-teammate conversation status. Help Scout's strength is email-first support with a Beacon widget, but teams handling high volumes across multiple channels find Front's unified routing model better suited to their workflow. Teams comparing Front against Zendesk, Intercom, or Freshdesk as a Help Scout replacement typically choose Front when cross-functional collaboration (not just support ticketing) is the primary workflow requirement. 2. **Cross-functional collaboration.** Front treats every conversation as a collaborative workspace where sales, ops, and support work side by side using Comments (called "discussions" in the product). Teams outgrowing Help Scout's support-only model move to Front for cross-functional visibility. 3. **Advanced rules and SLA workflows.** Front's rules engine supports conditional branching, time-based escalation, and custom ticket statuses organized into categories (open, waiting, resolved) that go beyond Help Scout's workflow triggers. ### The Architectural Differences That Make This Non-Trivial These structural gaps turn a simple migration into a data translation project: - **Thread types vs. message/comment separation.** Help Scout stores customer replies, agent replies, notes, chat messages, phone logs, line items, and forwards all as Thread objects within a single Conversation. Front separates content into two objects: Messages (external communications) and Comments (internal-only discussions). Every Help Scout thread must be classified and routed to the correct Front object type. - **Mailbox-centric vs. inbox-centric models.** Help Scout organizes around Mailboxes tied to email addresses. Front organizes around Inboxes that can receive messages from any channel type. This is a 1-to-1 map in theory, but Front Inboxes support multi-channel routing that Help Scout Mailboxes do not. - **Status granularity.** Help Scout uses `active`, `pending`, `closed`, and `spam` statuses. Front uses `open` and `archived` at the conversation level, with custom ticket statuses organized into categories (open, waiting, resolved) when ticketing is enabled. If your Help Scout queues rely on `pending`, you need a real waiting status in Front ticketing or a fallback like a custom field or tag. ## Help Scout to Front Object Mapping Before writing any code, map every source object to its destination. This table covers the full scope: | Help Scout Object | Front Object | Notes / Caveats | |---|---|---| | Mailbox | Inbox | 1:1 mapping. Create target Inboxes before migration. | | Conversation | Conversation | Parent container. The conversation is created indirectly when the first historical message is imported. Map `subject`, `status`, `assignee`, `createdAt`. | | Thread (type: customer, message, reply) | Message | External communications. Use the `POST /inboxes/{inbox_id}/imported_messages` endpoint. | | Thread (type: note) | Comment | Internal-only. Use the `POST /conversations/{id}/comments` endpoint. | | Thread (type: lineitem) | Tag or Comment | Assignment/status change logs. No direct Front equivalent. Encode as a timestamped comment or skip. | | Thread (type: chat) | Message | Beacon chat threads. Import as messages. Always fetch full threads from the dedicated endpoint — `embed=threads` truncates chat history. | | Thread (type: forward) | No clean 1:1 | Preserve important context in a comment if needed, or translate only the final state. | | Customer | Contact | Map `email`, `firstName`, `lastName`, `phone`, `company`. Pre-seed contacts to avoid duplicate auto-created records. Front enforces strict uniqueness on email addresses. | | Organization | Account | Help Scout organizations map to Front accounts. Front domains are unique to one account, so shared-domain cases need manual resolution. | | User | Teammate | Map by email address. Pre-provision teammates in Front before import. | | Tag | Tag | 1:1 mapping. Create tags in Front first or let the API auto-create. Front tags are shared across the entire workspace. | | Conversation Custom Field | Conversation Custom Field | Front supports specific data types. Picklist values must be pre-created and match exactly. Front rejects payloads if a value does not match the defined enum. | | Customer/Org Properties | Contact/Account Custom Fields | Help Scout properties support number, text, url, date, and dropdown. Front allows up to 50 custom fields per category. | | Saved Reply | Message Template | No API import. Must be rebuilt manually in Front. | | Workflow | Rule | No API import. Must be rebuilt manually in Front. | | Docs (Knowledge Base) | Knowledge Base | Separate migration. [Front supports Help Scout KB import by URL](https://help.front.com/en/articles/388544) for public docs sites and by CSV with a 3,000-row cap per file. | ### What Has No Clean Equivalent in Front? - **Help Scout Satisfaction Ratings.** Front does not have a native CSAT survey attached to conversations in the same way. Ratings can be stored as tags or custom field values for historical reference. - **Help Scout Beacon configuration.** Front's Chat Widget is a separate product. Beacon settings, proactive messages, and Beacon-specific workflows must be rebuilt from scratch. Chat conversations from Beacon can be imported as Front messages, but they lose their real-time chat formatting and appear as standard message threads. If your Beacon chat volume is significant, plan for agent retraining on Front's Chat Widget behavior (e.g., Front Chat conversations are assigned to individual teammates rather than queued in a Beacon-style round-robin). - **Lineitem threads.** These log assignment changes, status transitions, and system events in Help Scout. Front does not have a visible audit log per conversation in the UI. Encode these as timestamped comments if they carry operational value, or drop them. ### The Note Timestamp Limitation This is a detail most migration guides miss. Front's public Add comment endpoint accepts `author_id`, `body`, `is_pinned`, and attachments — but **no `created_at` field** ([dev.frontapp.com](https://dev.frontapp.com/reference/add-comment)). You cannot preserve the exact historical timestamp of Help Scout notes as first-class comment metadata through the public API. The standard workaround is to prefix each imported comment body with the original Help Scout timestamp and author name. It is a compromise, but it is the only reliable approach available through the documented endpoint. ## Does Front's Native Help Scout Importer Work? Front offers a built-in Help Scout importer under **Settings > Imports**. It connects via OAuth and pulls Mailboxes, Teammates, Tags, Customers, and Conversations (as messages). [Front itself recommends using migration partners](https://help.front.com/en/articles/2223) — Help Desk Migration or ClonePartner — rather than the native tool. > [!WARNING] > **The Hidden Data Loss: Internal Notes** > > Front's native Help Scout importer does not import Notes or Comments. Front's own documentation confirms this tool is not actively maintained. If your team has years of internal context, escalation notes, or compliance-relevant annotations stored as Help Scout notes, the native importer will silently drop all of it. This is not a bug — it is a known limitation of an unmaintained tool. Front documents a rough speed of about 3,000 Help Scout tickets per hour for the native importer. Speed is irrelevant if years of internal context disappear. Losing internal notes means your agents in Front will see the customer-facing conversation history but will have zero visibility into the internal decisions, escalation reasoning, or contextual notes that drove past resolutions. For regulated industries or high-touch support teams, this is a dealbreaker. Use the native importer only if: - You have fewer than 5,000 conversations - You do not need internal notes in Front - You have no custom fields to preserve - Historical accuracy is not critical For any team where agents rely on past internal notes to do their job, skip the native importer and plan an API-led migration. ## Migration Approach Options | Approach | How It Works | Best For | Complexity | Risk Level | |---|---|---|---|---| | **Front's native importer** | Built-in tool in Front Settings > Imports. Connects via Help Scout OAuth. | Quick look at data, teams that do not need internal notes | Low | High (drops notes, unmaintained) | | **Custom API script** | Read from Help Scout Mailbox API v2, transform, write to Front Core API | Full control, teams with engineering capacity | High | Medium (requires rate limit handling, error recovery, idempotency) | | **Third-party migration tool** | Automated tool with UI-based mapping (e.g., Help Desk Migration) | Mid-size teams wanting a guided process | Medium | Medium (verify note handling and Front threading in a test run before trusting it) | | **Managed migration service** | Expert-led custom scripts, QA, delta sync | Enterprise, complex schemas, zero-downtime requirements | Low (for your team) | Low | ### Which Approach Fits Your Team? - **Fewer than 5,000 conversations, no custom fields, no notes needed:** The native importer will work, but understand the data loss trade-off. - **5,000 to 50,000 conversations, simple schema, engineering team available:** Custom API script. Budget 60 to 100 engineer-hours including testing and error handling. At a fully loaded engineer cost of $100–$150/hour, that is $6,000–$15,000 in internal engineering time. - **50,000+ conversations, custom fields, internal notes required, zero downtime:** Managed migration service. The engineering cost of building rate-limit handling, attachment processing, note-to-comment mapping, delta sync, and validation from scratch typically exceeds the cost of hiring a specialist. Budget 120 to 200 engineer-hours if building in-house ($12,000–$30,000 in engineering time). Managed migration services for this volume typically range from $3,000–$15,000 depending on complexity, custom field count, and attachment volume. CSV is not the answer for conversation history. Help Scout's in-app exports omit conversation thread contents — [the API is the only way](https://docs.helpscout.com/article/466-data-export-options) to get full message bodies. CSV can work for Front contacts, accounts, or knowledge base content, but not for threaded ticket history. ## API Limits and Throughput Planning [For Engineering] Both platforms throttle aggressively. Plan throughput before you start coding. ### Help Scout Extraction The only way to extract full conversation data from Help Scout is through the Mailbox API v2. Help Scout's native export produces reporting CSV/XLSX with no message bodies. Full conversation data requires the API with OAuth and [48-hour access tokens](https://developer.helpscout.com/mailbox-api/overview/authentication/). Read our guide on [how to export data from Help Scout](https://clonepartner.com/blog/blog/how-to-export-data-from-help-scout-methods-api-limits-formats/) for exact endpoint specifications. **Key endpoints:** - `GET /v2/conversations?status=all&mailbox={id}` — list conversations - `GET /v2/conversations/{id}/threads` — get all threads per conversation (do not use `embed=threads`, which [truncates chat threads](https://developer.helpscout.com/mailbox-api/endpoints/conversations/list/)) - `GET /v2/conversations/{id}/custom-fields` — custom field values - `GET /v2/customers` — customer records - `GET /v2/attachments/{id}/data` — download attachment binaries **Rate limits:** | Help Scout Plan | Rate Limit | |---|---| | Standard | 200 requests per minute | | Plus | 400 requests per minute | | Pro | 800 requests per minute | [Write requests (POST, PUT, DELETE, PATCH) count as 2 requests](https://docs.helpscout.com/article/1140-mailbox-api) toward the rate limit. The conversation list endpoint paginates to 25 items per page; other endpoints paginate to 50. Your extraction script must read the HTTP 429 `Retry-After` headers and pause execution. ### Front Load **Key endpoints:** - `POST /inboxes/{inbox_id}/imported_messages` — import historical messages with original timestamps - `POST /conversations/{conversation_id}/comments` — create internal comments (for Help Scout notes) - `POST /contacts` — create contacts - `PATCH /conversations/{conversation_id}` — set tags, assignee, and status **Rate limits:** | Front Plan | Rate Limit | |---|---| | Starter | [50 requests per minute](https://dev.frontapp.com/docs/rate-limiting) | | Professional | 100 requests per minute | | Enterprise | 200 requests per minute | Rate limits are enforced **per-company**, not per-token. There is a burst limit of 5 requests per second per resource type (except exports, which is 1 per second). The `imported_messages` endpoint has an additional Tier 1 rate limit of [1 request per second](https://dev.frontapp.com/docs/rate-limiting). Front offers rate limit add-ons (300 additional calls per minute per add-on) on Professional plans and above. At the time of writing, add-ons are priced per-month and can be activated temporarily for migration windows — contact your Front account manager for current pricing. Requesting a temporary increase before migration is worth the conversation. **Important:** Front's imported message endpoint returns **202 Accepted**, meaning write success and object availability are not the same moment. If your validation script queries Front too soon after a write, it will produce false negatives. Build in a 2–5 second delay before querying newly created resources, or use a polling loop with exponential backoff on the GET. ### Throughput Math On a Front Professional plan (100 RPM), importing a conversation with an average of 4 external messages and 2 internal notes requires approximately 8 API calls: - 1 call to import the first message (creates the conversation) - 3 calls to import remaining messages - 2 calls to add notes as comments - 1 call to update tags, assignee, and status - Plus attachment calls if applicable At 100 RPM, that is roughly 12 conversations per minute, or about 720 per hour. A 50,000 conversation migration takes approximately 69 hours of continuous API time for the Front write phase alone. On the extraction side, a 100,000 conversation mailbox needs at least 4,000 list calls (25 per page) plus 100,000 thread calls — over 104,000 source-side requests. At 200 RPM on the Standard plan, that is roughly 520 minutes before retries or attachment downloads. At 400 RPM on Plus, it is still about 260 minutes. **Large migrations are thread-count problems, not ticket-count problems.** ## Step-by-Step Help Scout to Front Migration Process Follow this exact order of operations. If you change the sequence, you create broken threading or comments that have nowhere to land. ### Step 1: Audit and Pre-Provision - List all Help Scout mailboxes, conversation volumes, note usage, custom fields, tags, and organizations - Create all target Inboxes in Front, mapped from Help Scout Mailboxes - Pre-provision Teammates in Front using the same email addresses as Help Scout Users - For former employees or deactivated Help Scout Users who will not have Front accounts, create a hardcoded mapping table that assigns their conversations to a designated "legacy" teammate or leaves them unassigned - Create all Custom Fields in Front with matching picklist values - Create Tags in Front if you want to control naming conventions - Pre-seed Contacts and Accounts to avoid duplicate auto-creation during import - **Disable any Front Rules that might trigger on imported data** — auto-replies, assignment rules, and SLA timers will fire on imported conversations if left enabled - Tag all pre-existing Front conversations (if any) with a `pre-migration` tag so you can distinguish them from imported data during validation and rollback ### Step 2: Extract from Help Scout Paginate through all conversations using `GET /v2/conversations?status=all`. For each conversation, fetch all threads via the dedicated threads endpoint — do not rely on `embed=threads`, which truncates chat threads. Download all attachments using the attachment data endpoint. Store the entire dataset in a local staging format (JSON or database). Clean HTML bodies to remove malformed tags that Front will reject. ```python # Pseudocode: Extract conversations from Help Scout with exponential backoff import requests import time import random def extract_conversations(mailbox_id, token): conversations = [] page = 1 max_retries = 5 while True: retries = 0 while retries < max_retries: resp = requests.get( f"https://api.helpscout.net/v2/conversations", params={"mailbox": mailbox_id, "status": "all", "page": page}, headers={"Authorization": f"Bearer {token}"} ) if resp.status_code == 429: wait = int(resp.headers.get("Retry-After", 60)) time.sleep(wait) retries += 1 continue elif resp.status_code >= 500: # Exponential backoff with jitter for server errors wait = min(2 ** retries + random.uniform(0, 1), 120) time.sleep(wait) retries += 1 continue break if retries >= max_retries: log_to_dead_letter({"page": page, "mailbox_id": mailbox_id}) page += 1 continue data = resp.json() conversations.extend(data["_embedded"]["conversations"]) if page >= data["page"]["totalPages"]: break page += 1 return conversations def log_to_dead_letter(failed_request): """Log failed requests for manual retry after the main extraction completes.""" with open("dead_letter_queue.jsonl", "a") as f: import json f.write(json.dumps(failed_request) + "\n") ``` ### Step 3: Transform and Map For each Help Scout conversation, build the Front payload: - Classify each thread by type: `customer`, `message`, `reply`, `chat`, `phone` → Front imported message. `note` → Front comment. `lineitem` → comment or skip. - Convert Help Scout `createdAt` (ISO 8601) to Front's Unix timestamp format (seconds) - Map Help Scout status: `active` → `open`, `closed` → `archived`. For `pending`, either map to `archived` or use a custom ticket status if Front ticketing is enabled. - Resolve Help Scout User IDs to Front Teammate IDs by email lookup - Resolve Help Scout Customer emails to Front Contact handles - Separate threads into two arrays: customer-facing messages and internal notes - Sort all threads chronologically (oldest first) > [!TIP] > **Order of Operations** > > Import messages in chronological order (oldest first). The first imported message creates the conversation object in Front. All subsequent messages thread into that conversation using the `conversation_id` returned by the first import call. If you import out of order, threading breaks. ### Step 4: Load into Front For each conversation: 1. Import the first (oldest) customer-facing message via `POST /inboxes/{inbox_id}/imported_messages` — this creates the conversation 2. Capture the returned `conversation_id` 3. Import remaining messages into the same conversation 4. Add internal notes as comments via `POST /conversations/{conversation_id}/comments`, prefixing each comment body with the original Help Scout timestamp and author name (the comment endpoint has no `created_at` field) 5. Update conversation with tags, assignee, and status via `PATCH` Use the `imported_messages` endpoint specifically. The standard `/messages` endpoint overwrites the message date with the current server time. ```python # Pseudocode: Import a historical message into Front with retry logic def import_message(inbox_id, message_data, token, max_retries=5): for attempt in range(max_retries): resp = requests.post( f"https://api2.frontapp.com/inboxes/{inbox_id}/imported_messages", headers={ "Authorization": f"Bearer {token}", "Content-Type": "application/json" }, json={ "sender": {"handle": message_data["from_email"]}, "to": [message_data["to_email"]], "subject": message_data["subject"], "body": message_data["body"], "external_id": message_data["helpscout_thread_id"], "created_at": message_data["unix_timestamp"], "metadata": { "is_inbound": message_data["is_inbound"] } } ) if resp.status_code == 202: return resp # 202 Accepted — object may not be immediately queryable elif resp.status_code == 429: wait = int(resp.headers.get("Retry-After", 60)) time.sleep(wait) elif resp.status_code >= 500: time.sleep(min(2 ** attempt + random.uniform(0, 1), 120)) else: # 4xx error — log to dead letter queue, do not retry log_to_dead_letter({"inbox_id": inbox_id, "data": message_data, "status": resp.status_code, "body": resp.text}) return resp log_to_dead_letter({"inbox_id": inbox_id, "data": message_data, "error": "max_retries_exceeded"}) return None ``` ```python # Pseudocode: Import Help Scout note as Front comment with original timestamp def import_note_as_comment(conversation_id, thread, token): original_ts = thread["createdAt"] original_author = thread["createdBy"]["email"] body = f"[Imported Help Scout note | {original_ts} | {original_author}]\n\n{thread['body']}" resp = requests.post( f"https://api2.frontapp.com/conversations/{conversation_id}/comments", headers={ "Authorization": f"Bearer {token}", "Content-Type": "application/json" }, json={ "author_id": map_teammate(thread["createdBy"]), "body": body } ) return resp ``` ### Step 5: Run Delta Sync If your team continues working in Help Scout during migration, run an incremental export using `modifiedSince` to catch new conversations and updated threads created after the bulk extraction timestamp. Import the delta into Front before cutover. For a deeper cutover pattern, see our guide on [zero-downtime help desk data migration](https://clonepartner.com/blog/blog/zero-downtime-help-desk-data-migration/). ### Step 6: Validate and Go Live After all conversations are loaded, run a reconciliation pass: - Compare conversation counts: Help Scout total (by mailbox) vs. Front total (by inbox) - Sample 5% of conversations and verify thread count, note count, and attachment count - Check that assignee mappings are correct - Verify tags applied correctly - Confirm closed conversations are archived in Front - Verify internal notes appear as Comments - Redirect email forwarding to Front channels - Re-enable Front Rules For a detailed validation framework, see our [Front Migration Checklist](https://clonepartner.com/blog/blog/front-migration-checklist/). ## Rollback Procedure If validation fails or agents report critical data integrity issues post-cutover, execute this rollback plan: 1. **Revert email forwarding** from Front channels back to Help Scout Mailboxes. This is the single most time-sensitive step — do it first to stop new conversations from entering Front. 2. **Reactivate Help Scout** as the primary support tool. If you kept the account active (recommended for 30 days post-cutover), agents can resume work immediately. 3. **Archive imported conversations in Front** by applying a bulk tag (e.g., `migration-rollback`) and archiving by tag. This preserves the imported data without deleting it, in case you need to retry. 4. **Investigate the failure.** Common causes: missing notes, broken threading from out-of-order imports, incorrect assignee mappings, or attachment corruption. 5. **Re-run migration** after fixing the root cause. Because you used `external_id` on every imported message, you can identify which conversations were already imported and skip them or overwrite them. The cost of a rollback is primarily operational disruption (agent confusion, brief gap in response times), not data loss — as long as you kept Help Scout active during the migration window. ## Edge Cases and Known Limitations The failures in Help Scout to Front migrations are predictable. They just get ignored until late in the project. ### Attachments and Inline Images When sending files through the Front API, your request must use `Content-Type: multipart/form-data` ([dev.frontapp.com](https://dev.frontapp.com/reference/import-inbox-message)). The JSON data you would normally send in the request body needs to be split into multiple form fields. Every conversation with attachments requires a different request format than conversations without — your migration script needs two code paths. Front enforces a **25 MB attachment limit**. If a Help Scout thread contains massive inline images encoded as base64 strings, the payload may exceed this limit. Strip the base64 strings and replace them with hosted image URLs. Inline images embedded in Help Scout HTML message bodies reference Help Scout-hosted URLs. After migration, those URLs will break when you decommission Help Scout. Download each inline image during extraction, re-upload it to Front as an attachment, and rewrite the `src` attribute in the HTML body to reference the new Front-hosted URL. ### Merged Conversations Help Scout supports merging conversations. When two conversations are merged, one becomes the primary and the other returns `301 Moved Permanently` when you query the old conversation ID via the API. Your extraction script must follow the merge chain, resolve to the current conversation ID, and import all threads under a single Front conversation. ### Duplicate Contacts Help Scout allows multiple customers to share the same email address in some legacy configurations. Front enforces strict uniqueness on email addresses. Merge duplicate profiles during the transformation phase before loading into Front. Pre-seeding contacts also helps avoid additional duplicates auto-created from message handles during import. ### Duplicate Conversations from Retry Logic If your migration script retries a failed import without using `external_id`, Front will create duplicate conversations. Always set `external_id` to the Help Scout conversation ID or thread ID. This gives you idempotent imports and a clean audit trail for QA. ### Chat Thread Truncation Help Scout's `embed=threads` parameter truncates chat threads. Always pull full thread history from the dedicated `GET /v2/conversations/{id}/threads` endpoint. This is easy to miss if you build your extraction around embedded data. ### Custom Field Type Enforcement Front supports custom fields on conversations, contacts, and accounts (up to 50 per category). Field types must match exactly. Help Scout dropdown fields must be mapped to Front dropdown fields with pre-created options. Free-text fields map directly. Front rejects payloads if a custom field value does not match the defined enum or picklist. ### Deleted and Spam Conversations Help Scout's API does not return deleted conversations. If you need them, you must export before deletion. Spam conversations are accessible via `?status=spam` but are typically excluded from migration. ## Timeline, Phases, and Resourcing [For PMs] | Phase | Duration | Dependencies | |---|---|---| | Discovery and audit | 1 to 2 days | Access to both platforms, stakeholder alignment | | Object mapping and field mapping | 1 to 2 days | Custom field inventory, status mapping decisions | | Script development or tool configuration | 2 to 4 days | API credentials, staging environment | | Test migration (subset) | 1 to 2 days | QA team availability | | Full migration run | 1 to 3 days | Depends on volume and rate limits | | Delta sync and cutover | 1 day | Coordination with support team | | Post-migration validation | 1 to 2 days | Agent UAT, reporting verification | | **Total** | **5 to 12 business days** | | The import itself is rarely the schedule driver. Field mapping decisions, test loads, UAT, and delta sync usually take longer than the raw data transfer. ### Phased vs. Big-Bang vs. Incremental - **Big-bang cutover** works for teams with fewer than 20,000 conversations. Run the full migration over a weekend, validate on Monday, go live. - **Phased by mailbox** works for teams with multiple mailboxes serving different departments. Migrate one mailbox at a time over 2 to 3 weeks. - **Incremental with delta sync** works for high-volume teams that cannot pause operations. Run the bulk migration first, then sync new conversations that arrived in Help Scout during the migration window. This requires tracking the last-synced timestamp and running incremental exports with `modifiedSince`. ### Risk Register | Risk | Likelihood | Mitigation | |---|---|---| | Internal notes dropped by native importer | High (if using native tool) | Use API-based migration with comment mapping | | Rate limit throttling extends timeline | Medium | Request temporary rate limit increase from Front. Implement exponential backoff with jitter. Run over a weekend. | | Attachment download failures (expired URLs) | Low | Download all attachments during extraction phase, verify before load | | Duplicate conversations from retry logic | Medium | Use `external_id` for idempotent imports | | Automations triggering on imported data | High (if not disabled) | Disable all Front Rules before import, re-enable after validation | | Teammate IDs do not match | Medium | Create a hardcoded mapping table for former employees who do not exist in Front | | Status mismatch (pending has no clean equivalent) | Medium | Define the pending-to-archived or pending-to-custom-status mapping before test load | | Migration cost overrun (in-house) | Medium | Set a 100-hour checkpoint — if script development exceeds 100 hours, reassess build-vs-buy | ## What Customers and Agents Notice [For Customer Success] If you run a properly planned migration, customers notice nothing. Help Scout continues receiving and responding to conversations until the cutover moment. Front begins receiving new conversations only after you redirect your email forwarding and channel connections. The key concern is **conversation history continuity**. When a customer writes in after the migration, your agents need the full history of prior interactions — including internal notes. Without those notes, agents lose the context that informed past decisions. That slows resolution times and erodes customer trust. ### Change Management Checklist - Brief your support team on Front's UI differences (per-teammate status, discussions vs. notes, keyboard shortcuts) - Update any public-facing references to your Help Scout Beacon or Docs site - Confirm that email forwarding rules point to Front channels, not Help Scout Mailboxes - Monitor first-week metrics (first response time, resolution time) for regression - Keep your Help Scout account active for at least 30 days after cutover to handle edge cases, verify data integrity, and serve as a rollback option - If Help Scout Docs is in scope, treat it as a parallel project — [Front's knowledge base importer](https://help.front.com/en/articles/388544) supports Help Scout public content by URL and CSV imports capped at 3,000 rows per file ## How to Validate a Help Scout to Front Migration Do not sign off on record counts alone. Reconcile at four levels: conversations, customer-facing threads, internal notes, and attachments. ### Record-Count Reconciliation - Total conversations in Help Scout (by mailbox) vs. total conversations in Front (by inbox) - Total threads per conversation (sample 100+ conversations across different date ranges) - Total contacts in Help Scout vs. total contacts in Front ### Field-Level Checks - Subject line accuracy - Timestamp accuracy (verify that Help Scout ISO 8601 dates match Front Unix timestamps) - Assignee mapping (spot-check 20+ conversations) - Status mapping (verify closed conversations are archived) - Tag mapping (verify all tags transferred) - Custom field values (verify all picklist values match; check for silent rejections in API response logs) ### Sampling Strategy - Pull 50 random conversations from each mailbox - Open each in Front and compare against Help Scout - Verify that internal notes appear as Comments in Front - Download at least 10 attachments and confirm file integrity - Have support leads do UAT on a saved sample set For a comprehensive post-migration testing framework, see our [Help Desk Data Migration QA Checklist](https://clonepartner.com/blog/blog/help-desk-data-migration-qa-checklist/). ## Build In-House or Use a Managed Service Building in-house gives you full control. But the hidden costs add up fast: - **Rate limit engineering.** Both platforms throttle aggressively. Your script needs exponential backoff with jitter, retry queues, dead-letter handling for permanently failed requests, and 429 response handling on both the read and write sides. - **Attachment processing.** Every attachment requires a separate download from Help Scout, format conversion to `multipart/form-data` for Front, and inline image URL rewriting. - **Note-to-comment mapping.** This is the step that native tools skip entirely. Each Help Scout note must be extracted, attributed to the correct user, timestamped in the comment body (since the API has no `created_at` for comments), and written to Front's comment endpoint as a separate API call. - **Delta sync for zero downtime.** If your team keeps working in Help Scout during migration, you need an incremental sync that catches new conversations and threads created after the bulk export. - **Idempotency and rollback.** Without `external_id` tracking and a rollback strategy, a failed migration run means starting over or living with duplicates. **Decision criteria:** | Factor | Build In-House | Managed Service | |---|---|---| | Conversation volume | < 10,000 | > 10,000 | | Internal notes required | Few or none | Extensive | | Custom fields | < 5 fields | 5+ fields with picklists | | Attachment volume | Minimal | Heavy (inline images, large files) | | Engineering availability | Dedicated engineer for 2+ weeks | No dedicated resource | | Channel types | Email only | Email + chat + other | | Budget | $6,000–$15,000 in eng time | $3,000–$15,000 for managed service | | Timeline pressure | Flexible (3+ weeks) | Tight (< 2 weeks) | Build in-house if you have fewer than 10,000 conversations, mostly email, limited note usage, no shared-domain account issues, and an engineer comfortable with queues, retries, idempotency, and UAT ownership. Use a managed service if notes must be preserved, volumes are large, multiple mailboxes or brands are involved, or the cutover cannot disrupt support. The typical in-house effort for a 50,000-conversation migration with notes, attachments, and custom fields is 120 to 200 engineer-hours. ClonePartner has completed over 1,500 data migrations, including hundreds of helpdesk-to-helpdesk moves with full note preservation, attachment handling, and custom field mapping. Front lists ClonePartner directly in its help center as a recommended migration partner for Help Scout imports. > Need to migrate from Help Scout to Front without losing internal notes, attachments, or custom field data? Book a 30-minute call to scope your migration. > > [Talk to us](https://cal.com/clonepartner/meet?duration=30) ## Frequently asked questions ### Can I migrate Help Scout to Front without losing data? Yes, but not with Front's native importer alone. The native importer drops internal notes and is not actively maintained. An API-based migration using the Help Scout Mailbox API v2 and Front's Core API (imported_messages and comments endpoints) can preserve all conversation history, internal notes, tags, custom fields, and attachments. The one compromise is note timestamps — Front's comment endpoint has no created_at field, so exact historical timestamps must be embedded in the comment body. ### How long does a Help Scout to Front migration take? A typical migration of 10,000 to 100,000 conversations takes 5 to 12 business days including discovery, mapping, script development, test migration, full run, delta sync, and validation. The API write phase alone can take 24 to 72 or more hours of continuous processing due to Front's 50 to 200 RPM rate limits. ### What data cannot be migrated from Help Scout to Front? Help Scout Saved Replies, Workflows, Beacon configuration, and satisfaction rating survey responses cannot be migrated via the API and must be rebuilt manually in Front. Lineitem threads (system-generated audit logs) have no direct Front equivalent and are typically encoded as comments or dropped. Help Scout Docs require a separate migration — Front supports KB import by URL or CSV. ### Does Front have a built-in Help Scout import tool? Yes, Front has a native Help Scout importer under Settings then Imports. However, Front states this importer is not actively maintained and recommends using migration partners like Help Desk Migration or ClonePartner instead. The tool does not import internal Notes or Comments. ### How much does a Help Scout to Front migration cost? Front's native importer is free but drops internal notes. Third-party tools like Help Desk Migration charge based on record volume, typically $1,000 to $5,000 for mid-size migrations. Managed migration services range from $3,000 to $15,000 depending on volume and complexity. Building in-house costs 120 to 200 engineer-hours for a mid-size migration with notes, attachments, and custom fields.