Helpdesk migration

Migrate from Dynamics 365 Customer Service to Gorgias

Field-level mapping, validation, and rollback between Dynamics 365 Customer Service and Gorgias. We move data and schema; workflows are rebuilt natively in Gorgias.

Dynamics 365 Customer Service logo

Dynamics 365 Customer Service

Source

Gorgias

Destination

Gorgias logo

Compatibility

100%

12 of 12

objects map 1:1 between Dynamics 365 Customer Service and Gorgias.

Complexity

BStandard

Timeline

3-5 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from Dynamics 365 Customer Service to Gorgias is an enterprise-to-ecommerce realignment, not a straightforward record copy. Dynamics 365 stores Cases as Dataverse incident rows with full relational linkage to Accounts, Contacts, Entitlements, SLAs, and Queues. Gorgias uses a flat Ticket object with a required Customer lookup, pre-built channel integrations for Shopify and major ecommerce platforms, and a macro-driven response model rather than configurable SLA KPIs. We translate the Dataverse incident table and its parent lookups into Gorgias Tickets with Customer resolution, map SLA response-time definitions to Gorgias response rules, and carry Knowledge Articles into the Gorgias Help Center with taxonomy flattened to tags. Power Automate flows, Omnichannel conversation transcripts with channel-side assets, and Entitlement contract balances do not migrate as code; we deliver written inventories for the customer's admin to rebuild in Gorgias.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Dynamics 365 Customer Service logo

Dynamics 365 Customer Service

What's pushing teams away

  • Total cost of ownership escalates quickly: Premium sits at $195/user/month with annual increases, and most organisations also pay for Power Platform requests, Dataverse storage, and partner implementation fees on top.
  • The customer service hub UI is cluttered for new agents, the mobile app is feature-limited, and meaningful customisation requires JavaScript and Power Fx skills rather than the click-to-configure experience the marketing implies.
  • Microsoft support quality is reportedly inconsistent — resolution times vary widely by channel and region, which becomes painful when production Cases stall on a platform issue rather than an agent issue.
  • Setup and go-live timelines run long because the platform's breadth (queues, routing rules, entitlements, SLAs, knowledge taxonomy, Copilot prompts, Power Automate flows) requires deliberate configuration rather than out-of-the-box defaults.

Choosing

Gorgias logo

Gorgias

What's pulling them in

  • Shopify-native integrations pull order details, shipment status, and return data directly into the ticket view, eliminating the need for agents to switch between apps.
  • Unlimited user seats mean growing support teams do not trigger billing changes; pricing scales only on billable ticket volume.
  • AI Agent automates responses to high-volume queries like order status and returns, measurably reducing the number of billable tickets each month.
  • Omnichannel inbox consolidates email, live chat, Facebook, Instagram, WhatsApp, SMS, and voice into a single threaded view.
  • SOC 2 Type II certification and GDPR-aligned data handling satisfy enterprise procurement requirements for customer support platforms.

Object mapping

How Dynamics 365 Customer Service objects map to Gorgias

Each row shows how a Dynamics 365 Customer Service object lands in Gorgias, including any object-level transformations, lookup resolution, or schema-design dependencies.

Typical mapping — final map is confirmed during the sample migration step.

Dynamics 365 Customer Service

Contact

maps to

Gorgias

Customer

1:1
Fully supported

Dynamics 365 CE Contact records map to Gorgias Customer objects. Email address serves as the primary dedupe key. We preserve the full name split (first_name, last_name), email, phone, and address fields. Any parent Account linkage in Dynamics 365 is recorded as a tag on the Customer record since Gorgias Customers are not inherently linked to a separate Account object. If the source org uses Contact-level custom fields, we create matching custom fields on the Gorgias Customer object before migration.

Dynamics 365 Customer Service

Account

maps to

Gorgias

Customer (tagged)

1:1
Fully supported

Dynamics 365 Account records map to Gorgias Customers. Since Gorgias does not have a separate Account object, the Account name becomes the Customer's name or company field, and the Account's industry, website, and address fields map to custom fields on the Customer. Cases originally linked to an Account in Dynamics 365 resolve to the Customer record in Gorgias. If the source organisation uses Account-level custom fields, these migrate as Customer custom fields with a naming prefix indicating their original Account scope.

