Migrating from TOPdesk to ServiceNow

This page helps a reader plan a move from TOPdesk to ServiceNow in the right order. Before any record moves, inventory the data, map processes and fields, and map operators, persons and locations separately. Choose a cutover strategy, then validate, train users and monitor after go-live.

In a TOPdesk migration the tickets are the easy part; operators, persons and locations are three separate populations that have to be mapped before any call moves. This page covers what to inventory, process and data mapping, what usually does not map one-to-one, cutover strategy options, validation and testing, training and change management, post-cutover monitoring, and the timeline and key decisions. The later sections map the three populations side by side, set a load order that keeps references intact, show what goes wrong when people are migrated as text, and explain when to simplify the location model.

What to Inventory Before Migration

Inventory all TOPdesk data: incidents (calls), changes, problems, known errors, assets, users, groups, suppliers, and any custom data stored in TOPdesk. Count by record type and status (open vs. closed). Determine which data is live (active incidents, current assets) and which is historical (closed calls from years ago). Identify TOPdesk’s custom fields, custom queries, and custom reports—these are unique to TOPdesk and may not have equivalents in ServiceNow. Interview power users: how do they use TOPdesk daily, what keyboard shortcuts do they rely on, what reports do they run weekly? Understanding user workflows is critical to a successful transition.

Process and Data Mapping

Document TOPdesk’s incident lifecycle, change approval process, and asset lifecycle. Create a field-by-field mapping: each TOPdesk field (title, description, category, impact, urgency, assignment group, status) maps to a ServiceNow field. Some fields may not map exactly. For example, TOPdesk’s “subcategory” might map to ServiceNow’s category, or you might create custom fields to preserve it. TOPdesk’s “supplier” or “vendor” relationships may require custom linking in ServiceNow if ITAM modules are not licensed. Decide early: which TOPdesk features are must-have (recreate in ServiceNow) and which are nice-to-have (can defer or archive)?

What Usually Does Not Map One-to-One

TOPdesk’s UI/UX is different from ServiceNow; workflows users relied on need to be re-learned. TOPdesk’s “call” terminology (instead of “incident”) requires terminology change in training. TOPdesk’s custom fields, custom workflows, and custom reports must be rebuilt or replaced. TOPdesk’s “Supplier” module may not fully map to ServiceNow’s Vendor/Supplier functionality depending on licensing. TOPdesk’s API is different from ServiceNow’s; integrations with other tools require adapter updates or API call rewrites. TOPdesk’s asset tracking (CMDB-like) is different from ServiceNow’s CMDB; alignment requires careful mapping.

Cutover Strategy Options

Big-bang cutover: export all TOPdesk data to ServiceNow in a single load, turn off TOPdesk, go live with ServiceNow immediately. Fastest approach but riskiest; if the migration fails, rollback options are limited.

Phased cutover by team: migrate one support team or location at a time. For example, Week 1: Level 1 helpdesk moves to ServiceNow; TOPdesk is read-only. Week 2: Level 2 support moves. This spreads risk and allows time for issues to surface on a small scale before full rollout.

Phased cutover by data age: migrate only closed incidents (historical data) to ServiceNow initially; run both systems in parallel for active incidents for a set period; then cutover active data when confidence is high.

Parallel run: both systems run simultaneously during a transition period. This is safest but most resource-intensive; someone must maintain both systems during parallel running.

Validation and Testing

Create a detailed test plan. Verify migration results: all incident counts match, field values are populated correctly, relationships between records (incident-to-change, incident-to-asset) are preserved. Test user workflows in ServiceNow: can a user create an incident, assign it, add notes, and close it without issues? Test integrations: email-to-incident, phone system integration, CMDB sync, if any. Conduct user acceptance testing with a pilot group (10-20 power users) for one week; gather feedback on what works well and what needs improvement. Document issues and fixes before full cutover.

Training and Change Management

