SysAid to ServiceNow migration requires splitting unified Service Records into separate ITSM tables while respecting API limits and semaphore queues. Expect 3 to 6 weeks.
There is no native migration path from SysAid to ServiceNow. The fundamental data model challenge is that SysAid stores Incidents, Requests, Changes, and Problems in a single unified Service Record entity, while ServiceNow requires each type in its own table (incident, sc_request/sc_req_item, change_request, problem). Custom work is required to classify and split every Service Record, map SysAid's flat CI relationships to ServiceNow's hierarchical CMDB class inheritance model, rebuild reference field crosswalks (SysAid IDs to ServiceNow sys_ids), and manually recreate workflow automations, templates, and custom field schemas that have no automated conversion path.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Quick answer
SysAid stores Incidents, Requests, Changes, and Problems in a single Service Record entity, while ServiceNow requires each type in its own table. Workflow rules, custom fields, and CMDB relationships do not transfer 1-to-1. Teams with fewer than 10,000 records and no CMDB data can manage a CSV-based migration in-house. Anything above that, or with compliance requirements, benefits from a managed migration service. The biggest design risk is routing SysAid Requests to the wrong ServiceNow table and then breaking assignee, CI, and fulfillment relationships.
SysAid's API does not support bulk export of attachments in a single call
Each attachment must be downloaded individually. For a dataset with 50,000 attachments, this alone consumes 50,000 API requests — roughly 250 minutes (4+ hours) of extraction time at the rate limit ceiling. Test attachment export on day 1 and factor this into your timeline.
Do not load attachments before the parent ticket mapping is final
Reattaching thousands of files by hand is the kind of cleanup that turns a two-week project into a two-month one.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Scope the service model, not just the ticket table.
Objective Agreed scope across incidents, changes, problems, requests, CMDB and knowledge, with the CAB bought in.
Keep these open
-
Inventory every record type in SysAid
Count incidents, service requests, changes, problems, releases, knowledge articles and CI records. ITSM migrations fail on scope more than technique: the CMDB and the request catalogue are usually far larger and more entangled than the incident table everyone focuses on.
Data Profiler Get real record counts instead of estimating from memory -
Document the CMDB and its relationships
Map CI classes, attributes and — critically — the relationships between them. CI relationships carry your impact analysis, and they are the hardest thing to migrate faithfully because ServiceNow almost certainly models them differently.
CI relationships rarely map one-to-one between ITSM tools. Losing them silently breaks impact analysis and change risk scoring.
-
Capture SLAs, OLAs and their calculation rules
Record every SLA target with its business calendar, pause conditions and escalation path. The rules matter more than the numbers: an SLA that counts pending time differently in ServiceNow will report different compliance on identical data.
-
Review the request catalogue and its fulfilment workflows
Each catalogue item is a form plus an approval chain plus a fulfilment workflow. These are rebuilt, not migrated, and they are usually the longest lead-time item in the whole project.
COI & ROI Calculator Build the 36-month business case you will need for sign-off -
Take the migration through change management
The migration is itself a major change and needs CAB approval, a risk assessment and a documented rollback plan. Start this early — CAB cycles are measured in weeks and will otherwise set your go-live date for you.
Helpdesk Migration Planner Turn ticket volume into a dated SysAid → ServiceNow timeline -
Build the business case and set the window
Model licence delta, implementation effort and the operational risk of running degraded. Choose a window that avoids change freezes, month-end and any regulatory reporting deadline.
Helpdesk Evaluator Sanity-check that ServiceNow is the right target before you commit
SysAid → ServiceNow specifics
- Workflow complexity limits
- SysAid's workflow automation is template-driven. ServiceNow's Flow Designer and Business Rules engine supports multi-step, conditional, approval-chain workflows natively, including parallel approval paths, SLA-triggered escalations, and cross-table orchestration.
- CMDB depth
- SysAid's CMDB supports CI types, sub-types, and relation types with up to 250 customizable fields per CI type. ServiceNow's CMDB (built on the Common Service Data Model) supports hundreds of CI classes with inheritance, discovery integrations via MID Server and Discovery patterns, and service mapping out of the box.
- Enterprise ecosystem
- ServiceNow's IntegrationHub, MID Servers, and scoped application model provide integration depth — including bidirectional connectors for SAP, Workday, Jira, Azure DevOps, and Splunk — that SysAid's Workato-embedded marketplace does not match at scale.
Don't move on until
- Counts confirmed across every ITSM record type including CMDB
- Change-management implications reviewed with the CAB
- SLA and OLA targets documented with their calculation rules
02 Data Audit Audit the service data and the configuration data separately.
Objective Profiled exports for every record type, with CMDB integrity and audit-trail requirements resolved.
Keep these open
-
Export and profile every record type
Profile incidents, changes, problems, requests, knowledge and CIs separately — they have different shapes and different defects. Reconcile each export against the API count to catch pagination truncation.
Data Profiler Profile the SysAid export for nulls, outliers and type drift -
Audit CMDB integrity
Find CIs with no owner, no class, or relationships pointing at deleted CIs, plus duplicates from overlapping discovery sources. A CMDB is usually the least-maintained data in the estate and migrating its decay wastes the one chance you have to clean it.
Duplicate CIs from multiple discovery sources will multiply on load unless you dedupe before migrating.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Resolve audit-trail and retention requirements
Confirm with compliance how much history and which audit fields must be preserved, and whether a read-only archive of SysAid satisfies the requirement. In regulated environments this often changes scope materially.
Regulated environments frequently require the immutable original audit trail, which no migration can recreate — plan for an archive.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Validate structure and encoding of the exports
Check delimiters, encoding and embedded newlines. Incident work notes and change implementation plans contain long multi-line text and pasted logs, which is exactly what breaks CSV parsing.
CSV Validator Catch broken headers and ragged rows in the raw export -
Scan for PII and secrets in ticket text
ITSM tickets contain credentials, connection strings, internal hostnames and personal data pasted into work notes. Scan for both regulated data and secrets, and treat found credentials as a security incident in their own right.
Work notes commonly contain passwords and connection strings. Migrating them propagates the exposure into a new system.
-
Clean, normalise and produce masked test data
Normalise timestamps to UTC, standardise CI naming, trim whitespace, and generate a masked copy for the sandbox. Business-hours SLA calculations make timezone consistency non-negotiable here.
PII Masker Generate a safe copy for sandbox and vendor testing
SysAid → ServiceNow specifics
- SysAid Cloud
- API-only extraction. You are limited to the REST API (/api/v1/) and Connect API (/connect/v1/) endpoints, with the rate limits described below. No direct database access is available.
- SysAid On-Premise
- In addition to the API, on-premise deployments may allow direct SQL access to the underlying database (typically Microsoft SQL Server or MySQL). Direct DB queries can bypass API rate limits and extract data significantly faster, but require coordination with the DBA team and carry risk if the internal schema is undocumented. SysAid also offers report-based CSV exports from the admin console, which can supplement API extraction for simpler datasets (users, assets, flat ticket lists) but do not capture relationships, activities, or attachments.
- SysAid "Journey" tab
- The Journey tab is an actionable audit log of all Service Record Events. ServiceNow has no direct equivalent. The closest option is to import journey entries as journal entries (preserving timestamps) or as records in a custom audit table. Some teams create a custom u_sysaid_journey table to preserve the full event stream.
- SysAid templates
- SysAid uses templates as predefined formats for creating service records. ServiceNow uses catalog items, record producers, and form views instead. Templates must be rebuilt manually — there is no automated conversion path.
- SysAid one-step automations and workflow rules
- These cannot be exported via API. They must be audited manually in the SysAid admin console and recreated as ServiceNow Business Rules, Flow Designer flows, or Scheduled Jobs. Document each rule's trigger condition, action, and scope before attempting recreation.
Don't move on until
- Every record type exported and profiled against API counts
- CMDB orphans and broken relationships quantified
- Audit-trail retention requirements confirmed with compliance
03 Field Mapping Map record types, state models, CI classes and approvals.
Objective A signed mapping covering record types, state machines, CI classes and relationships, and approval chains.
Keep these open
-
Map record types before fields
Establish how SysAid record types land in ServiceNow — service requests may become a different object entirely, and incident/problem separation is modelled differently across tools. Get this wrong and every field decision downstream is built on sand.
Schema Mapper Opens pre-loaded with the SysAid → ServiceNow field pair -
Map the state model and the impact/urgency matrix
Enumerate every state and transition, plus how priority is derived from impact and urgency. Tools derive priority differently, so a straight priority copy will disagree with the target's own calculation and confuse everyone reading a report.
If ServiceNow derives priority from impact and urgency, migrating priority directly will produce records whose priority contradicts their own inputs.
-
Map CI classes, attributes and relationship types
Match each CI class and relationship type to a ServiceNow equivalent and document every gap explicitly. Where no relationship type exists, decide whether to approximate, flatten, or park the data in an attribute — and record the impact on change risk scoring.
JSON to CSV Converter Flatten nested API responses into a reviewable sheet -
Map assignment groups, roles and approval chains
Build the group and user map including leavers, and map each approval chain to its ServiceNow equivalent. Historical approvals usually cannot be recreated as live approval records — decide how you preserve the evidence.
-
Plan knowledge article migration
Decide how article bodies, categories, permissions and linked-incident references translate. Confirm whether internal links between articles and attachment references survive, or need rewriting after load.
-
Set load order and freeze the spec
Sequence users and groups, then CIs, then CI relationships, then tickets, then knowledge — CI relationships need both endpoints to exist. Version and sign off the spec before the pilot.
Don't move on until
- State and priority models mapped, including impact/urgency matrices
- CI classes and relationship types mapped with gaps documented
- Approval chains and assignment groups mapped to target equivalents
04 Test Migration Pilot the whole service model, including a change with approvals.
Objective A sandbox pilot where tickets, CI relationships, SLAs and approvals all behave correctly.
Keep these open
-
Build the ServiceNow sandbox to match the target service model
Configure record types, states, SLAs, business calendars, assignment groups, CI classes and approval workflows before loading anything. In ITSM the configuration is the product, so an unconfigured sandbox tests nothing.
-
Pick a pilot slice spanning every record type
Include incidents at every priority, a change with a full approval chain, a problem with linked incidents, a catalogue request, connected CIs, and knowledge articles with cross-links. Coverage of types matters more than volume here.
-
Load in dependency order with full logging
Users and groups, then CIs, then relationships, then tickets, then knowledge. Log each request against its source ID so you can trace any failure without a full re-run.
-
Verify CI relationships and impact analysis
Confirm relationships survived and then run an actual impact analysis on a pilot CI, comparing the result to SysAid. Relationship counts matching while impact analysis returns something different means the relationship types mapped wrongly.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Reproduce SLA compliance on migrated records
Compare calculated SLA compliance on the pilot records against SysAid. Differences trace to business-calendar or pause-condition mapping and must be resolved before full load, since compliance reporting is often contractual.
SLA compliance is recalculated from loaded timestamps. Any approximation in timestamp or pause-state mapping shows up directly as a compliance variance.
-
Run a change through approvals and reconcile
Raise a change in the sandbox, take it through its full approval chain and implementation states, and reconcile the pilot batch on counts and fields. Then let service-desk agents work sample incidents before you sign off the pilot.
Don't move on until
- CI relationships verified intact for the pilot slice
- SLA calculations reproduce source compliance figures
- A change record runs end to end through its approval chain
05 Cutover Switch the service desk without losing an incident.
Objective All in-scope service data live in ServiceNow, monitoring and email integrations repointed, desk operating normally.
Keep these open
-
Pre-load history and the CMDB ahead of the freeze
Load closed tickets, knowledge and the CMDB while SysAid stays live. The CMDB load in particular is slow and benefits enormously from happening outside the window.
Helpdesk Migration Planner Size the freeze window from ServiceNow's real API limits -
Publish the runbook with CAB-approved abort criteria
A timed sequence with named owners, plus the rollback conditions the CAB signed off. In ITSM the rollback plan is a formal deliverable, not a verbal understanding.
-
Freeze SysAid and take the final delta
Stop new ticket creation, let the desk finish in-flight work, then export everything changed since the pre-load. Communicate the freeze across the whole organisation and staff a manual intake path for genuine P1s during the window.
A P1 incident raised during the freeze needs a documented manual path, or it will be worked in the old system and lost.
-
Load open tickets and the delta, then reconcile
Load open incidents, changes and requests, then verify counts and open-state accuracy before repointing anything. Open-state accuracy matters more than history here — it is what the desk works from at 9am.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint monitoring, email and integrations
Switch monitoring-tool integrations, email intake, self-service portal links and any orchestration or discovery connectors. Then fire a real alert through monitoring and confirm the incident it creates routes correctly.
Monitoring integrations still pointing at the old tool will create incidents nobody is watching.
-
Go/no-go and switch the service desk
Call the decision against the exit criteria with the change manager present, then move the desk with elevated support for the first shift. Keep SysAid read-only as the archive and rollback path.
-
Keep SysAid readable
in read-only mode for at least 30 days post-cutover
-
Preserve the ID crosswalk
mapping database indefinitely — it is your Rosetta Stone for any post-migration corrections
-
Switch inbound channels
(email routing, portal URLs, agent bookmarks) only after validation passes
SysAid → ServiceNow specifics
- Do not destroy source data
- until validation is complete and stakeholders have signed off
Don't move on until
- Historical load complete and reconciled before the freeze
- Monitoring, email and integration inbound paths verified live
- CAB-approved rollback point passed explicitly
06 Validation Prove service continuity, compliance and reporting.
Objective Evidence that records, CMDB, SLAs and workflows all survived, plus signed acceptance and a retained archive.
Keep these open
-
Reconcile every record type and the CMDB
Compare counts per record type and per state, CI counts per class, and relationship counts per type. Produce one report acceptable to both the CAB and your auditor.
Migration Validation Tool Reconcile SysAid and ServiceNow record-for-record -
Re-verify CMDB relationships and impact analysis
Re-run impact analysis on a sample of critical CIs and compare with the pre-migration result. This is the CMDB equivalent of a field-completeness check and it is routinely skipped.
Data Profiler Prove field completeness held up through the load -
Tie SLA and service reporting to baseline
Rebuild SLA compliance, MTTR, first-time-fix and volume reporting, and compare to pre-migration figures for the same period. Explain every variance in terms of a specific mapping decision.
Business-calendar differences between tools will shift MTTR and compliance even when the underlying data is identical.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Test the full workflow layer
Fire every escalation, approval chain, notification, catalogue fulfilment workflow and automation with live records. Workflow is rebuilt from scratch, so nothing is proven until it has been observed running.
-
Confirm compliance evidence and audit archive
Re-scan for PII and secrets in loaded records, confirm retention configuration in ServiceNow, and formally retain the SysAid archive that satisfies your immutable audit-trail requirement.
-
Close the change and sign off
Close the migration change record with actual outcomes, get written acceptance against the Discovery criteria, and schedule decommission after the agreed read-only retention period.
-
Record-count reconciliation
Compare total counts per object type: incidents, requests, changes, problems, users, CIs, assets, attachments. Source counts should match destination counts within 0.1% (accounting for intentional exclusions like orphaned records or deduplicated users). Run this query in ServiceNow: incident.list?sysparm_query=u_sysaid_idISNOTEMPTY and compare against your source count.
SysAid → ServiceNow specifics
- Field-level spot checks
- Sample 50 to 100 records per object type across different categories — open tickets, closed tickets, high-priority, reassigned, and attachment-heavy cases. Verify that status, priority, assigned_to, created_date, and resolved_date match between source and target. Use a spreadsheet with side-by-side comparison columns.
- Relationship integrity
- Verify that CI-to-incident links, parent-child ticket references, company assignments, and user assignments resolve correctly in ServiceNow. Spot-check 20+ CMDB relationships by navigating the CI record and confirming related items appear.
- Attachment verification
- Confirm that attachments are accessible and renderable on their target records. Check file sizes against the source system. Run: sys_attachment.list?sysparm_query=table_name=incident^ORtable_name=change_request and compare counts.
- Timestamp accuracy
- Verify that created, updated, and resolved timestamps match the source system. Timezone shifts are a common failure mode — SysAid may return timestamps in the account's local timezone despite documenting UTC, so compare a sample of 10+ records with known timestamps.
- UAT with real agents
- Have 3 to 5 IT agents work in ServiceNow using migrated data for 1 to 2 days before go-live. Ask them to search for old SysAid IDs (using the u_sysaid_id field), open records, verify activity history, and confirm attachments are accessible. Agents find issues — missing categories, wrong assignment groups, truncated descriptions — that automated checks miss.
Don't move on until
- Reconciliation complete across all record types and CIs
- SLA and service reporting tie to pre-migration baselines
- Audit archive retained and acceptance signed
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
SysAid ServiceNow Object and Field Mapping
| SysAid field | ServiceNow field | Notes |
|---|---|---|
| Service Record (type=incident) | incident | Map SysAid id to a custom u_sysaid_id field for traceability |
| Service Record (type=request) | sc_request + sc_req_item OR incident | Only use sc_request + sc_req_item when the record represents catalog fulfillment. Generic help desk requests often map better to incident or a custom task table |
| Service Record (type=change) | change_request | SysAid change types (standard, normal, emergency) must map to ServiceNow's type field values |
| Service Record (type=problem) | problem | Map to problem, not problem_task. SysAid problems may have linked incidents; rebuild these as task_rel_task records |
| Users (Agents) | sys_user | Map SysAid admin flag and group memberships to ServiceNow roles (itil, itil_admin) |
| Users (End Users) | sys_user | Set active=true and appropriate user_name. No role assignment needed |
| Companies | core_company | SysAid stores company at the user level. ServiceNow has a dedicated company table. Load before users |
| Assets | alm_asset | SysAid assets and CIs are separate objects. Decide whether each source asset is a business asset, a CI, or both in ServiceNow |
| CIs | cmdb_ci_* (class-specific) | SysAid CI types must map to the correct ServiceNow CI class. Use IRE or CMDBTransformUtil to enforce identification during import |
| CI Relationships | cmdb_rel_ci | Each SysAid CI relation type maps to a cmdb_rel_type record. "Installed on" and "Depends on" must be mapped individually |
| Activities / Notes | sys_journal_entry | SysAid activities become journal entries on the target record. Preserve timestamps and author attribution |
| Attachments | sys_attachment + sys_attachment_doc | SysAid attachments are linked by Service Record ID. Each must be re-uploaded to the correct ServiceNow table and table_sys_id |
Data Type Endpoint
| SysAid field | ServiceNow field | Notes |
|---|---|---|
| Service Records | `GET /api/v1/sr?type={incident\ | request\ |
| Users | GET /api/v1/users | Returns agents and end users |
| Assets | GET /api/v1/assets | Hardware and software assets |
| CIs | GET /api/v1/ci | CMDB configuration items |
| Activities | GET /connect/v1/activities/sr/search | Activity history per Service Record |
| Related Items | GET /connect/v1/service-records/{recordId}/related-items | Linked records |
| Attachments | GET /api/v1/sr/{id}/attachment | Returns metadata. Binary download requires a separate call per attachment |
| Custom Field Metadata | GET /api/v1/sr/custom-fields | Required for translating list-type custom field indexed values to human-readable labels |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Incidents | low | SysAid Service Records with type=incident map directly to ServiceNow's incident table with straightforward field alignment. |
| Requests (Service Catalog) | high | SysAid Requests must be triaged into genuine catalog fulfillment (sc_request + sc_req_item) versus generic help desk asks (incident), and incorrect routing breaks fulfillment reporting and assignee relationships. |
| Change Requests | medium | SysAid change types (standard, normal, emergency) require explicit mapping to ServiceNow's type field values, and associated approval workflows must be rebuilt. |
| Problems | medium | SysAid problems may have linked incidents that must be rebuilt as task_rel_task records in ServiceNow, and incorrect mapping to problem_task instead of problem is a common error. |
| CMDB CIs | high | SysAid's flat CI types must be mapped to the correct ServiceNow CI class hierarchy and loaded through the IRE to prevent duplicate records and broken class inheritance. |
| CI Relationships | high | Each SysAid CI relation type must be individually mapped to a ServiceNow cmdb_rel_type record, and naive imports frequently break dependency and containment links. |
| Users and Companies | medium | SysAid stores company at the user level while ServiceNow uses a dedicated core_company table, requiring companies to be loaded first and role mappings (admin flag to itil roles) to be explicitly defined. |
| Custom Fields | medium | SysAid custom fields require a separate metadata API pull to resolve list-type indexed values, and every field must be pre-created in ServiceNow with the u_ prefix before import. |
| Activities and Notes | medium | SysAid activities and Journey tab entries have no direct ServiceNow equivalent and must be imported as journal entries with preserved timestamps, or stored in a custom audit table. |
| Attachments | medium | Each SysAid attachment must be re-uploaded to the correct ServiceNow table and table_sys_id, requiring the reference crosswalk to be fully resolved before attachment loading begins. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Unified-to-Multi-Table Splitting
Every SysAid Service Record must be classified by type and routed to the correct ServiceNow table, with Requests requiring an up-front design decision on whether they become sc_request/sc_req_item pairs or incident records.
CMDB Hierarchy and IRE Compliance
SysAid's flat CI types and relation types must be mapped to ServiceNow's class-inherited CMDB structure and imported through the Identification and Reconciliation Engine to avoid creating duplicate CIs.
Reference Field Crosswalk Resolution
Every reference field such as caller_id, assigned_to, cmdb_ci, and assignment_group requires a maintained translation database mapping SysAid IDs to ServiceNow sys_ids for accurate record linking.
Custom Field and Picklist Translation
SysAid custom fields (cust_ prefix) and numeric picklist values for status, priority, urgency, and impact require explicit metadata extraction and enum crosswalk mapping to ServiceNow's u_ fields and choice values.
Workflow and Automation Rebuild
SysAid one-step automations, workflow rules, and templates cannot be exported via API and must be manually audited and recreated as ServiceNow Business Rules, Flow Designer flows, and catalog items.
Activity History and Timestamp Preservation
SysAid activities and Journey tab entries must be converted to ServiceNow journal entries with accurate UTC timestamps and author attribution, accounting for mixed date formats (ISO 8601 and epoch milliseconds) in the source API.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
How long does a SysAid to ServiceNow migration take?
A typical mid-size enterprise migration (50,000 to 200,000 records) takes 3 to 6 weeks from discovery to go-live. Smaller migrations with under 10,000 records and no CMDB can complete in 1 to 2 weeks. Enterprise migrations with 500,000+ records and deep CMDB hierarchies may extend to 8 to 10 weeks. The largest variable is attachment volume, because each SysAid attachment requires an individual API call to download.
What data cannot be migrated from SysAid to ServiceNow?
SysAid workflow automations, routing rules, notification templates, and dashboard configurations cannot be exported via API and must be rebuilt in ServiceNow. SLA elapsed-time counters are calculated values that ServiceNow's SLA engine will not retroactively compute for imported records. Contextual attachment placement inside rich text fields also does not transfer 1-to-1.
Can SysAid CMDB data be preserved in ServiceNow?
Yes, but not as a 1-to-1 copy. SysAid CI types must be mapped to ServiceNow's class-based CMDB hierarchy. CI relationships must be individually mapped from SysAid's relation types to ServiceNow's cmdb_rel_type records. Use ServiceNow's IRE (Identification and Reconciliation Engine) during import to avoid creating duplicate CIs.
Can SysAid ticket history be preserved in ServiceNow?
Yes. SysAid activity history (notes, status changes, assignment changes) can be migrated as sys_journal_entry records in ServiceNow. Each journal entry preserves the original author and timestamp. Native ServiceNow audit and history behavior is not a 1-to-1 copy target, but human-readable history is fully preservable for compliance and operational purposes.
Is there downtime during a SysAid to ServiceNow migration?
A big-bang migration requires a freeze window of 4 to 24 hours where no new tickets should be created in SysAid. An incremental migration with delta sync can reduce this to under 1 hour. The bulk of historical data is migrated while SysAid is still active, and only the delta (new and modified records since the bulk load) is migrated during the cutover window.