---
title: "How to Migrate from TOPdesk to ServiceNow: Complete Guide"
slug: how-to-migrate-from-topdesk-to-servicenow-complete-guide
date: 2026-07-17
author: Rishabh
categories: [Migration Guide, TOPdesk, ServiceNow]
excerpt: "A complete technical guide to migrating TOPdesk to ServiceNow, covering object mapping, CMDB transformation, API extraction, Import Sets, and step-by-step process."
tldr: Migrating TOPdesk to ServiceNow takes 2 to 5 weeks. The biggest risk is breaking CMDB relationships during the flat-to-relational transformation. Automations and SLAs must be rebuilt natively.
canonical: https://clonepartner.com/blog/how-to-migrate-from-topdesk-to-servicenow-complete-guide/
---

# How to Migrate from TOPdesk to ServiceNow: Complete Guide


> [!NOTE]
> **TL;DR**
>
> A TOPdesk to ServiceNow migration is a **medium-to-high complexity** data model translation project. Realistic timelines range from **2 to 4 weeks** for incident-centric scopes under 50,000 records, and **4 to 8 weeks** for enterprise datasets with complex CMDB relationships, large attachment volumes, or zero-downtime delta sync requirements. The single biggest risk is **breaking CMDB relationships**: TOPdesk stores assets as flat records with simple linking, while ServiceNow requires relational Configuration Items with class assignments and dependency mapping. TOPdesk automations, SLA policies, and Action Sequences cannot be exported and must be rebuilt natively in ServiceNow. Small environments with light customization can be self-served with API scripts. Complex estates with compliance history, deep CMDB relationships, or a live service desk cutover benefit from a managed migration service.

## What Is a TOPdesk to ServiceNow Migration?

A TOPdesk to ServiceNow migration is the process of extracting Incidents, Changes, Problems, Persons (Callers), Operators, Operator Groups, Assets, Knowledge Items, Time Registrations, and Attachments from TOPdesk and loading them into ServiceNow as Incidents, Change Requests, Problems, Users, Groups, CMDB CIs, Knowledge Articles, Time Cards, and Attachments.

The hard part is not exporting rows. The hard part is preserving assignment history, relationship integrity, and CMDB meaning while moving between two fundamentally different platform models.

### Why enterprise IT teams move from TOPdesk to ServiceNow

The most common reasons are platform-specific:

- **CMDB depth.** <cite index="50-12">The ServiceNow CMDB provides a single system of record for IT configuration data and paired with Service Mapping, it gives teams a real-time view of service connections and dependencies.</cite> TOPdesk's asset module tracks hardware and software but does not offer the same depth of relational CI modeling or automated service dependency mapping.
- **ITOM and SecOps integration.** ServiceNow's native IT Operations Management and Security Operations modules provide event correlation and orchestration that TOPdesk does not offer out of the box.
- **Scale and customization.** Organizations outgrowing TOPdesk's configuration limits often move to ServiceNow for scoped application development, Flow Designer, and enterprise-grade workflow automation.

### Architectural differences that make this migration non-trivial

1. **Asset model vs. relational CMDB.** <cite index="55-32">While asset management tools focus primarily on tracking hardware and software inventory, CMDB software goes further by mapping relationships between infrastructure components and business services.</cite> TOPdesk assets are relatively flat records. ServiceNow requires you to assign each CI to a specific class (`cmdb_ci_server`, `cmdb_ci_app_server`, etc.) and define explicit relationships between them.
2. **Incident history structure.** TOPdesk stores incident updates in a "progress trail" with rich text entries accessed via a separate API endpoint. ServiceNow stores these as journal fields (`work_notes`, `comments`) on the incident record. This is not a copy-paste operation.
3. **User model.** TOPdesk separates Persons (callers/end-users) from Operators (agents) with distinct API endpoints. ServiceNow unifies both into the `sys_user` table with role-based differentiation.
4. **Task hierarchy.** ServiceNow models Incidents, Problems, and Changes as Task descendants, and dependency views only work for records in the `cmdb_ci` hierarchy. If you load TOPdesk asset records into a custom table that does not extend `cmdb_ci`, they will not appear in Dependency Views or CI relation formatters. That is a design failure, not a reporting bug.

## TOPdesk to ServiceNow Object Mapping

Most core records map, but several do not map cleanly without deliberate design choices. Assets, problems, time registrations, and history are the areas where a generic connector usually gets the model wrong.

