Migrating from Zendesk to ServiceNow

Assessing and Inventorying Current State

Zendesk treats most work as a ticket, while ServiceNow separates incidents from requests, so a migration starts with a decision about which Zendesk objects earn a place in the new platform. This page covers the inventory of roles, fields, automations, integrations and history, the mapping challenges, what usually does not map one to one, cutover strategies and timing, data validation, team preparation, and a phased plan. Later sections give a sequence for the configuration audit, show where the mapping breaks in practice, explain when a direct move is the wrong plan, and how to tell the load is correct before cutover.

Process and Data Mapping Challenges

Zendesk and ServiceNow differ in how they model requests and tickets. ServiceNow distinguishes between Incidents (unexpected problems) and Requests (normal work), while Zendesk treats most items as tickets. This difference means some Zendesk data may not map directly to ServiceNow. Understanding these differences early prevents discovering mapping problems late in migration.

Custom fields, workflow conditions and automation rules require careful attention. Zendesk triggers and automations often have no exact ServiceNow equivalent; they might need workflow redesign rather than direct translation. Service level targets and escalation paths must be reimplemented in ServiceNow’s workflow engine. Analysing what you have now helps decide what stays as-is, what needs redesign, and what you might drop entirely.

What Usually Does Not Map One to One

Certain patterns in Zendesk systems rarely translate cleanly. Deeply nested custom fields may need flattening or restructuring. Email routing rules based on ticket content usually require ServiceNow’s different routing logic. Time tracking approaches often differ, as do ticket merge and linking patterns. Organisational hierarchies and group assignments frequently need adjustment to match ServiceNow’s role and team structure.

Reporting and dashboard definitions almost always require rebuilding. Zendesk reports may use calculations or dimensions that don’t align with ServiceNow’s data structure. Most organisations find it worthwhile to simplify reporting during migration: build the essential reports first, then add sophisticated analytics once the fundamentals are stable. This phased approach also helps teams learn the new data model.

Cutover Strategies and Timing

Three approaches typically work for Zendesk to ServiceNow cutover: parallel running (both systems active until teams trust ServiceNow), big-bang cutover (switch everything at once), or phased by team (different groups move at different times). Parallel running reduces risk but creates extra work managing two systems temporarily. Big-bang works for smaller deployments but introduces risk if problems emerge. Phased cutover offers a middle path: one team validates the new system, others follow once that team confirms it works.

Timing considerations matter. Avoid cutover during peak seasons or critical business periods. Parallel running adds value when it lasts long enough to validate that nothing critical broke, but not so long that duplicate work becomes unsustainable. Planning training and communication before cutover reduces surprises when the switch happens.

Data Validation and Quality Assurance

Before cutover, validate that migrated data is complete and accurate. Run counts to verify ticket volumes match. Sample data to confirm field mappings worked correctly. Test that critical workflows execute properly in ServiceNow. Validate that integrations with other systems still work as expected. This testing should happen in a testing environment first, using a copy of your actual data.

Expect to find data quality issues during migration. Incomplete or malformed data in Zendesk sometimes surfaces only when mapping to ServiceNow’s structure. Plan time to clean data before cutover, or accept that cleanup might continue for a few weeks after migration. Teams usually find it worthwhile to start with clean data rather than inheriting Zendesk’s data problems.

Change Management and Team Preparation

Team adoption is critical. Service desk staff need training on ServiceNow’s incident and request workflows before cutover. Managers should understand how reporting changes. Stakeholders need to know when the migration happens and what to expect. Communication matters more during this transition than it might seem. Uncertainty creates anxiety, while clear information builds confidence.

Plan support for the first weeks after cutover. Assign someone to watch for data issues, help teams troubleshoot new workflows, and gather feedback. Many organisations embed support staff in service desk teams for a few weeks after cutover, reducing frustration when staff encounter unfamiliar processes. This intensive support phase usually wraps up once teams feel comfortable with the basics.

A Phased Implementation Plan

A plan’s length depends on scope. Early work focuses on planning, data inventory and mapping. Next comes building ServiceNow, configuring workflows and testing migrations in lower environments. Then come data migration validation, training and final cutover preparation. The last stage is cutover and early support. This sequencing allows thorough work without extending the migration indefinitely.

