How LawnGuru Moved More Than 200,000 Support Conversations from Zendesk to Front

TL;DR

Customer: LawnGuru (On-demand marketplace for lawn care and snow removal, Ann Arbor, Michigan. Founded 2014, serving metro Detroit, Atlanta, Cleveland, Chicago, Houston, Philadelphia and Washington DC.)

The Move: Zendesk to Front.

The Scope: More than 200,000 tickets with their full conversation history, more than 100,000 contacts, fewer than 10 ticket fields and more than 50 macros — plus requester, assignee, inbox and status information on every conversation.

The Roadblock: At this volume, the migration is only useful if the team can find and trust individual conversations afterwards. Front also handles imported status differently than expected: some conversations arrived open even though the source Zendesk ticket was solved, which would have left the team with a badly inflated open queue on day one.

The Outcome: The support history live in Front with a reconciled status state, a per-ticket mapping report connecting every Zendesk ticket ID to its Front conversation, and a final delta pass closing the gap before go-live.

By the Numbers

• Tickets migrated: more than 200,000
• Contacts migrated: more than 100,000
• Macros migrated: more than 50
• Ticket fields mapped: fewer than 10
• Tickets in the review sample: fewer than 100
• Tickets added or updated in the final delta: fewer than 15,000

The Challenge: A Large Archive, and a Team That Needed to Find It Again

LawnGuru runs an on-demand marketplace for outdoor home services. Founded in Ann Arbor in 2014 by two friends who had built a lawn and landscape business together since high school, the platform connects homeowners with local providers for mowing and snow removal within hours of a request, across metro Detroit, Atlanta, Cleveland, Chicago, Houston, Philadelphia and Washington DC.

Support volume at a marketplace like that arrives in bursts. Both sides of every job — the homeowner and the provider — can raise an issue, and demand peaks twice a year with the seasons. That history added up to more than 200,000 Zendesk tickets, and all of it had to move to Front.

The requirement was not simply that the tickets arrive. It was that the team could still work with them afterwards:

• Complete conversations. Every message in a ticket, not just the first and last, with the customer context attached.
• Working assignments. Requester, assignee, inbox and status preserved and mapped so the migrated history matched how the team actually operates in Front.
• The configuration too. Fewer than 10 ticket fields and more than 50 macros, so agents were not rebuilding their daily workflow by hand alongside a platform change.
• A traceable reference. A clear connection between each Zendesk ticket and the Front conversation it became, so any specific case could be located and checked.
• Nothing lost at the seam. A final delta sync capturing tickets created and updated after the initial extraction, right up to go-live.

The ClonePartner Solution: Sample First, Map Everything, Then Reconcile

A review sample before the full run. Fewer than 100 tickets were migrated first for Skye and Abbey Dombrowski's team to review. At this volume, the sample is not a technical dry run — it is the only realistic opportunity to inspect individual conversations closely before the scale makes that impractical. LawnGuru used it to verify conversation messages, requester details, assignee mapping, inbox mapping, ticket status, and how the whole thing actually presented in Front. Only after that review did the full scope proceed.

Configuration alongside data. Alongside the tickets and more than 100,000 contacts, fewer than 10 ticket fields and more than 50 macros were carried across. Migrating history without the fields and canned responses that surround it produces a searchable archive rather than a working helpdesk — the team would have had their tickets and none of the tooling they use to answer them.

A mapping report with one row per ticket. Every migrated ticket was written to a CSV carrying its Zendesk ticket ID, subject, creation date, Zendesk status, and the Front conversation reference it became. Not a summary, not a sample: a row for every ticket. That report is what let LawnGuru spot-check any specific case by searching Front on the conversation reference, the subject or the requester, then validating the messages, assignment, inbox and status against the source.

Reconciling Status After Import

Validation after the initial run turned up a Front behaviour worth planning for on any migration into it.

Some migrated conversations sat open in Front even though the corresponding Zendesk ticket had been marked solved. On a corpus this size, that is not a cosmetic issue. It would have handed the support team an open queue inflated by a large share of conversations that had already been resolved in Zendesk, on their first morning in a new tool — and the natural response to that, clearing it manually, is weeks of work.

A targeted cleanup pass identified the conversations that should have been closed and re-closed them based on their original Zendesk status. The pass was deliberately one-directional: it never reopened a conversation that was already closed in Front. A cleanup that corrects one error while introducing its mirror image is not a cleanup.

Delta and Final State

A final delta sync ran before go-live, retrieving tickets created after the initial extraction and capturing the latest updates to tickets already in Front. Fewer than 15,000 tickets were added or updated in that pass.

Because the delta ran against a mapping report that already covered every previously migrated ticket, updates landed on existing conversations rather than creating second copies of tickets that had simply changed since the first pull.

The Results: The Full History, Reconciled and Traceable

LawnGuru went live in Front with its Zendesk support history behind it — more than 200,000 tickets carrying their full conversation threads and customer context, more than 100,000 contacts, and the ticket fields and macros the team uses day to day.

Assignee, inbox and status information came across mapped rather than flattened, with a reconciliation pass ensuring solved Zendesk tickets did not present as open work in Front. The CSV mapping report gives the team a permanent, per-ticket route from any Zendesk ticket ID to its Front conversation, which is what makes a corpus this size auditable rather than merely present.

The support team kept its history without inheriting a queue that needed clearing before they could use it.

What Made This Migration Different

For support teams moving a large ticket archive into Front, three details from this project are worth noting:

• A mapping report is the deliverable, not a by-product. At this volume, "the migration completed" is not something anyone can verify by looking. One row per ticket, connecting source ID to destination reference, is what turns a large archive into something the team can spot-check on any specific case, indefinitely, long after the project ends.

• Check imported status before go-live, not after. Front left some conversations open despite the source ticket being solved. Discovered during validation, that is a scripted cleanup pass. Discovered on the first morning in a new tool, it is an inflated open queue and a support team that no longer trusts what it is looking at.

• A cleanup pass should only move in one direction. Re-closing conversations based on their original Zendesk status is safe. Doing it without an explicit guard against reopening conversations already closed in Front would have traded one wrong state for another — and on a corpus this size, nobody would have caught it manually.