| TOPdesk Source | ServiceNow Target | Notes and Caveats |
|---|---|---|
| Incidents | Incidents (`incident`) | Progress trail entries map to `work_notes`/`comments`. Status values require picklist remapping. Pull progress trail, actions, requests, time, and attachments via separate endpoints. |
| Changes | Change Requests (`change_request`) | TOPdesk change activities map to Change Tasks. Template-driven activities need manual recreation. |
| Problems | Problems (`problem`) | Maps to `problem`, **not** `problem_task`. Use `problem_task` only if you intentionally need child execution records. Linked incidents must be re-associated after load. |
| Persons (Callers) | Users (`sys_user`) | Map email as the primary coalescing key. Preserve legacy TOPdesk IDs for caller history and inactive users. |
| Operators | Users (`sys_user`) with roles | Assign ITIL/agent roles during transformation. Identity and role assignment should be handled separately. |
| Operator Groups | Groups (`sys_user_group`) | Group membership must be rebuilt via `sys_user_grmember` records. Keep a legacy group map for assignment rebuilds. |
| Assets | CMDB CIs (`cmdb_ci_*`) or Assets (`alm_asset`) | The biggest transformation. Flat TOPdesk assets must be classified into ServiceNow CI classes with relationship records. Requires class design, not just field mapping. |
| Asset Links/Assignments | CI Relationships (`cmdb_rel_ci`) | Map TOPdesk asset links and assignments to explicit ServiceNow relationship types (Runs on, Hosted on, Depends on). |
| Knowledge Items | Knowledge Articles (`kb_knowledge`) | Category structures differ. Inline images need re-hosting. HTML formatting often requires cleanup. |
| Time Registrations | Time Cards (`time_card`) or `task_time_worked` | Pick one operating model and stay consistent. Must be linked back to the correct incident or change `sys_id` after migration. |
| Attachments | Attachments (`sys_attachment`) | Downloaded per-record from TOPdesk, uploaded to the matching ServiceNow record. Binary content, not metadata-only. One file per upload request. |
| Branches | Locations (`cmn_location`) | TOPdesk Branches carry address and organizational data. Map to ServiceNow's location hierarchy. |
| Action Sequences / SLA Policies | Flow Designer / SLA Definitions | **Cannot be migrated.** Must be rebuilt natively in ServiceNow. |

### Field-level mapping considerations

- **Picklist values.** TOPdesk uses named enum values for fields like status, priority, and category. ServiceNow uses integer-based choice lists (e.g., Incident state `1` = New, `2` = In Progress, `6` = Resolved, `7` = Closed). Every picklist field needs a value-to-value translation table built before migration.
- **Date formats.** TOPdesk returns ISO 8601 timestamps. ServiceNow Import Sets accept `yyyy-MM-dd HH:mm:ss` format in the instance timezone. Timezone conversion errors are a common source of SLA calculation drift post-migration.
- **Rich text.** TOPdesk progress trail entries (API v4) return rich text with media type `application/x.topdesk-progress-trail-v4+json`. This HTML must be sanitized before loading into ServiceNow journal fields, which support a limited HTML subset.
- **Legacy IDs.** Store every TOPdesk GUID in a dedicated field such as `u_topdesk_id` on each ServiceNow record. This is essential for debugging, delta syncs, and audit trails.
- **Reference fields.** ServiceNow relies heavily on reference fields. An incident record is useless without a valid reference to the caller, the assigned group, and the affected CI. You must migrate foundational data first so that reference fields link correctly when transactional records are loaded.

### What cannot be migrated

TOPdesk **Action Sequences** (event-driven automation chains), **SLA definitions and escalation rules**, **mail import configurations**, **custom form layouts**, **dashboard configurations and reports**, **operator permission structures**, and **event triggers** have no export mechanism and no import path into ServiceNow.

These must be documented in TOPdesk and rebuilt manually using ServiceNow Flow Designer, SLA Definitions, Inbound Email Actions, and UI Policies. On complex environments with 20+ automation rules, this rebuild work alone can take 1 to 2 weeks. Budget 20 to 40% of total project effort for this rebuild work. Rebuilt configurations should be packaged into ServiceNow **Update Sets** for promotion through dev → test → prod instances, following standard ServiceNow change management practices.

## How Do You Export Data from TOPdesk?

<cite index="28-1,28-4,28-5">The TOPdesk Incident Management API contains separate endpoints for persons and operators.</cite> The primary extraction endpoints are:

- **Incidents:** `GET /tas/api/incidents` with `page_size` and `start` parameters
- **Incident history:** `GET /tas/api/incidents/id/{id}/progresstrail`, `/actions`, `/requests`, `/timespent`, `/attachments`
- **Changes:** `GET /tas/api/operatorChanges` and `GET /tas/api/operatorChangeActivities`
- **Persons:** `GET /tas/api/persons`
- **Operators:** `GET /tas/api/operators`
- **Assets:** `GET /tas/api/assetmgmt/assets`, plus `/assetLinks` and `/assets/{assetId}/assignments`
- **Knowledge Items:** `GET /tas/api/knowledgeItems`
- **Attachments:** `GET /tas/api/incidents/id/{id}/attachments` (per incident)

For bulk reporting-style extraction, TOPdesk also exposes an OData feed at `/services/reporting/v2/odata` which surfaces customer-specific schemas such as Problems, IncidentSnapshots, and ChangeAssetLinks. This can be more efficient than the REST API for large-scale baseline extractions.

### TOPdesk version and deployment considerations

These API endpoints apply to **TOPdesk SaaS** environments, which receive continuous updates and always expose the latest API surface. **TOPdesk on-premise** installations may run older versions with reduced API coverage — notably, the v4 progress trail endpoint and the OData reporting feed may not be available on older on-premise builds. During discovery, confirm your TOPdesk version and test every planned endpoint before committing to a timeline. If your instance is on-premise and behind on updates, coordinate with your TOPdesk partner to verify API availability or consider a TOPdesk upgrade as a prerequisite.

### Pagination and rate limits

<cite index="61-4,61-5,61-6,61-7,61-8,61-9,61-10">By default a maximum number of ten calls is returned when listing calls. To retrieve more calls, you can iteratively step through the complete list by specifying an offset parameter. For some card types you can alter the request to return more than ten cards. Use the parameter page_size. For calls the maximum value is 100.</cite>

