ConnectWise Manage to ServiceNow Migration: The CTO's Technical Guide

What Is a ConnectWise Manage to ServiceNow Migration?

A ConnectWise Manage to ServiceNow migration is the process of extracting ITSM data — tickets, companies, contacts, configurations, time entries, notes, and attachments — from ConnectWise Manage's PSA platform and loading it into ServiceNow's ITSM module with full relational integrity preserved. (developer.connectwise.com)

Enterprise IT teams make this move for three platform-specific reasons. First, ConnectWise Manage is built for MSPs serving multiple client companies, while ServiceNow is designed for internal enterprise ITIL workflows with native Change, Problem, and Release Management modules. Second, ServiceNow's CMDB is a purpose-built, class-based CI database with relationship types, dependency mapping, and service impact analysis — capabilities that ConnectWise Configurations cannot match at scale. Third, ServiceNow offers enterprise-grade workflow automation through Flow Designer and Integration Hub, replacing the manual dispatch and escalation patterns common in ConnectWise. (servicenow.com)

Three architectural differences make this migration non-trivial:

• Data model mismatch: ConnectWise organizes tickets by Service Boards with board-specific statuses. ServiceNow uses a flat incident table with category/subcategory taxonomy and Assignment Groups for routing.
• CMDB depth: ConnectWise Configurations are single-level asset records. ServiceNow's CMDB uses an inheritance-based class hierarchy (cmdb_ci_computer, cmdb_ci_vm_instance, cmdb_ci_business_service) with relationships stored in the cmdb_rel_ci table.
• API asymmetry: ConnectWise enforces a practical rate limit around 60 requests per minute per API member. ServiceNow's throughput is governed by semaphore-based concurrency, not a fixed request-per-minute cap.

ConnectWise Manage to ServiceNow Object Mapping

A successful migration starts with a strict object mapping document. You cannot force ConnectWise objects into ServiceNow without translating the underlying relationships. (docs.connectwise.com)

Field-level mapping requires careful data type conversion. ConnectWise picklists often allow custom values that do not exist in the default ServiceNow state models. For example, a ConnectWise ticket status of "Waiting on Client" must map to the ServiceNow Incident State of "On Hold" (value 3) with an On Hold Reason of "Awaiting Caller." Preserve the original CW status in a custom field (e.g., u_legacy_cw_status) for auditing.

What Has No Clean Equivalent in ServiceNow?

ConnectWise Service Boards are the biggest mapping challenge. A single CW board (for example, "Help Desk" or "Projects") bundles routing, status workflow, SLA rules, and team assignment into one object. In ServiceNow, this logic is distributed across four constructs:

1. Assignment Groups for team routing
2. Category/Subcategory for ticket classification
3. SLA Definitions for response and resolution targets
4. Assignment Rules for auto-routing based on category, location, or CI

Each board must be decomposed during the mapping phase. Document the decomposition in a board mapping matrix before writing any ETL code.

Board-specific statuses in ConnectWise are scoped per board. A "New" status on the "Help Desk" board is a different record than "New" on the "Alerts" board. ServiceNow incidents use a global State field with values like New (1), In Progress (2), On Hold (3), Resolved (6), and Closed (7). All ConnectWise statuses must be normalized into this fixed state model.

How Does the ConnectWise Manage API Handle Extraction?

ConnectWise Manage exposes a REST API at https://{server}/v4_6_release/apis/3.0/. Every ticket, company, contact, configuration, and time entry is accessible through dedicated endpoints. Note: cloud-hosted instances use api-na.myconnectwise.net (or regional variants like api-eu.myconnectwise.net), while on-premises deployments use a custom server hostname with potentially different base URLs and network-level access controls.

Rate limits: ConnectWise does not publish a hard per-minute cap in its official documentation. Third-party implementations commonly document approximately 60 requests per minute per API member. Aggressive polling triggers throttling with HTTP 429 responses. No Retry-After header is returned on 429 responses, so exponential backoff must be implemented without a reliable signal. Start with a 2-second backoff, double on each consecutive 429, and cap at 60 seconds. Write your extractor around retries, backoff, and resumable checkpoints rather than a fixed optimistic RPM plan. (stitchflow.com)

