Migrate from Atera to Gorgias

Atera Tickets map to Gorgias Tickets with the core fields preserved: subject, status, priority, customer association, assignee (technician), created date, and updated date. We resolve Atera's technician assignment to a Gorgias agent by email match. Tickets with no assigned technician (a common Atera gotcha for unassigned rows) are remapped to a nominated fallback agent during pre-flight validation. Tags on tickets carry through as string values and apply directly in Gorgias. Atera's ticket notes migrate as Gorgias ticket message threads, with the oldest message preserving the original created timestamp.

Atera Customer records represent the MSP client organisation or internal IT department. We map company name, domain, primary contact email, and billing address to Gorgias Customer fields. The Customer record must import before any linked Contacts so that the association is satisfied at insert time. Duplicate Customer names are flagged during pre-flight; the customer's admin chooses whether to merge or preserve as separate records in Gorgias.

Atera Contacts tied to a Customer account migrate to Gorgias Customer records with name, email, phone, and role preserved. The Contact-to-Customer association maps to the Gorgias Customer object, which supports both company-level and person-level records. We detect contacts with no parent Customer and assign them to a fallback Customer record nominated by the admin during discovery.

Atera technician records map to Gorgias agents by email address. We handle the technician license gating constraint documented in Atera's own migration article: if the CSV row count exceeds available seats, we coordinate a pre-scheduled disable/enable cycle with the customer's admin to free license slots sequentially. Agent role permissions (admin, technician, viewer) map to Gorgias Agent roles. Superpower-tier API rate limits do not apply because Atera's export is CSV-based on all non-Enterprise tiers.

Tags on Tickets and Customers are simple string values in Atera. We carry them through as-is and apply them to the corresponding destination records. No value transformation is required. Tags are applied during the ticket and customer import phases using Gorgias's tag API endpoint.

Atera allows custom fields on Tickets, Customers, Contacts, Contracts, SLA Policies, Agents, and Generic forms. We detect the full custom field schema during discovery, generate the corresponding Gorgias custom fields via the POST /api/custom-fields endpoint (supported for Ticket and Customer object types), and map values during the import phase. Atera field types (Text, Number, Date, Checkbox, Dropdown) map to Gorgias managed types (text, number, boolean) and definition objects. Role-based field visibility restrictions in Atera do not have a Gorgias equivalent and are documented for admin review.

Atera's SLA policies define response time and resolution time thresholds by priority level. Gorgias has SLA rules but uses a different data model: SLAs are attached to channels and apply based on conditions rather than inheriting from a named policy object. We map Atera's SLA name and thresholds to Gorgias SLA rules created per-channel (email, chat, social) and document the original Atera SLA-to-ticket assignments for the admin to reattach post-migration. This is a rebuild item, not a direct data migration.

Atera supports hourly, fixed-term, retainer, and project-based contract types with custom rates per customer. Gorgias has no contract billing object; billing is managed outside the helpdesk or through the connected e-commerce platform. We export contract records as a structured CSV inventory (contract type, rate, billing period, customer association) that the customer's admin uses to reconfigure billing in their accounting or e-commerce platform post-migration. This is a documentation deliverable, not a data import.

Atera KB articles with title, body text, category assignment, and attachment links migrate to Gorgias Help Center articles. HTML content in Atera KB bodies may require sanitisation before insertion into Gorgias, which uses a different HTML sanitisation model. We flag articles with complex HTML, embedded iframes, or external asset links during pre-flight for manual review before the KB import phase runs.

Atera's RMM layer tracks devices (workstations, servers, network hardware) with hardware specs, software inventory, and health status. Gorgias has no device or RMM layer; this is an e-commerce customer service platform where order data is the primary context object. Device records do not migrate. We deliver a CSV export of Atera device data (name, type, customer association, health status, last seen) as a documentation deliverable for the customer's admin to use if they deploy a separate RMM tool post-migration.

Atera billable time logged against tickets feeds PSA billing. Gorgias has no billing or timesheet object. Billable hour entries, rates, and totals export as a structured CSV that the customer's admin reconciles with their accounting platform (QuickBooks, Xero) post-migration. We do not import time entries into Gorgias as they have no destination object. Integration credentials for QuickBooks and Xero are platform-bound OAuth tokens that cannot transfer and are documented for reconfiguration.

Integration credentials and OAuth tokens are platform-bound and cannot be transferred between Atera and Gorgias. We document every active Atera integration endpoint, trigger, and configuration during discovery as a written inventory. The customer's admin reauthenticates each integration in Gorgias post-migration. Office 365 and Google Calendar email/calendar sync must be re-established in Gorgias's channel and integration settings.