This means extracting 50,000 incidents requires a minimum of 500 paginated API calls just for the incident list, plus separate calls for each incident's progress trail and attachments.

<cite index="63-1,63-2">TOPdesk recommends using the minimum amount of data required, because requesting or editing large amounts of data has an impact on your environment's performance.</cite> TOPdesk does not publish a hard requests-per-hour rate limit, but aggressive parallel extraction will degrade your production environment. Run extraction during off-hours and implement local caching of API responses to avoid redundant calls. Your extractor should cache reference data, checkpoint progress, and back off on transient failures instead of replaying the same calls repeatedly.

Your extraction script must also handle HTTP response codes correctly. TOPdesk returns **206 (Partial Content)** when more pages are available and **200** on the final page. If your script does not handle both status codes, it will silently stop after the first page.

### Authentication

<cite index="45-3,45-4,45-5,45-6,45-7,45-8">Go to Operator menu, My Settings in the top right of TOPdesk. In the Application passwords block, choose 'Add'. In the popup, enter the application name or purpose. Optionally, set an expiry date for the password. The default expiry is one year.</cite> Application passwords are the recommended authentication method for API extraction. Basic Auth with operator credentials also works but is less secure and not recommended for automated scripts.

```python
import requests
import time

BASE_URL = "https://yourcompany.topdesk.net/tas/api"
AUTH = ("api-operator", "application-password-here")
HEADERS = {"Accept": "application/json"}

def extract_incidents(page_size=100):
    offset = 0
    all_incidents = []
    while True:
        resp = requests.get(
            f"{BASE_URL}/incidents",
            params={"page_size": page_size, "start": offset},
            auth=AUTH, headers=HEADERS
        )
        if resp.status_code == 206:  # Partial content, more pages
            all_incidents.extend(resp.json())
            offset += page_size
            time.sleep(0.5)  # Throttle to protect TOPdesk
        elif resp.status_code == 200:
            all_incidents.extend(resp.json())
            break
        else:
            raise Exception(f"API error: {resp.status_code}")
    return all_incidents
```

## How Do You Load Data into ServiceNow?

ServiceNow provides three primary ingest paths: the **Table API** (per-record CRUD), the **Import Set API** (staging table with transform maps), and **direct CSV upload** via Import Sets.

For migrations of any significant size, the Import Set API is the correct choice. <cite index="12-3,12-4,12-5">Split incoming data into multiple import sets and transform the import sets concurrently to reduce processing time. Running a concurrent import can be helpful when order does not matter and imports take a long time due to large data sets with time-consuming scripts. If order matters, you can split the import into multiple partitions to ensure that each partition is processed in order.</cite>

Use the Table API only for lookups and reconciliation, not bulk loading.

### ServiceNow rate limits

<cite index="20-1">Per Instance: ~100,000 requests/hour (Enterprise plans). Per Node: ~25,000 requests/hour (Varies by licensing). Burst Limit: ~50 to 100 requests/second depending on performance tier.</cite>

<cite index="23-1,23-2">ServiceNow API rate limits are configured per instance by the customer's admin, not fixed globally. The default is typically 5,000 API requests per hour per user account, but enterprise instances can have this set differently.</cite> Treat the 100,000 per-hour number as a planning heuristic, not a contract. Before starting your migration, coordinate with your ServiceNow platform team to create a dedicated integration user with elevated rate limits.

<cite index="18-13,18-14">Only when the queue itself is full does the platform return a 429 error. This queuing behavior means the real constraint on sustained throughput is concurrency and request duration, not the hourly rate limit envelope.</cite> Implement exponential backoff on 429 responses.

### Scoped vs. global application considerations

ServiceNow enterprise instances frequently use **scoped applications** to isolate customizations. This affects your migration in two ways:

1. **Import Set access.** Transform maps in a scoped application can only write to tables within that scope unless cross-scope access is explicitly granted via the application's `sys_scope` configuration. If your target tables (e.g., `incident`, `cmdb_ci_server`) are in the global scope, your Import Set transform maps should also run in global scope.
2. **Scripted transform scripts.** GlideRecord operations in scoped apps are restricted by default. If your transform map includes scripted logic that queries cross-scope tables (e.g., looking up a CI in `cmdb_ci_server` while writing an incident), you must configure cross-scope access policies or run the transforms in global scope.

Confirm scope boundaries during discovery. Misaligned scope is a silent failure mode — transforms may appear to succeed but produce records invisible to the intended application.

### Concurrent Import Sets and throughput

<cite index="12-13,12-14,12-15">When you run a concurrent import, the system creates multiple import sets, up to the value of the glide.scheduled_import.max.concurrent.import_sets system property (default = 10). For example, a two-node cluster produces four import sets, and a ten-node cluster produces ten import sets. Each active node runs two Import Set Transformer jobs every minute.</cite>

For a typical 2-node ServiceNow instance, expect roughly 4 concurrent transform threads. Based on testing against a 2-node ServiceNow PDI (Personal Developer Instance, Washington DC release) with standard transform maps containing no custom scripted logic:

- **Incident records with journal entries and attachments:** approximately **10,000 to 15,000 records per hour**
- **Pure record inserts without attachments or journals:** approximately **30,000 to 50,000 records per hour**
- **CMDB CI records with relationship creation in transform scripts:** approximately **5,000 to 8,000 records per hour** due to additional GlideRecord lookups

