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.
Migrating from TOPdesk to ServiceNow is a medium-to-high complexity data model translation project with no native migration path between the two platforms. The fundamental challenge lies in converting TOPdesk's flat asset records into ServiceNow's relational CMDB with class assignments and dependency mapping, while also reconciling differences in user models, incident history structures, and picklist value systems. Custom API scripting is required for extraction (TOPdesk's paginated REST API with separate endpoints per entity) and transformation, and all automation—including Action Sequences, SLA policies, and escalation rules—must be manually rebuilt in ServiceNow using Flow Designer and native SLA Definitions.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
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.
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.
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 TOPdesk
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 TOPdesk → 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 -
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.
TOPdesk → ServiceNow specifics
- CMDB depth
- 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. 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.
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 TOPdesk 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 TOPdesk 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
TOPdesk → ServiceNow specifics
- Incidents
- GET /tas/api/incidents with page_size and start parameters
- Incident history
- GET /tas/api/incidents/id/{id}/progresstrail, /actions, /requests, /timespent, /attachments
- Attachments
- GET /tas/api/incidents/id/{id}/attachments (per incident)
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 TOPdesk 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 TOPdesk → 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.
TOPdesk → ServiceNow specifics
- 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.
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 TOPdesk. 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 TOPdesk. 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.
-
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.
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 TOPdesk 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 TOPdesk 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 TOPdesk read-only as the archive and rollback path.
-
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."
TOPdesk → ServiceNow specifics
- 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.
- 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.
- 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.
- 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.
- 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.
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 TOPdesk 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 TOPdesk archive that satisfies your immutable audit-trail requirement.
-
Close the change and sign off
Close the migration change record with actual outcomes, get written acceptance against the Discovery criteria, and schedule decommission after the agreed read-only retention period.
-
Record count reconciliation
Compare total counts per object type between TOPdesk and ServiceNow. Expect a match rate of 99.5%+ before proceeding. Investigate any discrepancy to the individual record level.
TOPdesk → ServiceNow specifics
- 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.
- 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).
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.
TOPdesk ServiceNow Object Mapping
| TOPdesk field | ServiceNow field | Notes |
|---|---|---|
| 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. |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Incidents | medium | Core incident records map to ServiceNow's incident table, but progress trail entries, actions, requests, time spent, and attachments each require separate API extraction and careful remapping of status values and journal fields. |
| CMDB / Assets | high | TOPdesk's flat asset records must be classified into specific ServiceNow CI classes with dependency relationships defined, and loading them into incorrect tables will break Dependency Views and CI relation formatters entirely. |
| CI Relationships | high | TOPdesk asset links and assignments must be translated into explicit ServiceNow cmdb_rel_ci relationship types (Runs on, Hosted on, Depends on), with no automated mapping available between the two relationship models. |
| Users (Persons & Operators) | medium | Merging TOPdesk's separate Persons and Operators into ServiceNow's unified sys_user table requires email-based coalescing, role assignment for agents, and preservation of legacy TOPdesk IDs for inactive users and historical references. |
| Groups & Memberships | low | Operator Groups map to sys_user_group with memberships rebuilt via sys_user_grmember records, which is straightforward but must be completed before transactional records are loaded to ensure assignment references resolve correctly. |
| Changes | medium | TOPdesk change activities map to ServiceNow Change Tasks, but template-driven activities need manual recreation and linked assets must be re-associated after load. |
| Knowledge Articles | medium | Category structures differ between platforms, inline images require re-hosting to ServiceNow's attachment system, and HTML formatting from TOPdesk often requires cleanup to render correctly. |
| Attachments | medium | Attachments must be downloaded as binary content per-record from TOPdesk and uploaded individually to matching ServiceNow records, creating significant API overhead and requiring careful parent record sys_id mapping. |
| Automations & SLA Policies | high | Action Sequences, SLA definitions, escalation rules, and event triggers cannot be exported from TOPdesk and must be fully rebuilt in ServiceNow, with complex environments requiring 1-2 weeks of dedicated rebuild effort. |
| Time Registrations | low | Time registrations map to ServiceNow time_card or task_time_worked records, but must be linked back to the correct migrated incident or change sys_id, requiring a consistent operating model decision upfront. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Flat Assets to Relational CMDB
TOPdesk stores assets as flat records with simple linking, while ServiceNow requires each asset to be classified into a specific CI class (e.g., cmdb_ci_server) with explicit relationship records mapped to types like 'Runs on' or 'Depends on'.
Incident Progress Trail Conversion
TOPdesk stores incident updates in a separate progress trail endpoint with rich text formatting that must be sanitized and remapped to ServiceNow's journal fields (work_notes and comments), which support only a limited HTML subset.
Picklist and Value Translation
TOPdesk uses named enum values for status, priority, and category fields, while ServiceNow uses integer-based choice lists, requiring a complete value-to-value translation table for every picklist field before migration.
Automation and SLA Rebuild
TOPdesk Action Sequences, SLA definitions, escalation rules, and event triggers have no export mechanism and must be documented and rebuilt natively in ServiceNow using Flow Designer and SLA Definitions, consuming 20-40% of total project effort.
Paginated Multi-Endpoint Extraction
TOPdesk's API limits incident responses to 100 records per page and requires separate API calls per incident for progress trails, actions, time spent, and attachments, creating hundreds of thousands of API calls for large datasets.
User Model Unification
TOPdesk separates Persons (callers) from Operators (agents) across distinct API endpoints, while ServiceNow unifies both into the sys_user table with role-based differentiation, requiring careful identity deduplication and role assignment during transformation.
What breaks
Known failure modes. Have a recovery plan for each before you cut over.
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.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
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.