Migrate from Motadata ServiceOps to Intercom

Motadata Requests map directly to Intercom Tickets. We extract all lifecycle stages (Open, Pending, Resolved, Closed), Priority (mapped to Intercom Priority: low, medium, high, urgent), Impact, Category, and custom fields. Request description and internal notes migrate as Ticket body and internal notes. The requester email resolves to an Intercom Contact record; if no Contact exists, we create one during migration. Resolved and Closed timestamps preserve as Ticket updated_at. Open tickets reconcile against Intercom's open/conversation state after migration.

Motadata Users (requesters in the self-service portal) map to Intercom Contacts by email as the dedupe key. We extract display name, email, phone, department, and any custom fields defined on the User form. Contacts created during migration carry a custom attribute motadata_original_id for reconciliation. Users who are also Technicians get a dual mapping: Contact for customer-facing records and Teammate for the Intercom admin workspace.

Motadata Technicians (support staff with group memberships) map to Intercom Teammates and Admins. Role assignments (Tier 1 support, Tier 2 support, Approver) map to Intercom team membership and admin-level access. We extract technician group assignments and preserve them in a custom attribute on the Teammate record. LDAP sync metadata from Motadata does not migrate; the customer's Intercom admin provisions SSO or manual Teammate accounts post-migration.

Motadata KB Articles migrate to Intercom Articles within Collections. We export article title, body content (with rich-text conversion to Intercom's Article format), category assignments, author, and view counts. View counts migrate as a custom attribute because Intercom Articles do not expose a native view counter. Articles assigned to Motadata categories map to Intercom Collections or Sections; we create the collection hierarchy during migration to match the source structure.

Motadata Assets (Configuration Items with CI type, serial number, location, assigned user, warranty metadata) have no native Intercom equivalent. We assess three paths during scoping: (1) drop all Assets if the customer uses a separate CMDB; (2) create a Custom Object named Asset with CI-type, serial, location, assigned contact (lookup), warranty expiry, and contract (lookup) attributes; or (3) export Assets to a reference CSV held in the customer's shared drive. The choice depends on whether the customer needs asset context visible inside Intercom conversations. Auto-discovery gaps from Motadata's discovery agent are flagged and supplemented with manual CI exports before migration.

Motadata Contracts (tied to vendors, with warranty sync settings and custom fields) have no native Intercom object. If the customer elects to carry forward contract data, we create a Custom Object named Contract with vendor name, contract type, start date, end date, renewal alert date, and custom fields. Supplier records from Motadata map to a separate Vendor custom object with contact information. If the customer manages contracts in a dedicated CLM tool, we export a reference CSV instead of building Custom Objects.

Motadata SLA definitions (time targets, business hours calendars, escalation rules attached to Requests by priority or category) have no native Intercom equivalent on Starter or Pro plans. On Intercom Advanced ($99/user), SLA limits are available but without business hours calendars or multi-tier escalation chains. We assess during scoping whether to (1) document SLAs as a reference sheet for the admin to manage manually, (2) create a Custom Object named SLA with target hours and priority mapping, or (3) rebuild SLA logic using Intercom Rules and Fin workflows post-migration.

Motadata Suppliers store vendor contact information, warranty sync settings, and custom fields. We map these to an Intercom Custom Object named Vendor with name, contact email, contact phone, contract reference (lookup to Contract), and notes. If the customer does not need vendor data inside Intercom, we export a reference CSV. Supplier associations on migrated Assets (Contract linking to CI) require the Vendor and Contract custom objects to be created before Asset migration.

Motadata Project records (milestones, tasks, assignments) represent a lightweight ITSM project schema. Intercom has no native project object. We assess whether Motadata Projects are ITSM Change records (which map to Intercom Tickets with a project identifier tag) or genuine project management records (which do not migrate). Project task dependencies and milestone relationships do not carry forward; the customer receives a CSV export of project records for reference in an external PM tool.

Motadata Notification templates (automated alerts for request updates, SLA breaches, approvals) export as template content and rule conditions. Since Intercom renders notifications differently and supports Macros and Articles as response templates, we extract Motadata template bodies as reference text for the customer's admin to republish as Intercom Macros. Template-to-request association rules (trigger conditions) are documented in a separate inventory spreadsheet and rebuilt in Intercom Rules or Fin workflows post-migration.