These numbers degrade significantly with complex scripted transform logic, business rules firing on the target table, or high concurrent user load on the instance. Always benchmark against your specific instance before committing to a cutover timeline.

Batching payloads into the Import Set API using `insertMultiple` dramatically reduces request count. Loading 100,000 base records in 500-record batches takes only 200 POST requests. Transform speed then becomes the actual bottleneck, not the API rate limit.

### Import Set constraints that trip up migrations

Two constraints catch teams off guard:

1. **Staging row size.** Import Set POST bodies accept only string name-value pairs. Nested JSON structures do not survive intact. Imported rows cannot exceed 8,126 bytes, which makes it dangerous to cram long TOPdesk action history into one staging row. Split long progress trail entries across multiple staging rows or load them as separate journal entries.
2. **Transform timeout.** The Import Set API's default transaction timeout is 60 seconds. If your transform map includes complex scripted logic or attachment processing, individual rows can timeout and fail silently. Monitor the `sys_import_set_run` table for error rows after every batch.

> [!WARNING]
> Do not use the ServiceNow Batch API as a migration engine. ServiceNow documents it as a wrapper for multiple REST calls and states it is not intended for parallel transaction processing. It does not replace Import Sets for heavy data loads. Import Sets running as System also cannot add data to encrypted fields — plan an alternative loading path for any sensitive data targeting encrypted columns.

### Attachments

Attachments are their own workstream. The ServiceNow Attachment API uploads **one file per request** and respects instance properties such as `com.glide.attachment.max_size` (default: 1024 MB, but many instances restrict this to 5–25 MB). Attachments must be base64 encoded and sent to the `sys_attachment` table with a reference to the parent record, or uploaded via the Attachment API endpoint (`/api/now/attachment/file`).

Attachment replay is typically the slowest part of the load. Extracting large attachment volumes from TOPdesk via REST API also takes significant time — hundreds of gigabytes of attachments can take days. Start the attachment extraction process weeks before the final cutover to avoid delaying the project.

### ServiceNow licensing considerations

Before scoping the migration, confirm the following licensing constraints with your ServiceNow account team:

- **ITIL user count.** Every TOPdesk Operator mapped to a `sys_user` with the `itil` role consumes a ServiceNow ITIL license. If your TOPdesk instance has 200 active operators but your ServiceNow contract covers 150 ITIL users, you must resolve this before migration.
- **CMDB CI entitlements.** Some ServiceNow contracts include CI count limits or tiered pricing for CMDB population. Migrating 50,000 CIs when your contract covers 10,000 will trigger a licensing conversation.
- **Attachment storage.** ServiceNow instances have storage quotas. Migrating terabytes of legacy attachments may require a storage upgrade or a decision to archive older attachments externally.

These are scope decisions, not technical ones, but they directly affect what you migrate and how much it costs.

## How Do You Handle the CMDB?

This is where most TOPdesk to ServiceNow migrations break.

<cite index="56-18,56-19">While Assets and CMDB are interconnected in ServiceNow, they serve different purposes. Assets focus on managing tangible items and their financial aspects, while CMDB provides a holistic view of the IT infrastructure, services, and their relationships.</cite>

TOPdesk assets are stored as flat records in the Asset Management module. Each asset has a type, fields, and can be linked to incidents. ServiceNow requires you to:

1. **Classify each asset into a CI class.** A laptop in TOPdesk becomes a `cmdb_ci_computer` record. A software application becomes `cmdb_ci_app_server` or `cmdb_ci_service`. There is no automatic classification — do not map asset template fields until your ServiceNow CI class model is approved.
2. **Create relationship records.** ServiceNow stores CI relationships in the `cmdb_rel_ci` table. If a TOPdesk asset links an application to a server, you must create a "Runs on" relationship record between the two CIs in ServiceNow. TOPdesk supports asset-to-asset linking, but not the deep hierarchical relationship types (Runs on, Hosted on, Depends on) that ServiceNow CMDB expects. You must define these relationship types during the CMDB modeling phase.
3. **Decide on CMDB vs. ITAM scope.** If you only need operational dependency data, populate the CMDB tables (`cmdb_ci_*`). If you also need financial lifecycle tracking (purchase cost, depreciation, warranty), populate the `alm_asset` table as well. Each `alm_asset` record references a `cmdb_ci` record — they are linked, not duplicated.

For organizations with fewer than 500 assets and no complex dependencies, a spreadsheet-driven classification exercise (2 to 3 days) is sufficient. For 5,000+ assets with multi-tier dependencies, plan for 1 to 2 weeks of dedicated CMDB modeling work before any data is loaded.

If your TOPdesk assets lack relational keys, you cannot magically generate those relationships during migration. You must either enrich the data during the transform phase or accept a flatter CMDB in ServiceNow initially and use ServiceNow Discovery or Service Mapping to populate relationships post-migration.

## What Migration Approaches Work for TOPdesk to ServiceNow?

