Migrate from Motadata ServiceOps to Zendesk

Motadata Requests map directly to Zendesk Tickets with lifecycle stages (Open, Pending, Resolved, Closed) mapped to Zendesk status values (Open, Pending, Solved, Closed). Request Priority (Low, Medium, High, Critical) maps to Zendesk Priority (Low, Normal, High, Urgent). The Motadata requester_id resolves to the Zendesk end-user record; assignee_id resolves to the Zendesk agent. Custom fields defined on Requests in Motadata are pre-created in Zendesk as ticket fields with matching data types before import. SLA attachments on Requests migrate as SLA Policy references tied to the Zendesk SLA Policy configuration we set up during target preparation.

Motadata Users who create Requests map to Zendesk End Users. We extract user records with email, name, phone, and any custom field values, then import them into Zendesk as end-user records. Duplicate detection uses email as the dedupe key. If a Motadata User has no email, we generate a placeholder and flag the record for the customer's admin to resolve post-migration. LDAP sync metadata on Motadata users does not transfer; Zendesk SSO (SAML or JWT) is configured separately as a setup task.

Motadata Technicians map to Zendesk Agents. We extract technician records with name, email, role, and group membership. In Zendesk, we create agent accounts, assign them to Groups (mapped from Motadata technician groups), and set Roles (Agent, Admin) based on Motadata role metadata. Motadata approval authority and approval group assignments do not have direct Zendesk equivalents; these are documented in the workflow inventory for the admin to configure in Zendesk Flow or as Macro conditions post-migration.

Motadata Assets from the discovery agent and manual CI entry map to Zendesk Asset Management (if the Zendesk suite includes the Asset Management add-on) or to a Zendesk Custom Object. We export all CI fields including CI Type, Serial Number, Location, Assigned User, Warranty Status, and any custom fields. Where Motadata discovery jobs timeout or miss CIs due to the scalability limitation, we supplement with manual CI exports and run a pre-migration validation scan to identify coverage gaps before loading into Zendesk. CI-to-Request linkages migrate as Zendesk ticket field values where the asset is referenced on the originating Request.

Motadata Contracts (tied to vendor/supplier records with warranty metadata, expiry dates, and custom fields) map to a Zendesk Custom Object named Contracts. We pre-create the Custom Object schema in Zendesk with all custom fields matching the Motadata data types before importing any contract records. Vendor associations on Motadata Contracts map to the supplier/vendor records migrated separately. The new Zendesk Custom Objects model (replacing legacy Custom Objects by July 2026) is used for all new schemas we create.

Motadata Suppliers and Vendors store contact information, custom fields, and warranty sync settings. These map to Zendesk Organizations (which serve as vendor and supplier placeholders in Zendesk's data model) with contact details preserved in Organization fields. If the customer uses Organizations for both customer accounts and vendor records in Zendesk, we recommend a tag or custom field on the Organization record to distinguish vendor-type Organizations from customer-type Organizations post-migration.

Motadata SLA definitions (time targets, business hours calendars, escalation rules) map to Zendesk SLA Policies. We export SLA-to-Request attachments and recreate them as Zendesk SLA Policy conditions matched by Priority and Request Type. Business hours calendars from Motadata map to Zendesk Business Hours configurations. Escalation rules from Motadata do not have a direct Zendesk Flow equivalent; we document the escalation logic in the automation inventory for the admin to rebuild as Zendesk triggers and macros. SLA definitions without attached Requests are imported as inactive SLA Policies for the admin to activate and attach post-migration.

Motadata KB Articles (title, content, category, view counts, portal visibility) map to Zendesk Help Center Articles. Article body content migrates in HTML format; Motadata-specific rich-text schema differences are normalized during transformation. Category assignments map to Zendesk Article Section and Section permissions. View counts from Motadata do not have a direct Zendesk equivalent and are preserved in a custom field for reference. Articles with Motadata-specific embedded media (screenshots, attachments) require attachment re-upload to Zendesk Guide; we flag each article with missing attachments for the admin to republish manually.

Motadata Projects include milestones, tasks, and assignments. These map to a Zendesk Custom Object named Projects with custom fields for milestones, status, and task count. Motadata's project schema is lightweight; we document any detailed task dependencies or Gantt-style scheduling as a gap note in the migration report for the admin to rebuild in a project management tool or as Zendesk Tickets with parent-child relationships if the use case warrants.

Motadata Notification templates (trigger conditions, content, and recipient rules) map to Zendesk Macros where the logic is purely content-based. Notification rendering is destination-specific; we export the template content and conditions and deliver them as a written inventory for the admin to rebuild as Zendesk Macros or Zendesk Flow triggers. Automated email notifications from Motadata workflows do not migrate as functional triggers; they require reconstruction in Zendesk Flow using the inventory we provide.

Motadata Workflows define conditional automation sequences for Requests, Changes, Approvals, and Assets. We export every workflow definition including trigger, conditions, steps, and assignee rules as a written inventory document. Workflows do not migrate as functional code because Motadata workflow syntax has no direct Zendesk Flow equivalent. The customer's Zendesk admin or an implementation partner uses the inventory to rebuild workflows in Zendesk Flow. This applies to all workflow types including Change Management and Approval workflows.