Pagination: The default page size is 25 records. The maximum page size is 1,000 records per request. Pagination uses page and pageSize query parameters. Forward-only pagination is available for large datasets by including the pagination-type: forward-only header, which returns a Link header with a pageId cursor for the next page.

Authentication uses Basic Auth with a compound key: company+publicKey:privateKey Base64-encoded in the Authorization header, plus a required ClientID header.

Key extraction endpoints:

curl 'https://api-na.myconnectwise.net/v4_6_release/apis/3.0/service/tickets?conditions=lastUpdated>[2026-06-01T00:00:00Z]&fields=id,summary,board,status,company,contact&page=1&pageSize=1000' \
  --header 'clientId: YOUR_CLIENT_ID' \
  --header 'Authorization: Basic BASE64_COMPANY+PUBLIC:PRIVATE'

That pattern keeps extraction focused on the fields you actually transform, which matters when the source is page-based and throttled. (learn.microsoft.com)

How Does ServiceNow Handle Data Import at Scale?

ServiceNow provides three primary inbound APIs for migration: the Import Set API, the Table API, and the Attachment API. The Import Set API is the recommended path for bulk migrations because it supports Transform Maps, which handle field mapping, data transformation, and coalesce logic (upsert) in a single pipeline. ServiceNow's own guidance recommends Web Service Import Sets over writing directly to application tables from external systems. (developer.servicenow.com)

Scoped App vs Global Scope

Before building staging tables and Transform Maps, decide whether to build in a scoped application or global scope. Scoped applications provide namespace isolation, making cleanup and promotion cleaner — staging tables, Transform Maps, and custom fields are bundled into a single deployable unit. Global scope is simpler for one-time migrations but creates cleanup overhead post-migration. For migrations where you plan to promote configuration from sub-production to production via Update Sets, a scoped application is strongly recommended because all artifacts (staging tables, Transform Maps, Transform Scripts, custom fields) can be captured in a single Update Set and promoted atomically.

Import Set API

A POST to /api/now/import/{staging_table_name} inserts data into a staging table that extends sys_import_set_row. A Transform Map then moves data from the staging table to the target table (for example, incident or cmdb_ci). Transform Scripts (onBefore, onAfter, onComplete) provide hooks for custom logic like reference field lookups and relationship creation. The insertMultiple endpoint supports batch inserts and can chain sequential loads with run_after, returning import set IDs you can log for replay and rollback. (servicenow.com)

A Transform Map entry for ticket migration includes:

• Source field (staging table column) → Target field (incident table column)
• Coalesce flag on the external ID field (u_legacy_cw_id) to enable upsert behavior — if a record with the same legacy ID already exists, it updates rather than creates a duplicate
• Choice action set to "reject" for fields where source values do not match target choice lists, preventing invalid state values from entering the incident table
• onBefore Transform Script for reference field resolution (e.g., looking up sys_user sys_id from a legacy member ID)

Table API

The Table API processes records synchronously, which will lock up the instance during a massive load. Use it for low-volume direct CRUD and edge cases, not bulk historical migration.

Rate Limiting and Throughput

Rate limiting in ServiceNow is governed by semaphores, not a fixed request-per-minute ceiling. Semaphores control how many transactions can run in parallel on each application node. The API_INT semaphore pool has a queue depth limit that varies by instance tier — typically around 50 for standard enterprise instances, but this is configurable by ServiceNow and can differ on dedicated or high-capacity instances. When all semaphore threads are busy and the queue is full, ServiceNow returns HTTP 429. Throughput depends on request complexity and duration, not just volume.