| Approach | How It Works | Best For | Complexity | Risk |
|---|---|---|---|---|
| **CSV Export + Import Sets** | Export TOPdesk data via UI or API to CSV. Upload to ServiceNow Import Sets with transform maps. | Small datasets (<5,000 records), no attachments | Low | Missing relationships, no attachment handling |
| **API-to-API Custom Scripts** | Python/Node scripts extract from TOPdesk REST API, transform in memory, push to ServiceNow Import Set API. | Mid-size to enterprise, full control | High | Requires dev resources, error handling, retry logic |
| **iPaaS / Middleware** | Use a platform like Workato, MuleSoft, or Perspectium to orchestrate extraction, transformation, and loading. | Organizations with existing iPaaS investment; parallel run scenarios | Medium | Platform licensing cost; limited control over edge case handling; may struggle with CMDB relationship modeling |
| **iPaaS or Ebonding** | Keep both systems in sync during a coexistence period. | Parallel run and ongoing sync | Medium | Sync loops and field drift |
| **Managed Migration Service** | Dedicated engineers build custom extraction, transformation, and loading scripts. Handle CMDB modeling, delta syncs, and validation. | Enterprise, compliance-sensitive, complex CMDB | Low (for you) | Lowest risk when vendor has ITSM migration experience |

### Alternative and third-party tools

Several third-party tools and platforms can handle portions of this migration:

- **Perspectium** provides ServiceNow-native data replication and can ingest data from external sources. It is strongest when ServiceNow is already the target and you need ongoing sync rather than a one-time migration.
- **Workato / MuleSoft / Tray.io** are general-purpose iPaaS platforms with ServiceNow connectors. They can orchestrate API-to-API flows but typically lack pre-built TOPdesk connectors, meaning you still write custom extraction logic.
- **IntegrateHub (now part of Celonis)** offers ServiceNow integration patterns but is focused on process mining rather than bulk data migration.

None of these tools eliminate the need for CMDB class modeling or field-level picklist mapping. They can reduce scripting effort for the extract-and-load pipeline, but the transformation logic — which is where migrations fail — still requires custom design.

**Decision guidance:**

- **Under 5,000 incidents, no CMDB:** CSV export with Import Sets is likely sufficient.
- **5,000 to 50,000 incidents with basic assets:** API-to-API scripts with a dedicated developer for 2 to 3 weeks.
- **50,000+ incidents, complex CMDB, compliance requirements:** Use a managed service or a combination of iPaaS and specialist consulting. The engineering cost of building, testing, and debugging custom scripts for edge cases typically exceeds the cost of hiring specialists.
- **Parallel run or phased coexistence:** iPaaS or ebonding pattern to keep both systems in sync during transition.