Success depends on clear ownership and realistic scheduling. Assign a project lead and involve key stakeholders early. Be honest about risks and contingencies. Most migrations encounter unexpected complexities; planning for them prevents them from derailing the schedule. Once cutover happens and teams settle into ServiceNow routines, you can begin expanding functionality and integration with other tools.

Deciding which Zendesk objects earn a place in ServiceNow

Much of the cutover risk often sits in the configuration rather than the ticket history. A service desk manager who opens the migration by counting tickets is measuring the easy part. The harder decision is which Zendesk objects are still doing real work for agents, which ones exist only because someone once needed a workaround, and which ones should be redesigned in ServiceNow rather than copied. Record that decision per object before any data is loaded, because it sets the scope that every later test is measured against.

A sequence for the configuration audit

Run the audit in an order that prevents rework. Start with triggers and automations, because they touch everything else. Once you know which rules actually fire, views and macros become easier to judge, since many of them exist to compensate for a rule that does not do what its name says. Leave groups and users until the workflow design is settled, because group structure follows routing, not the other way round.

1. Export every active trigger and automation, with its last-fired date and its owner.
2. Mark each rule as routing, notification, field update, or escalation. Most confusion comes from rules that do two jobs.
3. Ask the owning team to confirm which rules they would miss within a day of switching off. Treat the silent ones as candidates for removal.
4. Redesign the routing and escalation rules in the ServiceNow design, then test them against recorded example tickets.
5. Only then map views, macros and groups to their ServiceNow equivalents.

Where the mapping breaks down in practice

A common failure is a ticket that looks ordinary in Zendesk and carries a structure ServiceNow will not accept without a decision. A customer with several linked tickets, a request that was split into child tickets, or a field that holds free text in some tickets and a picklist value in others will each need a rule. Incidents and requests are separate kinds of record in ServiceNow, so every linked-ticket pattern has to be classified before loading. Email threads deserve their own decision as well. Whether replies on an old ticket should land as comments, as attachments or not at all changes the size of the load and what agents see on their first morning.

Attachments and inline images are the other common surprise. They often inflate the import far beyond the ticket count suggests, and a load that times out halfway leaves partial records that look complete. Plan the attachment step as its own batch with its own reconciliation, and follow the controls for reconciling migrated records before the first agent sees them.

When a direct move is the wrong plan

Some Zendesk estates are mostly workarounds. Triggers that reassign tickets after an agent fixes a mistake, macros that set fields the form already sets, and views that exist only to hide closed work are signs that the current process is what needs rebuilding. In that case, moving the configuration across preserves the problem in a more expensive tool. A better route is to write the target process first, using the ticket types and approvals the business actually needs, and to load data only once that process has been signed off by the people who work it every day.

How to tell the load is correct before cutover

Counts prove less than most teams expect. A matching total can hide duplicated tickets and dropped attachments. Reconcile by status, by group, and by creation window, then pick a set of known tickets, including a few awkward ones, and walk each one through in ServiceNow from start to finish. An agent who has worked those tickets should be the one who signs them off. For the load itself, the data migration and integration service covers how the data is analyzed, cleaned and transformed before it loads. Keep the reconciliation output with the cutover record, because it is the evidence you will need when a customer or manager asks why a ticket moved differently.

Questions teams raise before the load

Should Zendesk stay open after cutover?

Usually it should stay readable for a defined period, with new tickets blocked. Read-only access lets staff check history without creating a second place to work. Decide the end date in advance, and remove the link from agent bookmarks on the same day.

What happens to links that customers saved to old help center pages?

They can break unless someone plans redirects or a holding page. Inventory the public links that people are most likely to have saved, and treat the list as part of the cutover scope rather than a later tidy-up task.

Who should approve the switch?

The service owner signs the scope, but the team lead for the busiest queue should sign the walkthrough. A switch approved only by the project team often reveals its gaps in the first busy hour.

Can the migration run alongside a move from another desk tool?

Only if the two sources are kept separate in the load plan. Mixed sources are a common cause of duplicate records and inconsistent field values, so give each source its own mapping sheet and reconciliation run.

Next step

If your Zendesk configuration has more triggers than anyone can explain, the audit is the first piece of work to scope. The Freshservice migration page shows how another desk tool’s planning approach is structured, and the guide to validating data at cutover sets out what validation should prove before the switch. For the wider picture of moving service desk tools, the ITSM overview and the ServiceNow migration guides are the reference points to read alongside this section.