Practical throughput benchmarks: For simple record inserts via the Import Set API, enterprise instances typically sustain 300 to 500 records per minute. For imports with complex Transform Scripts that perform reference lookups or trigger business rules, throughput drops to 100 to 200 records per minute. For very large imports (100,000+ rows), split data into batches of 500 to 2,000 records and process sequentially to avoid instance resource contention. Disable unnecessary business rules during bulk transforms when your target design allows it — set the glide.script.block.server.globals system property and use conditional logic in business rules to skip during import.

Concrete example: A 75,000-ticket migration with 120,000 journal entries and 40,000 attachments typically requires 3 to 4 hours for ticket loading (at ~350 records/min with Transform Maps), 5 to 6 hours for journal entries, and 15 to 20 hours for attachment uploads (single-file-per-request constraint). Total ServiceNow load time: approximately 24 to 30 hours, typically split across 2 to 3 sequential batch runs.

Attachment API

Use the Attachment API for files, not the import table. ServiceNow uploads one file per request. The theoretical maximum attachment size is 1,024 MB, but the practical default limit for REST API uploads is typically 25 to 50 MB depending on instance configuration. The property com.glide.attachment.max_size controls this limit, and many instances ship with it set well below 1,024 MB. File types can also be restricted by the glide.attachment.extensions property. Verify your instance's actual limits before designing your attachment migration pipeline. (servicenow.com)

Storage Considerations

Migrated historical data counts against your ServiceNow instance storage allocation. A migration of 75,000 tickets with 40,000 attachments averaging 500 KB each adds approximately 20 GB of attachment storage plus table row storage. Review your storage entitlement before migration and request a temporary or permanent increase from ServiceNow if needed. Staging tables should be truncated after successful production migration to reclaim space.

For a deeper look at ServiceNow-specific migration pitfalls, see our guide on 10 ServiceNow Data Migration Challenges.

Which Migration Approach Should You Use?

For a one-time historical migration of 10,000+ records with attachments and CMDB data, custom ETL scripts or a managed service are the only viable options. iPaaS platforms are designed for ongoing bidirectional sync, not bulk historical data loading. CSV exports cannot handle binary attachments, threaded history, or relational rebuilds at scale.

Step-by-Step Migration Process

The order of operations matters. Loading records in the wrong sequence creates broken references that are expensive to fix after the fact.

Step 1: Freeze Configuration Drift

Lock Service Boards, statuses, custom fields, and agent routing during the build window. If the mapping file drifts between test and cutover, you are re-doing work. Document the freeze date and communicate it to all ConnectWise administrators.

Step 2: Extract and Stage Reference Data

Query the ConnectWise API for companies, contacts, members, boards, statuses, configuration types, and custom field metadata. Store this data in a secure relational staging database like PostgreSQL. Do not attempt to map data in memory. The staging database serves as your audit trail and enables re-extraction without hitting CW API limits again.

Step 3: Load Companies and Users

Push companies to customer_account or core_company in ServiceNow. Push contacts and members to sys_user, deduplicating by email address. Assign ITIL roles to members. Store the ConnectWise ID in a custom correlation field on every ServiceNow record (for example, u_legacy_cw_id). You will use this legacy ID to link every downstream record.

Step 4: Load CMDB Configurations (Pass One)

Extract ConnectWise Configurations from /company/configurations. Map each Configuration Type to the correct ServiceNow CI class (for example, "Server" maps to cmdb_ci_server, "Workstation" maps to cmdb_ci_computer). Push them to the appropriate cmdb_ci extended class table. During this first pass, leave the relationship fields blank. Store the original CW configuration/id in the correlation field.

Step 5: Build CMDB Relationships (Pass Two)

After all CIs exist in ServiceNow, run a second pass to create records in the cmdb_rel_ci table. Each record requires a parent sys_id, a child sys_id, and a relationship type (for example, "Depends on::Used by" or "Runs on::Runs"). Use the correlation field from Pass One to look up the correct sys_ids.

This two-pass approach prevents the most common CMDB failure mode: if you try to set a parent reference during initial CI creation, the parent CI may not exist yet, causing a null reference or a failed insert.

