Support Continuity During a HubSpot-to-Intercom Migration

Context

FLiiP is a fitness-technology SaaS platform. Gyms and studios run their member relationships through it, which makes the support channel part of the product experience rather than an afterthought: when an owner can’t fix a billing or booking problem, their members feel it the same day. I joined the support team in March 2026, three people including me alongside an engineering team of roughly twelve, handling a queue of roughly two hundred conversations in a typical week, from frontline questions to escalated investigations.

The support stack was built on HubSpot. This case study is about what happened when the operation outgrew it, and about keeping the support channel alive while you replace it.

Problem & stakes

The problems were operational, and they compounded:

• Routing and prioritization were too coarse for how the queue actually behaved; urgent items waited behind routine ones, and triage was manual judgment applied conversation by conversation.
• Automation had a low ceiling. The repetitive front of the queue consumed agent time that escalated investigations needed, and the knowledge content wasn’t structured to absorb those questions before they became tickets.
• Visibility was fragmented and escalation was ad-hoc: conversation history, customer context, and escalation state lived in different places, and handoffs to engineering travelled by copy-paste rather than through a system.

None of this was a crisis on any given day. That was exactly the danger: it was a slow tax on every conversation, invisible in any single interaction and large in aggregate. For a three-person team, capacity spent on tooling friction was capacity taken directly from customers.

Constraints

• The channel could not stop. Support for a live customer base has no maintenance window; whatever changed had to change underneath running traffic.
• In-flight conversations had to survive. Work opened on the old platform had to reach resolution without the customer noticing a seam.
• The team had to keep working. Three people could not stop answering a two-hundred-conversation week to learn a new tool; training had to happen alongside the day job.
• Cost was a live criterion. A platform change is a recurring-cost decision; pricing fit was an explicit evaluation criterion from the start.

The decision

I researched the alternatives before proposing anything. The evaluation, and the recommendation it produced:

Execution

I led the support-side and operational implementation while working closely with the support manager and lead software engineer on the broader technical rollout. The build ran in phases, each aimed at one of the problems above.

Foundation: clean the data, then move it. The legacy dataset held tens of thousands of historical tickets and a large contact dataset, accumulated over years, with all the duplicates, dead records, and inconsistent fields that implies. I cleaned and restructured the legacy customer and knowledge data before anything moved. For migration preparation, I used Dust to help build a script that processed a JSON export of the legacy data. The AI generated the scaffolding. Deciding what the data needed to look like on the other side, and checking that it did, remained human work.

Redesign, not transplant. The new platform was the moment to fix the routing and visibility problems rather than carry them over. I configured Intercom’s inboxes, attributes, routing, automations, priorities, SLAs, and escalation workflows around how the queue actually behaved. Integration design was shared work with the lead software engineer. The support workflow was connected across Intercom, Jira, Slack, and Vitally, so an escalation created engineering visibility with context attached instead of a copy-paste handoff. (Attachments turned out to need their own path; that story is below.)

Automation with a review loop. I configured and tested Intercom Fin against the knowledge base to absorb the repetitive front of the queue. The unglamorous half of that work mattered most: reviewing inaccurate or hallucinated answers and improving the supporting content until the assistant’s answers could be trusted.

Enablement, staged around the rollout. I created the technical documentation, diagrams, screenshots, step-by-step procedures, and Komodo training videos, and ran approximately six training sessions with live Q&A and ongoing guidance. The team trained on Intercom for roughly two weeks while still working the live queue, which was possible only because the rollout was staged rather than a cliff.

What went wrong

Some Intercom-to-Jira escalations failed, and the failure was not always immediately obvious to the agent working the conversation. That made it the worst kind: a handoff that looked sent but never arrived.

I reviewed the Intercom workflow logs and the JSON payload used to create Jira issues. The cause: required attributes could arrive empty or missing, and some fields didn’t match the corresponding Jira schema. Either condition could prevent issue creation. Attachments, separately, lacked a sufficient native synchronization path between the two systems.

