Migrating ServiceDesk Plus to ServiceNow takes 3 to 10 weeks, requires API-based extraction due to CSV export limitations, and demands careful CMDB relationship ordering to prevent data loss.
Migrating from ServiceDesk Plus to ServiceNow requires custom API-based extraction and transformation work, as no native migration path exists between the two platforms. The fundamental challenge lies in mapping ServiceDesk Plus's flat, loosely linked data model—where requests, assets, and CIs use numeric priorities and simple picklists—to ServiceNow's normalized relational model where every field resolves to a sys_id, CIs belong to a typed class hierarchy, and relationships are enforced in dedicated tables. Native CSV exports from ServiceDesk Plus drop critical data including conversations, worklogs, and inline attachments, making API-based extraction mandatory for production migrations. Custom transform scripts are required to handle field-level type conversions (e.g., priority matrix mapping), reference field resolution, choice list pre-loading, and CMDB class hierarchy reconstruction.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
If you migrate every historical ServiceDesk Plus service request into Incident because it
If you migrate every historical ServiceDesk Plus service request into Incident because it is easier, reporting gets simpler but catalog fidelity is gone. If you rebuild them as Request plus Requested Item, you preserve service request structure but increase mapping, validation, and test effort by roughly 40% because you must create catalog items, variable sets, and RITM-to-Request parent relationships. Make this decision explicitly during discovery and document its reporting impact.
Do not validate a CMDB migration by opening one giant dependency view and hoping it renders
Validate by CI class, relationship type, and sampled parent-child pairs. Use GlideRecord queries to systematically check relationship integrity:
If you load historical tickets into ServiceNow without suppressing notifications and SLA
If you load historical tickets into ServiceNow without suppressing notifications and SLA rules, every resolved ticket from the past several years can trigger an email to the original requester. Use sysparm_suppress_auto_sys_field=true on Import Set loads and disable SLA processing for historical records before loading. This is the single most common post-migration incident. In one observed case, a migration of 150,000 historical incidents without notification suppression generated over 80,000 outbound emails in 45 minutes before the email queue could be manually paused.
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 ManageEngine ServiceDesk Plus
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 ManageEngine ServiceDesk Plus → 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
ManageEngine ServiceDesk Plus → ServiceNow specifics
- Workflow engine depth
- ServiceNow's Flow Designer supports multi-stage, cross-module orchestration with branching, parallel approvals, SLA timers, and subflows that can invoke Integration Hub spokes. ServiceDesk Plus request workflows support sequential approval stages and field-update actions but lack conditional branching, parallel execution, and cross-module orchestration within a single flow.
- CMDB maturity
- ServiceNow's Common Service Data Model (CSDM) provides a standards-based CI class hierarchy with over 400 out-of-box CI classes organized across five CSDM layers (Foundation, Product, Technical, Design, and Sell/Consume). ServiceDesk Plus uses a flat asset-centric model with user-defined CI types that becomes difficult to maintain past a few thousand CIs because relationships are not enforced by class type.
- Enterprise integration surface
- ServiceNow exposes IntegrationHub (with 600+ prebuilt spokes as of 2024), bidirectional REST/SOAP APIs, and event-driven integration via Flow Designer triggers. ServiceDesk Plus Cloud restricts API throughput with endpoint-specific rate limits (detailed below) that constrain real-time integration patterns and offers a smaller integration ecosystem.
- Multi-instance consolidation
- Large enterprises running ServiceDesk Plus across multiple sites often reach a point where consolidation into a single ServiceNow instance simplifies governance, reporting, and license management. ServiceNow's domain separation feature enables multi-tenant data isolation within a single instance, which ServiceDesk Plus does not offer.
- Timeline
- A data-level rollback for 200K+ records across 8–10 tables takes 2 to 6 hours depending on business rule complexity. Test the rollback procedure in sub-production before go-live.
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 ManageEngine ServiceDesk Plus 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 ManageEngine ServiceDesk Plus 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 -
Audit compliance requirements
If SOX, HIPAA, or ITIL audit trails apply, document the chain-of-custody requirements for migrated data — what hash verification is needed, what migration logs must be retained, and what sign-off process is required before decommissioning SDP
ManageEngine ServiceDesk Plus → ServiceNow specifics
- SDP Request "Mode" field
- (Phone Call, Email, Web Form) has no default equivalent in the Incident table. Map to ServiceNow's contact_type field (which supports values like phone, email, self-service, walk-in) or create a custom field.
- SDP "Due by time" vs. ServiceNow SLA-driven due dates
- SDP stores a static due date on the request. ServiceNow calculates due dates dynamically from SLA definitions attached to the task_sla table. You can write the historical due date to a custom field (e.g., u_legacy_due_date), but active SLA tracking will not honor it — ServiceNow will calculate its own due dates based on SLA definitions applied to the record.
- SDP Purchase Orders and Contracts
- ServiceNow has procurement modules (Procurement > Purchase Orders, Contract Management), but they use a different schema (proc_po, ast_contract). These objects require a separate mapping effort outside the ITSM migration scope.
- SDP ticket numbers
- ServiceNow auto-generates ticket numbers (e.g., INC0010001) using a number sequence (sys_number) and does not allow direct control over the Number field via API import or Import Sets. Store the original SDP ticket ID in a custom field (e.g., u_legacy_sdp_id) for cross-reference. Index this field for query performance.
- ServiceDesk Plus Cloud
- uses OAuth 2.0 via Zoho Accounts (accounts.zoho.com). The token scope needed is SDPOnDemand.requests.ALL for request data and SDPOnDemand.assets.ALL for asset and CI data. Tokens expire after 1 hour; implement automatic refresh using the refresh token. (manageengine.com)
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 ManageEngine ServiceDesk Plus 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 ManageEngine ServiceDesk Plus → 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.
-
Map by meaning, not by label or numeric value
Priority is a good example — copying a raw source number rarely produces the right operational behavior in ServiceNow. Document the explicit mapping (e.g., SDP Priority 1 "High" → ServiceNow Impact 2 + Urgency 1 → Priority 2) and get stakeholder sign-off.
-
Preserve source identifiers
Keep the original SDP request ID, display ID, status name, and technician name in searchable custom fields (e.g., u_legacy_sdp_id, u_legacy_sdp_status). Agents need these during hypercare for search and reconciliation.
ManageEngine ServiceDesk Plus → ServiceNow specifics
- Coalesce fields
- the field(s) used to determine insert vs. update (e.g., coalesce on u_legacy_sdp_id to prevent duplicates on re-runs)
- Choice action
- set to "reject" to catch unmapped choice values rather than silently inserting blanks
- Transform scripts
- onBefore, onAfter, and field-level scripts for data transformation
- Field mapping document
- signed off by the data owner, documenting every source-to-target field mapping and any data transformations applied
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 ManageEngine ServiceDesk Plus. 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 ManageEngine ServiceDesk Plus. 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.
ManageEngine ServiceDesk Plus → ServiceNow specifics
- Rollback test results
- evidence that the rollback procedure was tested in sub-production
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 ManageEngine ServiceDesk Plus 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 ManageEngine ServiceDesk Plus 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 ManageEngine ServiceDesk Plus read-only as the archive and rollback path.
ManageEngine ServiceDesk Plus → ServiceNow specifics
- Before import
- Export each target table's current state using ServiceNow's XML export (/sys_export.do?sysparm_query=...&XML). For large tables, use background scripts with GlideRecord to export in batches.
- Rollback execution
- If validation fails, delete all records with u_legacy_sdp_id IS NOT NULL from each target table, then re-import the pre-migration XML exports.
- CMDB rollback
- Delete relationships first (cmdb_rel_ci records), then CIs. Reversing this order leaves orphan relationship records.
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 ManageEngine ServiceDesk Plus 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 ManageEngine ServiceDesk Plus 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.
ManageEngine ServiceDesk Plus → ServiceNow specifics
- Hash verification
- SHA-256 hashes of all extracted data files, matched against hashes of loaded data
- Validation report
- results of the checklist above, with specific record IDs sampled
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.
ServiceDesk Plus ServiceNow Object Mapping
| ManageEngine ServiceDesk Plus field | ServiceNow field | Notes |
|---|---|---|
| Requests (Incident type) | Incident (incident) | SDP uses a single "Request" object with a type field. Filter on is_service_request = false. Map resolution codes carefully; state transitions must align with ServiceNow's ITIL state model (New=1, In Progress=2, On Hold=3, Resolved=6, Closed=7). |
| Requests (Service Request type) | Requested Item (sc_req_item) | Service Requests map to RITMs, not directly to incident. Catalog items and variable sets must exist in ServiceNow first. Each RITM requires a parent Request (sc_request) record. |
| Problems | Problem (problem) | Direct mapping. Problem tasks in ServiceNow are child records (problem_task) that SDP does not separate natively — SDP embeds task tracking within the problem record itself. |
| Changes | Change Request (change_request) | Map SDP change types (Standard, Normal, Emergency) to ServiceNow's Type field. Rebuild approvals and workflows separately from data load — ServiceNow change approvals live in sysapproval_approver, not on the change record itself. |
| Assets | Asset (alm_asset) | SDP asset types map to ServiceNow CI classes via asset-CI pairing. Do not force every asset into CMDB if it is really ownership or lifecycle data — ServiceNow distinguishes between alm_asset (financial/lifecycle) and cmdb_ci (technical/operational). |
| CIs (CMDB) | CMDB CI (cmdb_ci_*) | SDP uses flat CI types. ServiceNow requires mapping to specific class tables (e.g., cmdb_ci_server, cmdb_ci_app_server, cmdb_ci_win_server). Load CIs first; load relationships only after target sys_ids exist. |
| Requesters | User (sys_user) | SDP separates requesters and technicians into distinct tables. ServiceNow uses a single sys_user table with role assignments. Map email addresses as the primary coalesce value. |
| Technicians | User (sys_user) | Merge with requesters. Assign itil role for agent access. If a person exists in both SDP tables, deduplicate by email before loading. |
| Support Groups | Group (sys_user_group) | Ensure group membership records (sys_user_grmember) are loaded before ticket assignment references. |
| Solutions | Knowledge Article (kb_knowledge) | SDP Solutions map to ServiceNow Knowledge Base articles. HTML cleanup is usually required — SDP stores solutions with ManageEngine-specific HTML formatting. Requires a target knowledge base and category structure to exist first. |
| Request Notes | Comments / Work Notes (sys_journal_field) | Use the SDP show_to_requester flag to determine whether a note maps to ServiceNow's customer-visible comments or internal work notes. (manageengine.com) |
| Worklogs | Time Card (time_card) or Journal Entry | Use Time Cards only if your ServiceNow instance has Time Card Management enabled. Otherwise, map to journal entries on the parent record. Timestamps must be preserved in UTC. |
| Attachments | Attachment (sys_attachment) | Binary files linked via table_sys_id. ServiceNow's default maximum attachment size is 24 MB per file (configurable via com.glide.attachment.max_size property). Must be downloaded from the SDP API and uploaded via the ServiceNow Attachment API. |
| Notifications | No direct equivalent | SDP notification history does not migrate. ServiceNow generates its own notification logs via sys_email. |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Incidents (Requests) | medium | Request records map reasonably well to ServiceNow incidents, but state transition alignment to ServiceNow's ITIL state model and priority matrix re-mapping require careful transform scripting and validation. |
| Service Requests | high | Rebuilding service requests as Request plus Requested Item preserves catalog fidelity but requires pre-built catalog items, variable sets, and parent-child RITM relationships, increasing mapping and validation effort by approximately 40%. |
| CMDB CIs and Relationships | high | ServiceDesk Plus's flat CI types must be mapped to ServiceNow's typed class hierarchy, and ServiceNow enforces relationship depth limits that can silently truncate parent-child CI graphs during load. |
| Assets | medium | ServiceNow distinguishes between alm_asset (financial/lifecycle) and cmdb_ci (technical/operational), so migration must correctly separate asset data from CMDB data rather than forcing all assets into CI tables. |
| Users and Groups | medium | Merging separate requester and technician tables into a single sys_user table requires email-based deduplication and correct role assignment, and group membership records must be loaded before any ticket assignment references. |
| Worklogs and Time Entries | medium | Worklogs map to either Time Cards or journal entries depending on ServiceNow instance configuration, and all timestamps must be normalized to UTC to prevent time zone drift in historical records. |
| Attachments | medium | Binary files must be individually downloaded via the ServiceDesk Plus API and re-uploaded via the ServiceNow Attachment API, subject to ServiceNow's default 24 MB per-file size limit and API throughput constraints. |
| Custom Fields | high | Every ServiceDesk Plus dropdown value must be pre-loaded into ServiceNow's sys_choice table before ticket import, because ServiceNow silently defaults unrecognized choice values to empty rather than creating them on the fly. |
| Knowledge Articles (Solutions) | low | Solutions map directly to kb_knowledge records, but HTML cleanup is typically required to remove ManageEngine-specific formatting, and target knowledge base and category structures must exist prior to import. |
| Change Requests | medium | Change type mapping is straightforward, but approvals and workflows must be rebuilt separately since ServiceNow stores change approvals in sysapproval_approver rather than on the change record itself. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
CMDB Class Hierarchy Mapping
ServiceDesk Plus uses flat, user-defined CI types that must be mapped to ServiceNow's 400+ out-of-box CI class tables (e.g., cmdb_ci_server, cmdb_ci_app_server) organized across five CSDM layers, with relationships loaded separately into cmdb_rel_ci after all target sys_ids exist.
API Rate Limit Constraints
ServiceDesk Plus Cloud enforces endpoint-specific API rate limits that throttle extraction throughput, requiring careful batching and retry logic to extract complete datasets without hitting quota ceilings.
Priority and Field Transformation
ServiceDesk Plus stores priority as simple numeric values while ServiceNow derives priority through an Impact × Urgency matrix lookup, meaning direct numeric copies produce incorrect priority calculations and each value must be explicitly mapped to the correct Impact/Urgency combination.
Service Request Structure Divergence
ServiceDesk Plus uses a single Request object with a type flag, but ServiceNow separates service requests into a three-tier structure of sc_request, sc_req_item, and catalog item with variable sets, requiring catalog infrastructure to be built before data loading.
User Table Deduplication and Merging
ServiceDesk Plus separates requesters and technicians into distinct tables, while ServiceNow uses a single sys_user table with role assignments, requiring deduplication by email and role mapping before ticket assignment references can resolve.
Journal and Attachment Fidelity
Native CSV exports from ServiceDesk Plus omit conversations, worklogs, and inline attachments, and request notes must be split into customer-visible comments versus internal work_notes based on the show_to_requester flag, with binary attachments requiring separate download and re-upload via API.
What breaks
Known failure modes. Have a recovery plan for each before you cut over.
Duplicate users across SDP Requester and Technician tables
A single person can have both a requester record and a technician record in ServiceDesk Plus with different internal IDs. ServiceNow uses one sys_user record per person. Deduplicate by email before loading. If the same email has different names in requester vs. technician records, choose the technician record as the canonical source.
SDP custom statuses vs. ServiceNow fixed statuses
ServiceDesk Plus allows custom statuses (e.g., "Waiting for Vendor", "Pending Approval"). ServiceNow Incident uses a fixed status lifecycle (1–8). Custom statuses must be mapped to ServiceNow's standard values or added to the State field's choice list via sys_choice records. Adding custom states requires modifying the incident state model, which affects SLA calculations and reporting.
Attachment size limits
ServiceNow's default maximum attachment size is 24 MB (controlled by com.glide.attachment.max_size). SDP files larger than this must be uploaded to a linked file store or compressed. Large attachments may also need multipart/form-data uploads because base64 encoding inflates file size by approximately 33%.
Time zone mismatches
SDP stores timestamps in the instance's configured timezone. ServiceNow stores all timestamps in UTC internally and renders them in the user's local timezone. All extracted timestamps must be converted to UTC before loading, or your SLA calculations and audit trails will be wrong. Use Python's pytz library or equivalent for reliable timezone conversion.
ServiceNow business rules firing on imported data
Assignment rules, notification rules, and SLA rules can fire on newly inserted records. Disable SLA processing (com.snc.sla.engine.enabled = false) for historical records and suppress auto-generated notifications during bulk loads to prevent false alerts and email storms. Re-enable after loading and before delta sync.
Unsupported custom modules
Custom modules built in ServiceDesk Plus that have no equivalent in ServiceNow must be mapped to custom tables (u_ prefix), which may consume table quota depending on your ServiceNow contract.
Service request model fidelity
If you compress historical service requests into incidents for simplicity, you reduce build time by approximately 40% but lose catalog structure. This affects reporting (service request vs. incident volume trends), audit trails (catalog approval history), and future automation (catalog-driven workflows). Make this trade-off explicitly — it is permanent.
Multi-language content
If your SDP instance stores ticket descriptions or knowledge articles in multiple languages, ServiceNow's internationalization model requires separate knowledge article versions per language, not inline translation. Plan for additional transform work.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
How long does a ServiceDesk Plus to ServiceNow migration take?
A typical migration takes 2 to 3 weeks for small IT teams with under 10,000 tickets and no CMDB, 4 to 6 weeks for mid-size organizations with basic CMDB, and 6 to 10 weeks for enterprise environments with 100,000+ tickets and complex multi-level CMDB. The extraction phase alone accounts for 30 to 40% of calendar time due to API rate limits.
Can I migrate ServiceDesk Plus to ServiceNow without losing CMDB data?
Yes, but only through API-based extraction. The native CSV export from ServiceDesk Plus does not preserve CMDB relationship data. You must extract CIs and their parent-child relationships via the v3 REST API, map relationship types to ServiceNow's cmdb_rel_type records, and load CIs before relationships to avoid orphaned records.
What data cannot be migrated from ServiceDesk Plus to ServiceNow?
SDP notification history, audit trails of field-level changes, and active SLA timer states have no direct migration path. Native CSV exports also drop worklogs, inline attachments, conversation threading, and CMDB relationships. SDP-specific modules like built-in project management and certain procurement workflows have no equivalent in ServiceNow ITSM without additional module licensing.
How much does a ServiceDesk Plus to ServiceNow migration cost?
Cost depends primarily on record volume, custom field count, and CMDB complexity. A managed migration service for 10,000 tickets without CMDB data typically costs $3,000 to $8,000. Enterprise migrations with 100,000+ records and full CMDB can range from $15,000 to $50,000+. DIY migrations cost less in vendor fees but consume 4 to 8 weeks of senior engineering time.
Does ServiceNow have a native import tool for ServiceDesk Plus?
No. ServiceNow does not offer a built-in connector or migration wizard for ServiceDesk Plus. Data must be loaded through ServiceNow's generic Import Sets and Transform Maps from CSV, XML, or API sources. ManageEngine also does not provide a native export-to-ServiceNow feature.