Dynamics 365 Customer Service

Case (Incident)

maps to

Gorgias

Ticket

1:1
Fully supported

Dynamics 365 Case records map to Gorgias Tickets. The Case title (title) maps to Ticket subject, Case status maps to Gorgias Ticket status (open, pending, resolved, closed), Case priority maps to Ticket priority (low, medium, high, urgent), and the created-on and modified-on timestamps preserve. The primary Customer lookup resolves via email match against the migrated Contact/Account Customer record. Channel detection maps the Dynamics 365 Communication Origination (email, phone, chat) to Gorgias channel metadata.

Dynamics 365 Customer Service

Activity: Email, Phone Call, Task, Appointment

maps to

Gorgias

Ticket reply / Ticket note

1:1
Fully supported

Dynamics 365 Activities linked to a Case via regardingobjectid migrate as Ticket replies (for Email and Phone Call) or internal Ticket notes (for Task and Appointment). Each Activity party's email address resolves to the matching Gorgias Customer. The activity timestamp preserves as the ticket reply or note timestamp. Activities that are not linked to a Case are inventoried separately and migrate as standalone Ticket notes or are excluded based on the agreed migration scope.

Dynamics 365 Customer Service

Knowledge Article

maps to

Gorgias

Help Center Article

1:1
Fully supported

Dynamics 365 Knowledge Articles map to Gorgias Help Center articles. Article title and body (rich text) migrate, article status (draft, published, archived) maps to Gorgias publication status, and the article category or topic taxonomy migrates as Gorgias categories and tags. Article versioning is flattened to the most recent published version unless the destination requires version preservation, in which case we create one article per version with a version suffix in the title. Language variants are handled as separate article records with language tags.

Dynamics 365 Customer Service

Queue

maps to

Gorgias

Team

1:1
Fully supported

Dynamics 365 Queues (holding Cases and Activities awaiting assignment) map to Gorgias Teams. Queue members migrate as Team members by email match. Queue-level routing rules and visibility configurations do not have a direct Gorgias equivalent; we document the routing logic for the customer's admin to configure Gorgias team-level permissions and inbox routing manually post-migration. Unified Routing decision tables (Enterprise feature) are excluded from migration entirely.

Dynamics 365 Customer Service

Entitlement and Entitlement Template

maps to

Gorgias

Customer tag + macro

1:1
Fully supported

Dynamics 365 Entitlements (support contracts with allocated hours, case counts, and channel restrictions) do not have a native Gorgias equivalent object. We migrate the Entitlement terms as a custom Customer field (entitlement_type, entitlement_hours_remaining, entitlement_expiry_date) and tag the associated Customer records with the entitlement name. If the customer has active entitlement-based routing or SLA triggers in Dynamics 365, we document these as Gorgias macro triggers and response-time rules for the admin to configure post-migration.

Dynamics 365 Customer Service

SLA (Service Level Agreement)

maps to

Gorgias

Response Time Rules + tag

1:1
Fully supported

Dynamics 365 SLA definitions (first response time, resolution time, business hours, pause conditions, warning thresholds) do not have a direct Gorgias equivalent. We extract the SLA name, applicable entity, and KPI targets (response and resolution in hours or business hours) and document them as a written specification for Gorgias response-time rules. Active SLA instances on open Cases migrate as a tag on the corresponding Gorgias Ticket (sla_tier or support_tier). The customer configures Gorgias response-time rules to match their contracted SLAs post-migration.

Dynamics 365 Customer Service

Custom Dataverse Tables

maps to

Gorgias

Custom Ticket Fields or Customer Fields

1:1
Fully supported

Customers extending the Dynamics 365 data model with custom Dataverse tables and columns migrate to Gorgias custom fields on Ticket or Customer. We inventory the source schema during discovery, map each custom field by name and data type (text, number, date, boolean, option set), create the matching custom fields in Gorgias, and migrate values. Option-set values from Dataverse become Gorgias dropdown options. Lookup relationships across custom tables require careful resolution if both sides of the lookup are being migrated.