# Pass 2: CMDB relationship creation with retry and dead-letter handling
import time
 
dead_letter_queue = []
 
for rel in cw_configuration_relationships:
    parent_sysid = lookup_sn_ci(rel['parent_cw_id'])
    child_sysid = lookup_sn_ci(rel['child_cw_id'])
    if parent_sysid and child_sysid:
        for attempt in range(3):
            try:
                resp = sn_client.post('/api/now/table/cmdb_rel_ci', {
                    'parent': parent_sysid,
                    'child': child_sysid,
                    'type': map_relationship_type(rel['type'])
                })
                if resp.status_code == 201:
                    break
                elif resp.status_code == 429:
                    time.sleep(2 ** attempt)  # Exponential backoff
                else:
                    raise Exception(f"Unexpected status: {resp.status_code}")
            except Exception as e:
                if attempt == 2:
                    dead_letter_queue.append({
                        'rel': rel, 'error': str(e)
                    })
    else:
        dead_letter_queue.append({
            'rel': rel, 'error': 'Missing parent or child CI'
        })
 
# Process dead_letter_queue manually or in a retry batch

Step 6: Map Service Boards and Statuses

Extract boards from /service/boards and statuses from /service/boards/{id}/statuses. Create corresponding Assignment Groups in ServiceNow and build a status-to-state mapping table that normalizes board-specific statuses into ServiceNow's global State field.

Step 7: Load Tickets

Extract ConnectWise Tickets from /service/tickets with pagination. Transform board + status to category + state. Set company and contact references using sys_ids created in Step 3. Link to CMDB CIs using the correlation field. Push the payload to the ServiceNow Import Set API.

Ensure idempotency by using the ConnectWise ticket ID as the coalesce field on the staging table. If a load is interrupted and restarted, the Transform Map will update existing records rather than creating duplicates.

payload = {
    'records': [
        {
            'u_legacy_cw_id': '12345',
            'u_summary': 'VPN failure',
            'u_company_name': 'Acme',
            'u_legacy_board': 'Service Desk',
            'u_legacy_status': 'In Progress',
            'u_target_state': '2'
        }
    ]
}
 
r = requests.post(
    'https://instance.service-now.com/api/now/import/u_cw_ticket_import/insertMultiple',
    auth=('user', 'pass'),
    headers={'Accept': 'application/json'},
    json=payload
)
 
# Log the import set sys_id for rollback capability
import_set_id = r.json().get('result', [{}])[0].get('import_set')

Use Transform Maps to resolve company_name, requester, assignment group, and target task type inside ServiceNow, not in the raw load payload. Index your coalesce fields to speed up lookups — add a database index on u_legacy_cw_id in the staging table definition.

Step 8: Load Journal Entries and Attachments

Extract ConnectWise Notes from /service/tickets/{id}/notes for each ticket. Push them to the sys_journal_field table, linking them to the Incident sys_id. Internal notes map to Work Notes; external notes map to Additional Comments. Preserve the original created_by and timestamp — use ServiceNow's autoSysFields=false parameter during API insert to retain original dates. (servicenow.com)

Download binary files from /system/documents. Upload to ServiceNow via the Attachment API, linked to the correct parent record sys_id.

Step 9: Validate and Delta Sync

Run record-count reconciliation across all object types. Perform field-level spot checks. Verify CMDB relationship integrity. Then load the delta — any records created or updated in ConnectWise during the migration window.

Step 10: Promote Configuration to Production

If you built staging tables, Transform Maps, and custom fields in a sub-production instance, export them as an Update Set (or as a scoped application if you followed the scoped app approach). Promote the Update Set to production before running the production data load. Verify that all Transform Maps, Transform Scripts, and custom fields are active and correctly configured in the production instance. Run a small validation batch (100 records) against production before committing to the full load.

For guidance on deciding what data to migrate and what to leave behind, see our Help Desk Data Migration Playbook.

How Long Does a ConnectWise Manage to ServiceNow Migration Take?

