Migrating ConnectWise Manage to ServiceNow takes 3 to 8 weeks and requires multi-pass CMDB loading, board-to-Assignment Group decomposition, and API rate limit management on both platforms.
Migrating from ConnectWise Manage to ServiceNow has no native migration path and requires custom ETL development to bridge fundamentally different data models. ConnectWise organizes tickets by Service Boards with board-specific statuses and uses flat, single-level Configuration records, whereas ServiceNow uses a global incident state model with category/subcategory taxonomy, Assignment Groups for routing, and a class-based CMDB with relationships stored in a dedicated cmdb_rel_ci table. Custom work is required to decompose each ConnectWise Service Board into ServiceNow Assignment Groups, Categories, SLA Definitions, and Assignment Rules, as well as to perform multi-pass CMDB loads, email-based contact deduplication, status normalization, and binary attachment re-upload via API.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Quick Answer
Migrating from ConnectWise Manage to ServiceNow is a multi-object data migration that typically takes 3 to 8 weeks depending on record volume, CMDB depth, and custom field count. The single biggest risk is broken CMDB relationships: ConnectWise Configurations use a flat parent/child model, while ServiceNow stores CI relationships in a dedicated cmdb_rel_ci table that requires a multi-pass load. Service Boards, board-specific statuses, and ticket-to-configuration links have no direct 1-to-1 equivalent in ServiceNow and must be decomposed into Assignment Groups, Incident Categories, CI associations, and SLA Definitions. Teams with fewer than 50,000 records and no multi-level CMDB dependencies can often handle the migration in-house. Organizations with 100,000+ records, complex configuration hierarchies, or compliance requirements (SOC 2, HIPAA) should use a managed migration service.
If you do not lock the board-to-assignment mapping and the external ID strategy before
If you do not lock the board-to-assignment mapping and the external ID strategy before the first full load, you are still prototyping.
ConnectWise Report Writer CSV exports cannot extract attachments, inline images, or binary files
If your migration scope includes attachments, you must use the REST API /system/documents endpoint to download each file individually. For a dataset with 50,000 tickets and an average of 2 attachments per ticket, that is 100,000 additional API calls at 60 per minute — roughly 28 hours of extraction time for attachments alone. Plan accordingly by running attachment extraction in parallel with a separate API member credential to avoid starving your ticket extraction pipeline.
If a Service Board can produce both incident-like work and request-like work, split the
If a Service Board can produce both incident-like work and request-like work, split the routing rule before full load. Mixing both into one target table is a common source of re-migration. Create explicit board-to-target-table rules: board "Help Desk" → incident, board "Service Requests" → sc_req_item.
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 ConnectWise
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 ConnectWise → 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
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 ConnectWise 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 ConnectWise 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
ConnectWise → ServiceNow specifics
- Assignment Rules
- for auto-routing based on category, location, or CI
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 ConnectWise 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 ConnectWise → 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 ConnectWise. 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 ConnectWise. 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.
ConnectWise → ServiceNow specifics
- Field-level spot checks
- Sample 50 to 100 records across each object type. Verify that status, priority, company reference, assigned agent, and timestamps match the source. Confirm that time zones did not shift during API extraction — ConnectWise returns timestamps in the member's configured time zone, while ServiceNow stores in UTC.
- Relationship integrity
- Query cmdb_rel_ci to confirm that every migrated CI has the expected parent/child links. Flag any CIs with null parent references that should not be null. Validation query: SELECT child FROM cmdb_rel_ci WHERE parent IS NULL AND child.u_legacy_cw_id IS NOT NULL.
- Journal entry ordering
- Verify that ticket notes appear in the correct chronological order on the incident timeline. If notes were flattened into a single text blob, you have lost the journal behavior ServiceNow uses for comments and work_notes, which weakens troubleshooting context and auditability.
- UAT with agents
- Have 3 to 5 IT agents review their most recent and most complex tickets in ServiceNow. They will find mapping errors that automated checks miss.
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 ConnectWise 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 ConnectWise 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 ConnectWise read-only as the archive and rollback path.
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 ConnectWise 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 ConnectWise 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 tickets, contacts, companies, and configurations between source and target. Acceptable variance is 0%. Any delta indicates dropped records. Query: SELECT COUNT(*) FROM incident WHERE u_legacy_cw_id IS NOT NULL and compare against your staging database count.
ConnectWise → ServiceNow specifics
- Attachment verification
- Sample 20 to 30 attachments. Confirm they open correctly and are linked to the right incident. Verify file sizes match between source and target.
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.
ConnectWise Manage ServiceNow Object Mapping
| ConnectWise field | ServiceNow field | Notes |
|---|---|---|
| Service Tickets | Incidents (incident) or RITMs (sc_req_item) | Service requests map to RITMs; break-fix issues map to Incidents. Each CW board has its own status set that must be normalized. |
| Service Boards | Assignment Groups (sys_user_group) + Categories + SLA Definitions + Assignment Rules | No direct equivalent. Board routing logic maps to Assignment Group membership and category-based assignment rules. Board SLA targets must be recreated as SLA Definitions. |
| Companies | Accounts (customer_account) or Companies (core_company) | Depends on ServiceNow ITSM configuration. Must be loaded first to establish the parent account for users and assets. |
| Contacts | Users (sys_user) | Deduplicate by email before load. ConnectWise allows duplicate emails; ServiceNow requires unique email addresses on sys_user. |
| Members (Agents) | Users (sys_user) with ITIL roles | Map CW identifier (capped at 15 characters) to SN user_name. Assign ITIL roles to members who will function as agents. Note: each ITIL-role user consumes a ServiceNow ITIL license. |
| Configurations | CMDB CIs (cmdb_ci + extended classes) | Requires class mapping per configuration type and a two-pass load for parent/child relationships. |
| Time Entries | Time Cards (time_card) | SN time tracking is less granular than CW. Must link back to the specific Incident or RITM and the User who logged the time. |
| Ticket Notes | Journal Entries (sys_journal_field) | Internal notes map to Work Notes. External notes map to Additional Comments. Preserve created_by and timestamp. |
| Attachments | Attachments (sys_attachment) | Must be downloaded as binary from CW /system/documents endpoint and re-uploaded via SN Attachment API. |
| Custom Fields | Custom fields on target table | CW custom fields must be pre-created on the target ServiceNow table before import. Land them in staging columns first, then normalize in Transform Maps. |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Tickets (Incidents/RITMs) | high | Board-specific statuses, routing logic, and the split between break-fix incidents and service request items require complex normalization and classification logic with no direct 1-to-1 mapping. |
| CMDB Configurations | high | Flat ConnectWise Configuration records must be mapped to ServiceNow's inheritance-based CI class hierarchy with relationships loaded in a separate pass into cmdb_rel_ci, creating significant risk of broken dependencies. |
| Service Boards | high | Service Boards have no direct equivalent in ServiceNow and must be decomposed into Assignment Groups, Categories, SLA Definitions, and Assignment Rules, requiring a detailed board mapping matrix. |
| Companies (Accounts) | medium | Companies must be loaded first to establish parent account relationships for users and assets, and the target table depends on the specific ServiceNow ITSM configuration in use. |
| Contacts (Users) | medium | Duplicate email addresses in ConnectWise must be resolved before import since ServiceNow enforces unique email constraints on the sys_user table. |
| Members (Agents) | medium | ConnectWise member identifiers are capped at 15 characters and must be mapped to ServiceNow user_name fields with ITIL roles assigned, where each role consumes a ServiceNow ITIL license. |
| Time Entries | medium | ServiceNow's time tracking is less granular than ConnectWise, and each entry must be correctly linked back to both the specific Incident or RITM and the user who logged it. |
| Ticket Notes | low | Internal and external notes map cleanly to ServiceNow Work Notes and Additional Comments respectively, though original created_by attribution and timestamps must be carefully preserved. |
| Attachments | medium | Each attachment requires an individual binary download from ConnectWise and re-upload to ServiceNow, creating a significant time bottleneck at scale due to API rate limits. |
| Custom Fields | medium | ConnectWise custom fields and picklist values must be pre-created on target ServiceNow tables before import, landed in staging columns first, and then normalized via Transform Maps. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Service Board Decomposition
ConnectWise Service Boards bundle routing, status workflows, SLA rules, and team assignment into a single object, which must be decomposed into four separate ServiceNow constructs: Assignment Groups, Categories, SLA Definitions, and Assignment Rules.
CMDB Relationship Reconstruction
ConnectWise Configurations use a flat parent/child model, while ServiceNow stores CI relationships in a dedicated cmdb_rel_ci table with an inheritance-based class hierarchy, requiring class mapping per configuration type and a multi-pass load strategy.
Board-Specific Status Normalization
ConnectWise allows board-scoped statuses where identically named statuses on different boards are distinct records, all of which must be normalized into ServiceNow's fixed global Incident State model with only seven values.
API Rate Limit Constraints
ConnectWise enforces an approximate 60 requests-per-minute rate limit without returning a Retry-After header on 429 responses, requiring custom exponential backoff logic and parallel extraction using separate API member credentials for large datasets.
Contact Email Deduplication
ConnectWise allows duplicate email addresses across contacts, but ServiceNow requires unique email addresses on the sys_user table, necessitating deduplication and merge logic before loading.
Attachment Binary Re-Upload
Attachments must be individually downloaded as binary files from ConnectWise's /system/documents endpoint and re-uploaded via ServiceNow's Attachment API, which for large datasets can require tens of hours of dedicated extraction time.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
How long does a ConnectWise Manage to ServiceNow migration take?
A ConnectWise Manage to ServiceNow migration typically takes 3 to 8 weeks depending on record volume, CMDB complexity, and custom field count. A mid-size migration of 50,000 tickets and 5,000 configurations requires roughly 3 to 5 weeks across discovery, ETL development, test migration, UAT, and production cutover.
Can ConnectWise Manage ticket history be preserved in ServiceNow?
Yes. Ticket notes can be migrated as Journal Entries preserving the original author, timestamp, and content. Work Notes and Additional Comments maintain the full conversation thread. Original creation and resolution dates can be set using ServiceNow's autoSysFields=false parameter during API insert.
How do ConnectWise Service Boards map to ServiceNow?
ConnectWise Service Boards have no direct equivalent in ServiceNow. Each board must be decomposed into Assignment Groups for team routing, Categories and Subcategories for classification, and SLA Definitions for response targets. Board-specific statuses must be normalized into ServiceNow's global incident State field.
What are the biggest risks of this migration?
The three most common failure modes are orphaned CMDB CIs caused by single-pass loading without relationship reconstruction, incorrect status mapping where board-specific statuses are flattened into the wrong ServiceNow incident state, and API throttling on the ConnectWise side causing incomplete data extraction. All three are preventable with proper architecture and testing.
How much does a ConnectWise Manage to ServiceNow migration cost?
A managed migration of 20,000 to 50,000 tickets with standard objects typically ranges from $5,000 to $20,000. Enterprise migrations exceeding 200,000 records with multi-level CMDB and compliance requirements can exceed $30,000. In-house builds appear cheaper but carry hidden costs in engineering time and re-work.