Dynamics 365 Customer Service

Attachment (annotation)

maps to

Gorgias

Ticket attachment

1:1
Fully supported

Attachments stored on the Dataverse annotation table (Notes) and linked to Cases migrate as ticket attachments in Gorgias. Files are retrieved from the source, uploaded to Gorgias via the REST API, and linked to the corresponding ticket. Large files are chunked; we respect Gorgias's attachment size limits per the API documentation. Inline images within Note body text are extracted and re-uploaded separately if the destination renders them differently.

Dynamics 365 Customer Service

Omnichannel Conversation (session + message)

maps to

Gorgias

Ticket message thread

1:1
Fully supported

Dynamics 365 Omnichannel session transcripts and message records linked to Cases migrate as the ticket message thread in Gorgias. We export the conversation text, participant, timestamp, and channel type. Channel-specific assets (voice recordings, chat files, social media attachments) that reference external storage are flagged in a separate report for re-linking or re-upload since Gorgias handles attachments natively and may not support all channel-specific file formats.

Dynamics 365 Customer Service

Customer Voice Survey Response

maps to

Gorgias

Ticket tag + note

1:1
Fully supported

Microsoft Customer Voice survey responses linked to Cases migrate as tags on the corresponding Gorgias Ticket with the survey name and a score field if available. Survey definitions (question sets, branching logic, and scoring models) do not migrate; Customer Voice is a Microsoft-specific product. We deliver a written survey inventory so the customer can recreate equivalent satisfaction surveys in Gorgias's native feedback tools or a third-party replacement.

Gotchas + challenges

What specifically takes care here

Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.

Dynamics 365 Customer Service logo

Dynamics 365 Customer Service gotchas

High

Service Protection API limits will throttle bulk migration loads

Medium

OData v4 paging caps reads at 5,000 records per page

High

Power Automate flows do not migrate as data

Medium

Licensing tier gates which capabilities migrate cleanly

Medium

Omnichannel conversation history is fragmented across channels

Gorgias logo

Gorgias gotchas

High

AI Agent adds outcome-based fees on top of billable ticket costs

High

Overage billing for tickets scales nonlinearly

Medium

API rate limits restrict bulk export throughput

Medium

Agent data visibility cannot be restricted by role for GDPR use cases

Low

Knowledge Base translations require separate API calls per locale

Pair-specific challenges

  • SLA configuration does not translate to Gorgias response rules

    Dynamics 365 SLA definitions with business hours calendars, pause conditions, warning thresholds, and KPI rollups have no direct equivalent in Gorgias. Gorgias response-time rules support target windows per priority level but lack pause conditions, business-hour-only counting, and multi-step KPI thresholds. We migrate the SLA name and targets as ticket tags and a written specification document; the customer's admin must configure Gorgias response-time rules to approximate the contracted SLA terms. This is a configuration gap, not a data-loss gap, but it requires admin attention post-migration.

  • Dataverse Service Protection API limits require dedicated throttling

    Dynamics 365 enforces Service Protection API limits of approximately 6,000 requests per user within any rolling 5-minute window. Bulk exports must batch through OData $batch (up to 1,000 operations per request) and each operation still counts toward the per-user budget. We use a dedicated application user with the Bulk Data Loader pattern, throttle reads explicitly, and handle 429 responses using the Retry-After header. Without this handling, large Case exports stall mid-run and produce incomplete datasets.

  • Queue routing logic does not migrate to Gorgias team assignment

    Dynamics 365 Queues hold Cases and Activities with visibility and assignment logic; Unified Routing adds skill-based and capacity-aware dispatch that is Enterprise and Premium only. Gorgias Teams handle group-based assignment but do not support skill profiles, capacity thresholds, or conditional routing based on case attributes. We migrate Queue membership to Team membership, document the routing conditions for each queue, and flag any skill-based or capacity-based routing rules as items for manual Gorgias configuration. Migrations that skip this step lose routing intelligence silently.

  • Entitlement balances and SLA linkage are not data-model equivalents

    Dynamics 365 Entitlements carry remaining hours, case count allocations, channel restrictions, and active SLA instances. Gorgias has no entitlement object. We carry Entitlement name and remaining balance as Customer tags and custom fields, but SLA linkage (which SLA applies to which Case under which Entitlement) does not translate. Cases that were created under a specific Entitlement in Dynamics 365 will not carry that context into Gorgias unless manually tagged. We identify all open Entitlements and their associated Cases during scoping and flag any that require manual intervention.

  • Custom Dataverse tables with lookup dependencies require pre-creation of destination schema

    If the source organisation has extended the Case or Contact table with custom Dataverse tables and lookup columns referencing other custom tables, the destination schema must be created in Gorgias before any data is loaded. Custom fields and their option sets are created via the Gorgias REST API (POST /api/custom-fields) with the managed_type and definition payload matching the source data type. We run schema creation before any migration phase that touches those objects. Skipping this step results in silent field omission during import.