Create training materials: how to create an incident in ServiceNow, how to view my queue, how to update an incident, how to close a ticket. Conduct classroom-style training for all support staff (or virtual if distributed). Publish quick-reference guides (1-page checklists). Identify super-users in your team who can help others during the transition. Create a support channel (email, chat, or ticketing system) for questions. Be prepared for a dip in productivity in the first week; people are learning a new system. This is normal and temporary.

Post-Cutover Monitoring

During the early period after cutover, have dedicated resources monitoring ServiceNow for issues: performance problems, data integrity issues, workflow failures, integration failures. Monitor ticket closure rates and resolution times; if they drop sharply, investigate why and provide additional training or fixes. Have a defined escalation path: if something breaks badly, who can you call? Keep TOPdesk running in read-only mode for a short period after cutover as a safety net; if a critical issue arises, you can revert. Once the early period has passed, transition to standard support and continuous improvement.

Timeline and Key Decisions

Typical migration timeline: planning and data extraction, mapping and configuration, testing, training, and cutover. The total depends on scope and organization size. Key decisions upfront: cutover strategy (big-bang or phased), data retention (how far back to migrate), and go-live readiness criteria (what must be true before you’re willing to turn off TOPdesk).

Operators, persons and locations need separate mapping before any ticket moves

TOPdesk installations tend to model the organization around operators who handle work, persons who request it and locations where it happens. The vocabulary is different in ServiceNow, where users, groups, companies and locations are organized in their own tables and relationships. Those differences matter because a ticket is only meaningful when the person, the place and the team it refers to exist in the same form on the new side. Map the three groups first, then the tickets, because a ticket that cannot find its requester or its location becomes an orphan that no report will ever show correctly.

Mapping the three populations side by side

The three groups do not translate one for one. An operator may be a user with a fulfillment role, a member of several groups, or both at different times. A person may be an employee, a contractor or an external contact. A location may be a branch, a building, a floor or a room, depending on how granular the old model went. The table sets out the decision for each.

A load order that keeps references intact

1. Load locations first, from the top of the hierarchy down, so that every child has a parent when it arrives.
2. Load companies and departments next, then groups, then users, so references resolve on the first pass.
3. Load assets and relationships after the people and places they point to.
4. Load tickets last, in date order, and check that each requester and location resolves to a live record.
5. Run a reconciliation report of unresolved references and resolve them with the owners, not by creating placeholder records.

What goes wrong when people are migrated as text

A common shortcut is to copy requester names as plain text onto each ticket. That keeps the ticket readable and breaks every query that depends on who asked for the work. Routing, satisfaction surveys and the reports on repeat requesters all need a reference. A second shortcut is loading every person from the old directory, including leavers, which puts stale accounts in the requester lookup. Decide with the HR owner which population is in scope, and document the rule that keeps leavers out.

Location models also cause quiet trouble. If rooms are loaded without their building, the location report groups them under a blank heading, and a manager looking for the site with the most incidents sees nothing useful. The fix is to check the hierarchy before the first ticket arrives, not to correct the reports afterwards.

When to simplify the location model

An old TOPdesk model may hold far more detail than the new reports need. Rooms that exist for facilities bookings rarely help an IT incident, and carrying them into the request forms makes every choice slower. Keep the level that the service needs for routing and reporting, and move the finer detail to the facilities system if it exists there. The decision is worth a short workshop with the people who answer the requests, because they know which levels they actually use.

Questions TOPdesk teams ask about the move

Should operators keep the same permissions they had in TOPdesk?

Not automatically. Re-derive the permissions from the roles each person needs in the new platform, and review them with the service owner. Copying old permissions tends to copy old exceptions.

How do we handle a person who appears twice in the old system?

Choose one authoritative record, keep the other as a reference in notes if it matters for history, and do not load both. Duplicate people produce duplicate requesters, which then split the reports.

What happens to tickets that refer to a deleted location?

Keep the ticket and attach it to the nearest surviving location, with a note recording the original. Losing the location silently makes the ticket invisible to the team that owned it.

How transform maps convert source data is explained in the transform map guide, the design of the import is covered in the import design note, and the data migration work is described on the data migration service page.