Migrate from Web+Center to Gorgias

Web+Center Incidents map directly to Gorgias Tickets. We extract the full Incident record including status, priority, category, assignee, creation timestamp, last-modified timestamp, and resolution notes. Conversation threads (customer messages and agent replies) migrate as Ticket messages in Gorgias with the original sender preserved. Priority and status values from Web+Center map to Gorgias Ticket priority and status fields, with IT-specific status values (e.g., pending hardware, awaiting vendor) converted to Ticket tags if no direct equivalent exists. We preserve the Incident creation timestamp so Gorgias SLA rules recalculate deadlines from that anchor.

Web+Center Customer records map to Gorgias Customer objects, preserving email address, phone number, name, and any portal preferences. The Customer-to-Company linkage from Web+Center is preserved by resolving the Company reference to the corresponding Gorgias Customer record. Customer IDs are not portable between platforms; we use email address as the dedupe key during import. If a Customer in Web+Center has multiple associated Companies, we create the first Company as the primary on the Gorgias Customer and note the additional linkages for manual follow-up.

Web+Center Company records carry company name, address, domain, and industry data. Gorgias does not have a separate Company object; company data lives on the Customer record. We map Web+Center Company fields to the primary Customer's company information fields. If a Web+Center Company has multiple associated Customers, all of those Customers point to the same merged company data on the Gorgias side. Multi-company parent-subsidiary hierarchies in Web+Center are flattened to a single company entry per Customer record, with the hierarchy relationship noted for manual reconstruction if needed.

Web+Center agents and administrators map to Gorgias Users. We match by email address. Any Web+Center agent without an email match in the destination is held in a reconciliation queue for the customer's admin to provision before migration resumes. Password hashes from Web+Center cannot migrate for security reasons; agents reset passwords at first login. Agent role (admin vs. regular agent) maps to Gorgias User permissions level.

Web+Center KB articles migrate to Gorgias Help Center articles. We extract article title, body content, category assignment, and any internal notes. HTML formatting in Web+Center articles may require post-migration cleanup because Gorgias uses a different content renderer. Article attachments migrate as file uploads to the Help Center article. If the customer uses multi-language KB content, we preserve language metadata and advise on rebuilding language versions in Gorgias.

Web+Center stores Categories, Subcategories, and Priority levels as separate lookup tables. Gorgias has no native category hierarchy for tickets; we map these to Tags using the pattern 'Category: Subcategory' for compound values. Priority levels (e.g., Critical, High, Medium, Low) map to Ticket priority in Gorgias with any IT-specific priority values converted to Tags. We inventory all active and inactive lookup table values during discovery and present the full mapping for customer sign-off before migration.

Gorgias has no native Asset or CMDB object. Web+Center Assets (hardware inventory, software licenses, serial numbers, purchase dates, assignments) require a design decision during scoping: either create a custom object in Gorgias (requires Enterprise plan or custom object add-on) or map key asset fields to Tags on the related Customer or Ticket. We recommend the custom object approach for IT departments that rely on asset tracking; we define the schema, fields, and lookup relationships during the schema design phase. Asset attachment files (e.g., warranty PDFs, photos) migrate as Ticket attachments linked to the associated asset record.

Web+Center custom Incident fields (e.g., building location, device type, service request type) map to Gorgias Ticket custom fields via the Gorgias API endpoint POST /api/custom-fields with object_type = 'Ticket'. Gorgias custom fields support boolean, number, and text types only. Multi-select picklists, date pickers, or IT-specific field types from Web+Center that have no Gorgias equivalent are converted to text fields or Tags. We inventory all custom Incident fields per deployment during discovery, present type-mapping recommendations, and apply them before Ticket migration begins.

Web+Center ticket attachments are stored as files on the server filesystem with path references in the database. We resolve each file path, extract the binary content, and upload it to Gorgias as a Ticket attachment with the original filename and MIME type preserved. We run a pre-migration path validation step against the Web+Center attachment folder to identify and report any broken file references before migration opens. Orphaned attachments (files referenced in the database but missing from the filesystem) are logged and skipped.

Web+Center SLA timers are calculated by the source application based on Incident priority and configured business hours. This state cannot be ported directly. We preserve the Incident creation timestamp, last-modified timestamp, and priority so that Gorgias SLA rules can recalculate deadlines from the original creation date. Customers should review and configure their Gorgias SLA policies before go-live to match the business-hour rules that were in place in Web+Center.

Web+Center stores customer portal preferences including language, timezone, and notification settings. These migrate as customer-level attributes in Gorgias where applicable. Timezone and language preferences map to the Customer record's locale fields. Email notification preferences migrate to HasOptedOutOfEmail or subscription settings as appropriate.

Web+Center maintains lookup tables for values that vary by deployment (e.g., department codes, cost centers, hardware types, vendor names). These do not map to a native Gorgias object type and are handled as Tags on the relevant Ticket. We extract the full active and inactive value sets during discovery, present them as a Tag taxonomy for the customer's review, and apply them during migration. Inactive lookup values are migrated as Tags with an 'inactive' prefix so the customer's admin can suppress them from active views post-migration.