Migration approach

Six steps for a successful Dynamics 365 Customer Service to Gorgias data migration

  1. Discovery and source audit

    We audit the source Dynamics 365 Customer Service organisation across tier (Professional, Enterprise, Premium), enabled features (Unified Routing, Omnichannel, Customer Voice), Dataverse table count, and custom column inventory. We extract record counts for Cases, Contacts, Accounts, Knowledge Articles, Queues, Entitlements, SLAs, Activities, and Omnichannel sessions. We identify the Power Automate flow inventory and flag any that trigger on Case state changes. We run a data quality check for duplicate Contacts (same email on multiple records), open Cases without a Customer lookup, and Knowledge Articles with missing categories. The discovery output is a written migration scope and a feature-gap report for Gorgias configuration.

  2. Schema design and custom field pre-creation

    We design the Gorgias destination schema: creating custom fields on Ticket and Customer objects to hold migrated Dataverse data that does not have a native equivalent (entitlement tags, SLA tier, original Case ID, Dataverse-created-on timestamp). We create team structures matching the Dynamics 365 Queue hierarchy. We configure response-time rules per priority level based on the extracted SLA KPI targets. Any custom Dataverse tables referenced by Cases are mapped to either custom Ticket fields or Customer fields, with option-set values created in Gorgias before data migration begins. Schema creation is validated in a Gorgias staging environment before production.

  3. Customer and Account migration

    We extract all Contacts and Accounts from Dataverse in parallel. Account names resolve as Gorgias Customer name (or company field), and we merge Account-level fields onto the Customer record. For Contacts with a parent Account, we resolve the Account first, then create the Contact as the same Customer record (Gorgias does not distinguish Contact from Account as separate objects). Email is the primary dedupe key. Any Contacts without an email address are flagged for manual handling. Custom fields on Contact and Account migrate to Gorgias Customer custom fields. This phase validates that all Customer records exist before Case migration references them.

  4. Case and Activity migration

    We extract all Cases from the incident table with their parent Customer lookup resolved, status, priority, created-on, modified-on, and description. Cases migrate as Gorgias Tickets with channel metadata inferred from the Dynamics 365 communication origination field. Activities (Email, Phone Call, Task, Appointment) linked to each Case migrate as ticket replies or internal notes with timestamp preserved. We use the Gorgias REST API with batched writes, handle rate-limit 429 responses with exponential backoff, and resolve the Customer lookup by email at migration time. Open Cases migrate first; closed Cases follow in a second pass.

  5. Knowledge Article and macro migration

    Knowledge Articles migrate to Gorgias Help Center articles with category mapping from the Dynamics 365 article category taxonomy. We flatten versioning to the most recent published version unless version preservation is required. Article language variants migrate as separate article records with language tags. Macros are documented from the Gorgias Help Desk Migration integration documentation: standard action macros migrate automatically, but macros with conditional logic, placeholders, or external integrations require manual adjustment post-migration per Gorgias's own migration guidance. We deliver a macro inventory identifying which require admin attention.

  6. Cutover, validation, and automation rebuild handoff

    We freeze Dynamics 365 writes during cutover, run a final delta migration for any Cases or Activities modified during the migration window, then close the Dynamics 365 organisation as the system of record. We validate record counts in Gorgias against the source extraction totals, spot-check 25-50 Tickets for field accuracy and parent linkage, and deliver the Power Automate flow inventory, SLA specification document, Entitlement report, and Omnichannel asset re-link checklist to the customer's admin team. We support a one-week hypercare window for reconciliation issues. We do not rebuild Power Automate flows as Gorgias macros inside the migration scope; that is a separate engagement.