The response came in layers. I aligned the relevant fields between Intercom and Jira so payloads matched the schema. I added error handling in the escalation workflow so a failed escalation produced a visible note inside the Intercom conversation. The person who owned the customer relationship now saw the failure where they were already looking. I added a failure notification path so that an escalation could no longer fail without someone seeing it. And I worked with the lead software engineer on a Zapier-based workflow to carry attachments across.

The escalation path came out of this more reliable than it went in. But the failure was found in live-like use rather than designed out beforehand, and that shaped the lessons below.

Customer & stakeholder communication — keeping the channel alive

The cutover ran as a roughly two-week phased rollout in early July 2026, with full cutover landing mid-month. New support work was introduced through Intercom while the previous platform remained available during the transition, so existing work stayed accessible and active conversations could continue throughout. Throughout the window, I monitored SLAs, attribute quality, routing behaviour, usage, visibility, and customer response flow. The cutover completed only after the workflow had been exercised in live use and the team was operating comfortably. HubSpot was retired after the switch.

Engineering felt the change too: escalated work now arrived in Jira carrying its context and surfaced in Slack, so both sides gained visibility they hadn’t had before.

Customers were told what was changing before it changed:

Reconstruction based on the operational workflow; representative, not verbatim.

The safety net was the phasing itself. Because the previous platform remained available while Intercom took on new work, a problem in the new workflow, like the escalation failures described above, showed up as degraded internal routing rather than as lost customer conversations.

Outcomes

Stated at the level the evidence supports. The first outcome answers the project’s central constraint; the other three answer the problems named at the top:

• Continuity held. The rollout was designed so active customer conversations could continue throughout the transition, and there was no known interruption to customer support during the phased migration. No record-by-record audit is claimed; the monitoring during the rollout window is the basis for “no known.”
• Routing matched urgency instead of arrival order. Priorities and SLAs were configured around real queue behaviour and monitored through the rollout. This was the redesign’s most direct answer to the manual-triage tax.
• The repetitive front of the queue began flowing through Fin, with a human review loop catching inaccurate answers and feeding content improvements back, returning agent time to escalated work. No deflection figures are claimed.
• Escalation became a defined, monitored workflow step instead of an ad-hoc handoff. Engineering saw support escalations in Jira and Slack with context attached. After the field-alignment and notification fixes, a failed escalation announced itself instead of disappearing.

What I’d do differently

• Define and validate required fields across both systems before live rollout, and test null, missing, and mismatched attributes deliberately rather than discovering them through production-like use. The escalation failure was findable in advance. It was found late because nothing forced it early.
• Build more automated post-migration validation. Monitoring caught behaviour; scripted checks on field mappings and payload shapes would have caught structure, earlier and more cheaply.
• Start knowledge-base cleanup earlier, including bilingual-content reconciliation, with clearer content ownership before importing into Fin. The AI assistant is only as trustworthy as the content underneath it, and content debt became AI debt the moment Fin went live.
• Pilot critical workflows against a smaller controlled sample first. The phased rollout protected customers well; a deliberate small-sample pilot of the escalation path specifically would have protected the workflow too.

Transferable lessons

• The platform choice mattered less than the continuity design. The load-bearing property of the project was that active conversations always had a home through the transition; the tooling decisions existed to protect that property.
• Migration is the right moment to redesign. Workflows transplanted unchanged carry the old problems into the new platform.
• Fin’s usefulness depended on the content underneath it, not the configuration on top. Enabling the assistant took hours. Making its knowledge base accurate, current, and consistently owned was the real work, and reviewing its wrong answers mattered more than extending its coverage.
• Writing the proposal was support-engineering work. Translating queue friction into a fifteen-minute business case covering features, pricing, workflow fit, and business impact is what turned an observed problem into an approved project.