A realistic timeline depends on record volume and CMDB complexity. Below is a phased estimate for a mid-size migration (50,000 tickets, 5,000 configurations, 10,000 contacts).

For larger datasets, CMDB-heavy environments, or organizations requiring multiple test loads, expect 6 to 8 weeks.

A big-bang cutover works best for organizations with fewer than 100,000 tickets and light customization. You extract the final delta on a Friday night and go live on Monday morning. A phased cutover fits global enterprises where different regional IT teams cut over on different dates. A delta-based cutover is usually the lowest-risk option because agents keep working in ConnectWise while the historical backfill runs in ServiceNow. For organizations with domain separation enabled in ServiceNow (common in shared-service or multi-tenant enterprise IT), each domain may require its own staging tables and Transform Maps scoped to the correct domain — factor this into the timeline.

Your go-live criteria must include a 99.9 percent record reconciliation match. Your rollback plan should consist of keeping ConnectWise Manage active in read-only mode for 30 days post-migration. If rollback from ServiceNow is required, delete imported records by querying on Import Set sys_id (import_set field on each imported record) rather than attempting a full instance restore. For catastrophic failures, restore from a pre-migration instance clone.

Change management matters. Communicate the cutover date 30 days in advance. Provide agents with quick reference guides showing how ConnectWise statuses map to ServiceNow states. Agents will mostly notice differences in search behavior, note visibility, and CI context — make sure migrated tickets open with enough history to be useful from day one. Run daily standups for the first week post-go-live to address routing issues.

For zero-downtime cutover strategies, see our guide on Zero-Downtime Help Desk Data Migration.

Edge Cases and Known Limitations

Some ConnectWise data requires special handling or has no target in ServiceNow.

Duplicate email addresses. ConnectWise allows multiple contacts to share the same email address. ServiceNow requires unique email addresses for the sys_user table. Deduplicate contacts in your staging database before loading them. Common strategies: append a numeric suffix to the email for secondary contacts, or merge duplicate contacts into a single sys_user record and link both ConnectWise contact IDs via a custom many-to-one mapping table.

Inline images in ticket notes. ConnectWise stores some inline images as HTML references that often export as broken links. You must parse the HTML, download the image file, upload it to the sys_attachment table, and rewrite the HTML src tag to point to the new ServiceNow attachment URL (format: /sys_attachment.do?sys_id={attachment_sys_id}).

Oversized or blocked attachments. The practical ServiceNow attachment limit via REST API is typically 25 to 50 MB (controlled by com.glide.attachment.max_size), not the theoretical 1,024 MB maximum. File types can be restricted by the glide.attachment.extensions property. If a ConnectWise ticket contains a file that exceeds the limit or is a blocked type, the ServiceNow API will reject it with HTTP 413 or a file-type validation error. Log these exceptions and move oversized files to secure storage (e.g., S3 with a reference URL stored on the incident).

Agreement and billing data. ConnectWise Manage's agreement and billing modules are MSP-specific. ServiceNow ITSM does not have an equivalent billing engine. ConnectWise time entries often tie to specific agreements and billing rates. You must map these to ServiceNow Cost Management, store them as historical reference data in a custom table, or archive them outside ServiceNow.

Workflow rules and automation. ConnectWise dispatch rules, auto-assignment logic, and escalation triggers cannot be exported via the API. These must be manually rebuilt as ServiceNow Assignment Rules, SLA Definitions, and Flow Designer flows. Document every active dispatch rule in ConnectWise before migration begins — there is no API endpoint that exports the full rule definition with conditions.

Board-level SLA configurations. SLA response and resolution targets tied to CW boards must be manually recreated in ServiceNow SLA Definitions. There is no automated path for this.

On-premises ConnectWise deployments. If ConnectWise Manage is hosted on-premises rather than cloud-hosted, the API base URL will differ from api-na.myconnectwise.net. On-premises deployments may require VPN or firewall rule changes to allow the migration server to reach the API. Authentication may also differ if the instance uses custom SSL certificates.