Platform deep dives

Context on both ends of the pair

Dynamics 365 Customer Service logo

Dynamics 365 Customer Service

Source

Strengths

  • Dataverse-backed model gives Cases a real relational schema and a full Web API for migration and BI.
  • Unified Routing handles skill-based, capacity-aware case distribution across Omnichannel without bolt-ons.
  • Native Outlook, Teams, SharePoint, and Power BI integration for organisations already on Microsoft 365.
  • Copilot Service Agent and AI summarisation are bundled with Microsoft 365 Copilot at no incremental cost.
  • Configurable SLAs with business hours, pause conditions, and KPI rollups for tiered support contracts.

Weaknesses

  • Licensing stack adds up fast: per-user, Power Platform requests, Dataverse storage, and capacity entitlements.
  • Customisation beyond out-of-the-box configuration requires JavaScript, Power Fx, and partner expertise.
  • Customer service hub UI is dense and the mobile app trails the web experience in functionality.
  • Microsoft support resolution times are inconsistent; partner support is often necessary for production issues.
  • Implementation timeline runs months, not weeks, due to the platform's configurable surface area.
Gorgias logo

Gorgias

Destination

Strengths

  • Shopify and BigCommerce integrations surface order, return, and shipment data natively inside every ticket.
  • Unlimited agent seats remove per-user licensing friction as support teams grow.
  • AI Agent reduces billable ticket volume through automated resolution of high-frequency queries.
  • SOC 2 Type II certified with GDPR-aligned data handling for enterprise procurement readiness.
  • Omnichannel inbox aggregates email, live chat, Facebook, Instagram, WhatsApp, SMS, and voice into a single threaded view.

Weaknesses

  • Ticket-volume pricing with overage fees creates unpredictable monthly costs during seasonal traffic spikes.
  • Custom reporting is shallow; raw event-level data export for BI tooling is not natively supported.
  • Knowledge Base, Macros, and Rules lack simple export tooling, making competitive migrations complex.
  • GDPR compliance limitations mean customer data cannot be hidden from agents by role, blocking use by teams with freelance staff.
  • Performance and glitch reports emerge in G2 reviews at higher ticket volumes.

Complexity grading

How hard is this migration?

Standard Helpdesk migration. 3 of 7 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Dynamics 365 Customer Service and Gorgias.

  • Object compatibility

    C

    3 of 7 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    7-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    Dynamics 365 Customer Service: Service Protection API limits — roughly 6,000 requests per user per rolling 5-minute window per web server; 429 responses include Retry-After header.

  • Data volume sensitivity

    A

    Dynamics 365 Customer Service exposes a bulk API — large-volume migrations stream efficiently.

Estimator

Estimate your Dynamics 365 Customer Service to Gorgias migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Dynamics 365 Customer Service to Gorgias data migrations

Answers to the questions buyers ask most during Dynamics 365 Customer Service to Gorgias migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your Dynamics 365 Customer Service to Gorgias migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Straightforward migrations under 20,000 Cases and 5,000 Knowledge Articles with no custom Dataverse tables land between three and five weeks. Migrations with custom tables, active Entitlement records, large activity histories (over 300,000 records), or Omnichannel transcript preservation move to eight to twelve weeks because of parent-record lookup resolution, SLA rule translation, and queue-to-team mapping complexity. Timeline is also affected by the customer's data quality: duplicate Contact records, orphaned Cases (no Customer lookup), and unclean Knowledge Article taxonomy all add reconciliation time during discovery.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Dynamics 365 Customer Service.
Land in Gorgias, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day