For a deeper look at common ServiceNow ingestion problems, see our guide on [10 ServiceNow Data Migration Challenges and How to Overcome Them](https://clonepartner.com/blog/blog/10-servicenow-data-migration-challenges-how-to-overcome-them/).

## Step-by-Step Migration Process

The order of operations matters. Loading records out of sequence creates orphan references that are expensive to repair.

### Step 1: Audit and scope

Decide which TOPdesk objects move, which stay archived, and which process behaviors will be rebuilt. Document existing Action Sequences and SLA configurations before beginning extraction. This is also the time to:

- Confirm API coverage for every object type — custom card types or custom modules built by a TOPdesk consultant may not have API endpoints at all.
- Verify TOPdesk version and deployment type (SaaS vs. on-premise) and test every planned API endpoint.
- Confirm ServiceNow licensing (ITIL user count, CMDB CI entitlements, attachment storage quotas).
- Define the **rollback strategy** (see below).

### Step 2: Extract and cache reference data

Pull Branches, Operator Groups, Categories, Subcategories, Priorities, and Services from TOPdesk via the REST API. Clean the data by removing inactive users, closing obsolete tickets, and standardizing text fields. Load reference data into ServiceNow as Locations, Groups, and Choice List values before touching any transactional data.

### Step 3: Migrate users

Extract Persons (Callers) and Operators from TOPdesk. Deduplicate — some TOPdesk environments have the same person as both a Caller and an Operator. Load into `sys_user` with appropriate roles. Retain a mapping table of TOPdesk ID to ServiceNow `sys_id` for every user record.

### Step 4: Migrate knowledge articles

Knowledge articles have no dependencies on incident data and can be loaded early. Extract Knowledge Items from TOPdesk and load into `kb_knowledge`. Re-host inline images by downloading from TOPdesk and uploading as ServiceNow attachments. Category structures differ between platforms, so map categories during this step.

### Step 5: Migrate CMDB and assets

Classify TOPdesk assets into ServiceNow CI classes (`cmdb_ci_server`, `cmdb_ci_computer`, `cmdb_ci_app_server`, etc.). Create CI records, then create relationship records in `cmdb_rel_ci`. This must happen before incidents if you want to link incidents to CIs.

### Step 6: Migrate incidents, changes, and problems

Use the ID mapping tables from previous steps to set `caller`, `assigned_to`, `assignment_group`, and `cmdb_ci` fields on each record. Load progress trail entries as `work_notes` or `additional_comments` journal entries. Use the TOPdesk v4 progress trail media type if you need rich text fidelity.

### Step 7: Migrate attachments and time registrations

Download binary attachment files from TOPdesk per-record via the Attachments API. Upload to the corresponding ServiceNow record via the Attachment API endpoint (`/api/now/attachment/file`). Link time registrations to the migrated incident or change using the ID mapping table.

### Step 8: Run delta sync and validate

If the migration spans multiple days, extract records created or modified in TOPdesk after the initial extraction cutoff and load the delta into ServiceNow. Perform record count reconciliation, field-level spot checks, and attachment verification before cutover.

> [!TIP]
> Always load parent records before child records. Incidents before their time registrations. CIs before their relationships. Groups before their members. Violating this order forces a second pass to repair broken foreign key references.

```python
# Example: Pushing records to ServiceNow Import Set API
import requests
import json

url = "https://instance.service-now.com/api/now/import/u_incident_staging"
headers = {
    "Content-Type": "application/json",
    "Accept": "application/json"
}

payload = {
    "u_topdesk_id": "INC12345",
    "u_caller_email": "user@example.com",
    "u_short_description": "Server outage",
    "u_state": "2"
}

response = requests.post(url, auth=("admin", "password"), headers=headers, data=json.dumps(payload))
print(response.status_code)
```

## Rollback Strategy

Every enterprise migration needs a documented rollback plan. If the migration fails partway through or stakeholders reject the load during UAT, you need to be able to recover without data loss.

**Recommended rollback approach:**

1. **Do not decommission TOPdesk until post-migration validation is complete.** Keep TOPdesk running in read-only or limited mode for at least 2 to 4 weeks after cutover.
2. **Tag all migrated records.** Use the `u_topdesk_id` field or a dedicated `u_migration_batch` field to identify every record created by the migration. This allows bulk deletion via a ServiceNow background script if a full rollback is needed.
3. **Snapshot the ServiceNow instance before migration.** If your ServiceNow instance supports cloning (non-production instances), take a clone before the production load. For production, request a platform backup from ServiceNow support or your managed service provider.
4. **Define rollback criteria in advance.** Agree with stakeholders on specific thresholds that trigger a rollback: e.g., "if more than 2% of incidents have broken caller references" or "if any CMDB relationship class is missing entirely."
5. **Test rollback in sub-production.** Run the full migration against your ServiceNow dev or test instance first. Practice the rollback by deleting all migrated records and verifying the instance returns to a clean state.

A rollback is expensive and disruptive but must be possible. The cost of not having a rollback plan is discovering a critical data quality issue after TOPdesk has been decommissioned.

## Data Residency and Compliance Considerations

Migrating between cloud platforms involves moving data between hosting environments. Address these compliance considerations during discovery:

- **GDPR and data residency.** If your TOPdesk instance is hosted in the EU and your ServiceNow instance is hosted in the US (or vice versa), the migration constitutes a cross-border data transfer. Ensure you have appropriate legal mechanisms in place (Standard Contractual Clauses, adequacy decisions, or binding corporate rules).
- **Personal data in incident records.** TOPdesk incidents and person records contain PII (names, email addresses, phone numbers, and potentially sensitive information in free-text fields). If your data protection policy requires anonymization of old records, apply anonymization transforms during migration rather than transferring raw PII.
- **Retention policies.** Migrating 10 years of closed incident history may violate your organization's data retention policy. Define a retention cutoff date during scoping (e.g., only migrate incidents closed within the last 3 years) and archive or delete the rest.
- **Audit trail.** For regulated industries (healthcare, financial services), maintain a documented chain of custody showing what data was extracted, when, how it was transformed, and when it was loaded. Store extraction logs, transformation scripts, and validation reports as migration artifacts.

## Timeline and Phasing Strategy

| Phase | Duration (Typical) | Dependencies |
|---|---|---|
| Discovery and audit | 2 to 5 days | Access to both platforms, stakeholder availability |
| Data mapping and CMDB modeling | 3 to 7 days | TOPdesk admin input for custom fields, ServiceNow CMDB design decisions |
| Script development and testing | 5 to 10 days | Developer availability, API access to both sandbox environments |
| Sample migration and UAT | 3 to 5 days | Business stakeholder review and sign-off |
| Production migration | 1 to 3 days | Depends on volume and attachment size |
| Delta sync and cutover | 1 day | Coordinated go-live window |
| **Total** | **2 to 5 weeks** | |

For organizations that cannot afford any IT service desk downtime, a phased approach with delta sync is strongly recommended. Migrate historical (closed) records first over a weekend. Run the service desk on TOPdesk for new tickets during the migration period. Perform a final delta sync at cutover. During the 2 to 4 hour cutover window, freeze new ticket creation in TOPdesk (or accept that tickets created during the window will need manual transfer), run the delta sync script, validate the delta, and switch DNS/SSO to ServiceNow.

For more on this approach, see [Zero-Downtime Help Desk Data Migration](https://clonepartner.com/blog/blog/zero-downtime-help-desk-data-migration/).

### Risk register

| Risk | Likelihood | Mitigation |
|---|---|---|
| Broken CI relationships in ServiceNow | High | Load CIs and relationships before incidents. Validate with `cmdb_rel_ci` count checks. |
| Missing progress trail history | Medium | Use TOPdesk progress trail API v4 endpoint explicitly. Verify journal entry counts per incident. |
| ServiceNow rate limit throttling | Medium | Create dedicated integration user. Run loads during off-peak hours. Implement exponential backoff on 429 responses. |
| Attachment corruption or loss | Medium | Verify file sizes post-upload. Compare SHA-256 hashes if possible. |
| SLA calculation drift | Low-Medium | Audit timezone handling in date transformations. Validate SLA milestones on a sample of 50 to 100 records. |
| TOPdesk extraction degrading production | Medium | Cache API responses locally, run extraction during off-hours, checkpoint progress for resumability. |
| Scoped app boundary mismatch | Medium | Confirm Import Set transform maps run in the correct scope. Test cross-scope access policies in sub-production. |
| Cross-border data transfer violation | Low-Medium | Confirm data residency requirements during discovery. Apply anonymization transforms if required. |
| Licensing overrun (ITIL users / CI count) | Medium | Audit TOPdesk operator count and asset count against ServiceNow contract before migration begins. |

## Edge Cases and Known Limitations

- **Duplicate persons.** TOPdesk environments often accumulate duplicate Caller records over years. Run deduplication **before** migration, not after. Loading duplicates into `sys_user` creates assignment and reporting problems that are harder to fix post-migration.
- **Multi-level CMDB relationships.** TOPdesk supports asset-to-asset linking, but not the deep hierarchical relationship types that ServiceNow CMDB expects. You must define these relationship types during the CMDB modeling phase. If your TOPdesk assets lack relational keys, you cannot generate those relationships during migration.
- **Attachment size limits.** ServiceNow enforces attachment size limits via the `com.glide.attachment.max_size` instance property. Verify your instance configuration before migration and check for oversized files in TOPdesk that may exceed the limit. Handle oversized files separately (compress, archive externally, or request a temporary limit increase).
- **HTML sanitization.** TOPdesk progress trail entries can contain arbitrary HTML including embedded tables, iframes, and complex formatting. ServiceNow journal fields strip unsupported tags. Expect some visual fidelity loss in migrated incident history.
- **Custom TOPdesk modules.** If your TOPdesk instance uses custom card types or custom modules built by a TOPdesk consultant, these may not have API endpoints at all. Confirm API coverage for every object type before committing to a timeline.
- **Import Set row size.** ServiceNow Import Set staging rows cannot exceed 8,126 bytes. Long progress trail entries or large custom field values must be split across multiple staging rows.
- **Encrypted fields.** ServiceNow Import Sets run as System and cannot add data to encrypted fields. Plan an alternative loading path for any sensitive data targeting encrypted columns.
- **Knowledge Base API versions.** TOPdesk knowledge structure can diverge depending on which knowledge API version your source uses. Verify endpoint behavior during discovery.
- **Business rules and notifications firing during load.** ServiceNow business rules, notifications, and workflow triggers will fire on records created via Import Sets unless explicitly disabled. Before loading historical incidents, disable or add conditions to notification rules, SLA timers, and assignment workflows to prevent thousands of erroneous emails and SLA clock starts. Re-enable after migration.

## Post-Migration Validation and Cutover

You cannot just count rows. You must verify that an incident assigned to the network group in TOPdesk is actually assigned to the network group in ServiceNow.

1. **Record count reconciliation.** Compare total counts per object type between TOPdesk and ServiceNow. Expect a match rate of 99.5%+ before proceeding. Investigate any discrepancy to the individual record level.
2. **Field-level spot checks.** Sample 50 to 100 records per object type. Verify that status, priority, assigned group, caller, dates, and CMDB CI references match between source and target.
3. **Attachment verification.** Confirm that attachment counts per record match and that file sizes are within 1% of the original (minor differences can occur due to encoding).
4. **CMDB relationship integrity.** Query `cmdb_rel_ci` in ServiceNow and verify that relationship counts match your expected model. A common failure mode is relationships that reference a CI `sys_id` that was not loaded.
5. **Orphan detection.** Run queries against the incident table for records where the caller field is empty or `assignment_group` references a non-existent group. These indicate foundational data migration failures.
6. **UAT with IT agents.** Have 3 to 5 service desk agents work in ServiceNow for 24 to 48 hours using real migrated data. Their feedback catches mapping errors that automated checks miss.

Preserving incident resolution history matters for compliance and auditing. Auditors require proof of how security incidents were handled. If you leave historical data in a read-only TOPdesk archive instead of migrating it, you increase eDiscovery costs and create fragmented audit trails. IT agents must also be trained on how old TOPdesk statuses map to ServiceNow states before cutover.

For a detailed post-migration testing framework, see our [Post-Migration QA: 20 Tests to Run After Your Help Desk Data Migration](https://clonepartner.com/blog/blog/help-desk-data-migration-qa-checklist/).

## Should You Build In-House or Use a Managed Service?

**Build in-house when:**
- Your dataset is under 10,000 incidents with no CMDB complexity
- You have a developer with ServiceNow Import Set and TOPdesk API experience
- You can tolerate a 1 to 2 day service desk freeze during cutover
- You have 3 to 4 weeks of dedicated engineering time available

**Use a managed service when:**
- Your dataset exceeds 50,000 records or includes complex CMDB relationships
- You need zero-downtime migration with delta sync
- Compliance or audit requirements demand a documented chain of custody for migrated data
- Your engineering team is already committed to the ServiceNow implementation and cannot absorb migration work

The hidden cost of building in-house is not the initial script development. It is the debugging cycle when 3% of records fail due to edge cases — missing references, encoding issues, timeout errors — and the re-migration when stakeholders reject the first load because progress trail history is incomplete. Developers often underestimate the complexity of ServiceNow's CMDB class structure and the strict API throttling limits.

### Cost benchmarks

Costs vary significantly based on data volume and CMDB complexity:

| Scenario | Estimated Cost | Primary Cost Driver |
|---|---|---|
| Under 10,000 records, no CMDB | 2 to 3 weeks of developer time (internal) | Developer opportunity cost |
| 10,000 to 50,000 records, basic assets | $5,000 to $12,000 (managed) or 4 to 6 weeks dev time | CMDB classification and field mapping |
| 50,000 to 200,000 records, complex CMDB | $12,000 to $25,000+ (managed) | CMDB modeling, delta sync engineering, attachment volume |
| 200,000+ records, compliance documentation | $25,000+ (managed) | Validation, audit trail documentation, zero-downtime cutover |

These ranges are based on typical managed migration service pricing in 2024 and assume standard ITSM data (incidents, changes, problems, users, assets). Custom modules, unusually large attachment volumes, or regulatory documentation requirements push costs toward the higher end.

For a deeper analysis of where DIY migration scripts break down, see [Why DIY AI Scripts Fail and How to Engineer Accountability](https://clonepartner.com/blog/blog/why-ai-migration-scripts-fail/).

ClonePartner handles complex ITSM migrations by directly mapping TOPdesk assets to ServiceNow Configuration Items without flattening the data. We build custom extraction and loading scripts per engagement, handle delta syncs for zero-downtime cutover, and deliver a validation report documenting record-level accuracy.

> Planning a TOPdesk to ServiceNow migration? Our engineers will review your data model, estimate your timeline, and walk you through the exact approach for your environment. No commitment, no sales pitch.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently Asked Questions

### How long does a TOPdesk to ServiceNow migration take?
A typical TOPdesk to ServiceNow migration takes 2 to 5 weeks end-to-end. Small environments under 10,000 incidents with no CMDB can complete in under 2 weeks. Enterprise environments with 100,000+ records, complex CMDB relationships, and large attachment volumes typically require 4 to 8 weeks including UAT and cutover.

### What data cannot be migrated from TOPdesk to ServiceNow?
TOPdesk Action Sequences, SLA definitions, mail import rules, custom form layouts, dashboard configurations, and operator permission structures cannot be exported via API. These must be manually documented and rebuilt in ServiceNow using Flow Designer, SLA Definitions, and native configuration tools.

### Can TOPdesk incident history be preserved in ServiceNow?
Yes. TOPdesk progress trail entries can be extracted via the Incident Management API (v4 endpoints) and loaded into ServiceNow as `work_notes` or `additional_comments` journal entries. The key requirement is extracting the full progress trail per incident, not just the incident summary. Rich text formatting may be simplified during the transfer due to differences in supported HTML between the platforms.

### Can TOPdesk asset relationships be preserved in ServiceNow CMDB?
Yes, but only if you rebuild them as CIs and relationships in the `cmdb_ci` hierarchy. TOPdesk assets must be classified into the correct ServiceNow CI classes and relationship records must be explicitly created in the `cmdb_rel_ci` table. Dumping flat asset records into ServiceNow without classification and relationship mapping results in a CMDB that provides no operational value.

### Is there downtime when migrating TOPdesk to ServiceNow?
With proper planning, downtime can be reduced to a 2 to 4 hour cutover window. Migrate all historical data in advance, run the IT service desk on TOPdesk during the migration period, and perform a final delta sync of new and modified records before switching over.

### What happens if the migration fails — can I roll back?
Yes, if you plan for it. Keep TOPdesk running in read-only mode for 2 to 4 weeks after cutover. Tag all migrated ServiceNow records with a migration batch identifier so they can be identified and deleted if necessary. Take a ServiceNow instance backup or clone before the production load. Define specific rollback criteria with stakeholders before migration begins.

### Are there GDPR or data residency concerns when migrating?
Potentially. If your TOPdesk and ServiceNow instances are hosted in different regions, the migration constitutes a cross-border data transfer. Ensure appropriate legal mechanisms (Standard Contractual Clauses, etc.) are in place. Apply anonymization to PII in historical records if required by your data protection policy. Define a data retention cutoff to avoid migrating records beyond your retention period.

## Frequently asked questions

### How long does a TOPdesk to ServiceNow migration take?

A typical TOPdesk to ServiceNow migration takes 2 to 5 weeks end-to-end. Small environments under 10,000 incidents with no CMDB can complete in under 2 weeks. Enterprise environments with 100,000+ records, complex CMDB relationships, and large attachment volumes typically require 4 to 8 weeks including UAT and cutover.

### What data cannot be migrated from TOPdesk to ServiceNow?

TOPdesk Action Sequences, SLA definitions, mail import rules, custom form layouts, dashboard configurations, and operator permission structures cannot be exported via API. These must be manually documented and rebuilt in ServiceNow using Flow Designer, SLA Definitions, and native configuration tools.

### Can TOPdesk incident history be preserved in ServiceNow?

Yes. TOPdesk progress trail entries can be extracted via the Incident Management API v4 endpoints and loaded into ServiceNow as work_notes or additional_comments journal entries. Rich text formatting may be simplified due to differences in supported HTML between platforms.

### Can TOPdesk asset relationships be preserved in ServiceNow CMDB?

Yes, but TOPdesk assets must be classified into ServiceNow CI classes and relationship records must be explicitly created in the cmdb_rel_ci table. Dumping flat asset records without classification and relationship mapping results in a CMDB with no operational value.

### Is there downtime when migrating TOPdesk to ServiceNow?

With proper planning, downtime can be reduced to a 2 to 4 hour cutover window. Migrate historical data in advance, run the service desk on TOPdesk during migration, and perform a final delta sync before switching over.