Migrate from Web+Center to Zendesk

Web+Center Incidents map directly to Zendesk tickets. The Incident status, priority, category, and assigned technician fields map to Zendesk ticket Status, Priority, Tags (from Category), and Assignee. Custom Incident fields extend to Zendesk custom ticket fields created during the schema phase. Conversation threads from Web+Center internal notes and customer replies migrate to Zendesk ticket comments with public/internal visibility preserved. Creation timestamp migrates as-is to preserve the original SLA calculation base date.

Web+Center Customer records map to Zendesk end-user accounts. Email address is the primary lookup key. We map Customer name, phone, and portal preferences to Zendesk user name, phone, and locale. If a Customer record has no email address, we create the Zendesk user with a generated placeholder and flag it for the customer's admin to update before go-live. Customer portal password hashes cannot migrate due to security constraints; users must reset passwords post-migration.

Web+Center Companies map to Zendesk Organizations. The Company-to-Customer linkage migrates as Zendesk organization membership so that tickets submitted by linked Customers display the correct organization in the Zendesk Agent Workspace. If the destination has multiple organization records that should be merged, we document the merge candidates during scoping and apply the consolidation before ticket import so that the organization lookup is satisfied.

Web+Center Asset records map to Zendesk Assets (available on Zendesk Suite Enterprise and with the Asset Management add-on on other tiers). Serial numbers, purchase dates, assignment status, and custom asset fields migrate to Zendesk Asset custom fields. Asset-to-Customer assignment links migrate as Zendesk Asset user assignments. Note that Asset Management is not included in Zendesk's entry-level Support Team plan; we confirm the destination plan includes asset tracking during scoping.

Web+Center categories and subcategories are lookup table values that do not have a direct Zendesk equivalent. We map top-level categories to Zendesk tags and use subcategories as a second tag layer (category::subcategory format) for teams that need the full hierarchy. Alternatively, if the customer prefers dropdown behavior, we create a custom ticket field of type dropdown with the category values as options. The customer chooses the strategy during scoping.

Web+Center KB articles use a proprietary content format that we extract as raw HTML. We convert the HTML to Zendesk Guide article format and import via the Zendesk Help Center API. Formatting may require post-migration review because Web+Center's content markup does not always map cleanly to Zendesk's article HTML schema. Images embedded in Web+Center articles are extracted from the filesystem and re-uploaded to Zendesk's article attachment storage. The Help Center must be active in Zendesk before article import begins.

Web+Center administrators can define arbitrary custom fields on Incidents, and the schema varies per deployment. We inventory all custom Incident fields during discovery, map each to a Zendesk custom ticket field of equivalent type (text, number, date, dropdown, checkbox, or multi-select), and create the destination fields before ticket import. Multi-select picklist values in Web+Center map to Zendesk multi-select custom fields. If a custom field type has no Zendesk equivalent (e.g., a relational lookup to a non-ticket object), we discuss alternatives like tag approximation or text field storage.

Web+Center stores ticket attachments on the server filesystem with references in the database. We resolve each attachment path, extract the binary content, and upload it to Zendesk via the ticket comments API. Zendesk enforces a 20 MB per-file attachment limit; files exceeding this are flagged and reported to the customer's admin for manual handling. We run a pre-migration path validation step to identify broken attachment references (files deleted or moved without database update) and surface the orphan list before the migration window opens.

Web+Center maintains its own agent and administrator directory. We export agent records and map them to Zendesk agent accounts by email match. If a Zendesk agent account does not exist for a Web+Center agent, we place the mapping in a reconciliation queue for the customer's Zendesk admin to provision the account before ticket import resumes. Passwords cannot migrate; we flag the provisioning step as a prerequisite before production migration begins.

Web+Center calculates SLA breach timestamps based on priority level and configured business hours. These computed timers cannot be extracted as static values and do not map to Zendesk's SLA Policy model, which recalculates from import time. We preserve the ticket creation timestamp and original priority so Zendesk can recompute SLA deadlines using its own SLA Policy rules. The customer's Zendesk admin must configure SLA Policies in Zendesk that match the original Web+Center SLA thresholds before go-live.