Validation and Testing

You cannot validate a migration by spot-checking five tickets. Every migration should include these checks before go-live:

• 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.
• 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.
• 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.
• 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.

Keep every source ID on the target record and log every Import Set run ID so rollback and replay are surgical instead of global. Store Import Set IDs in a migration log table with timestamps, record counts, and pass/fail status.

Preserving incident resolution history is a strict requirement for compliance and auditing. If an auditor requests proof of an IT security incident from two years ago, you must be able to produce the exact ticket thread, timestamps, and attachments in ServiceNow.

Build In-House or Use a Managed Service?

Build in-house when: your team has ServiceNow development experience (Import Sets, Transform Maps, Scripted REST APIs), your dataset is under 50,000 records with minimal CMDB complexity, and you have 4 to 6 weeks of engineering time available without impacting product delivery.

Use a managed service when: your dataset exceeds 100,000 records, you have multi-level CMDB relationships that require multi-pass loading, you need zero-downtime cutover with delta sync, or your organization has compliance requirements (SOC 2, HIPAA, GDPR) that mandate auditable migration processes with chain-of-custody documentation.

The hidden cost of in-house migration is not the initial build. It is the re-work. Broken CMDB relationships, orphaned CI records, and incorrect status mappings are typically discovered 2 to 4 weeks after go-live. By that point, agents have created new records in ServiceNow, and a clean re-migration requires a complex merge instead of a clean load.

ClonePartner has completed over 1,500 data migrations, including ITSM-to-ITSM moves with complex CMDB relationship mapping and custom field transformation. Our engineering team handles multi-pass CI loading, API rate limit management on both platforms, and zero-downtime cutover with delta sync — so your IT team never misses a ticket during the cutover.

Frequently Asked Questions

Can ConnectWise Manage ticket history be preserved in ServiceNow?

Yes. Ticket notes — both internal and external — can be migrated as Journal Entries on the ServiceNow incident record, preserving the original author, timestamp, and content. Work Notes and Additional Comments maintain the full conversation thread. Original ticket creation dates and resolution dates can be set using ServiceNow's autoSysFields=false parameter during API insert. Attachments must go through the Attachment API linked to the correct parent record.

How do ConnectWise Service Boards map to ServiceNow?

ConnectWise Service Boards have no direct equivalent in ServiceNow. Each board must be decomposed into four constructs: Assignment Groups (for team routing), Categories and Subcategories (for ticket classification), SLA Definitions (for response targets), and Assignment Rules (for auto-routing). The board-specific status workflows must be normalized into ServiceNow's global incident State field (New=1, In Progress=2, On Hold=3, Resolved=6, Closed=7).

What are the biggest risks of this migration?

The three most common failure modes are: (1) orphaned CMDB CIs caused by single-pass loading without relationship reconstruction in cmdb_rel_ci, (2) incorrect status mapping where ConnectWise board-specific statuses are flattened into the wrong ServiceNow incident state, and (3) API throttling on the ConnectWise side (HTTP 429 with no Retry-After header) causing incomplete data extraction. All three are preventable with multi-pass loading, a documented status mapping matrix, and exponential backoff with resumable checkpoints.

How much does a ConnectWise Manage to ServiceNow migration cost?

Cost depends on record volume, number of custom fields, CMDB complexity, and whether attachments are in scope. 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 (typically 160 to 320 hours of ServiceNow developer time) and re-work.

Does migrated data affect ServiceNow licensing or storage?

Yes. Migrated historical records count toward your ServiceNow instance storage allocation. Attachments are the primary storage driver — 50,000 attachments at 500 KB average = 25 GB. Additionally, every ConnectWise member migrated as a sys_user with an ITIL role consumes a ServiceNow ITIL license. If you are migrating members who are no longer active, set them as inactive (active=false) in ServiceNow to avoid unnecessary license consumption. Verify storage and licensing entitlements with your ServiceNow account team before migration.