Migrating from ManageEngine ServiceDesk Plus to ServiceNow

This guide helps a service team plan a move from ManageEngine ServiceDesk Plus to ServiceNow. It covers inventorying the current environment, mapping data and processes, choosing a cutover approach, validating records during parallel running, and stabilising the new service after go-live.

Understanding Your ManageEngine Inventory

Before migration planning begins, you need a complete picture of your current ManageEngine environment. Document all workflows, request types, approval chains, custom fields and integrations. Pay special attention to automations and scripts that may not have direct equivalents in ServiceNow. Identify which system records your authoritative data: some organisations use ManageEngine primarily for ticketing while keeping incident and change management elsewhere.

Create a mapping spreadsheet that lists each ManageEngine function alongside its intended ServiceNow destination. Note which fields are required in both systems versus those that exist only in ManageEngine or only in ServiceNow. Test data export from ManageEngine early—many organisations discover encoding issues or incomplete audit trail exports only during the real cutover.

Data and Process Mapping Challenges

ManageEngine’s request types and their associated workflows rarely map one-to-one to ServiceNow’s catalog items and fulfillment logic. ServiceNow separates request intake (Service Catalog) from execution (Service Desk), while ManageEngine often handles both in a single entity. Plan to redesign your catalog structure rather than attempting a direct field-by-field conversion.

Custom fields in ManageEngine typically become variables in ServiceNow’s catalog items. Assignment groups and escalation rules work differently: ManageEngine may route based on request category alone, while ServiceNow offers more granular routing through assignment rules, workflows and scripts. Your existing SLAs will require rebuilding in ServiceNow’s response and resolution time model.

Integration points deserve particular scrutiny. If ManageEngine uses SOAP calls to other systems, ServiceNow offers both MID Servers and REST integrations depending on your network architecture. Verify that target systems accept ServiceNow’s connection method before cutover.

Cutover Approaches and Validation

Many large enterprises use a phased cutover rather than a big-bang switch. One common pattern: migrate a pilot department first to validate your data mapping and process redesigns. Run parallel systems while the pilot team operates in ServiceNow and you validate that no tickets are lost or duplicated.

Prepare a validation checklist before cutover. Check record counts in key tables, sample random requests to verify data completeness, confirm that SLA calculations match your historical performance, and test escalations under load. During the parallel period, identify tickets created in ManageEngine that need manual creation in ServiceNow because they crossed the cutover boundary.

Archive ManageEngine data before decommissioning the old system. You may need historical records for audit purposes for years after migration. Store exports in a location where business users can access them without system administrator privileges.

Change Management and Stakeholder Communication

Ticket requesters care primarily about whether their requests are handled correctly, not which system processes them. Train end users on the new Service Catalog interface before cutover, with enough time to practise. Highlight changes in how they submit requests, check status and receive notifications. Some organisations hold dual support: a few experienced users use the new system while others continue submitting via the old process for a short period, with central IT re-entering those requests into ServiceNow.

Service desk staff need more intensive training because they use the system constantly. Dedicate time to teaching them the new notification model, the difference between incidents and requests, and how to use Knowledge management. Plan for reduced first-call resolution rates in the first two weeks while staff become familiar with the new interface.

Support leadership should establish a 24-hour rapid-response process for critical issues during and immediately after cutover. Have your ServiceNow consultants available for live troubleshooting, not just post-implementation handoff. Plan for increased ticket volume immediately after cutover as staff and users navigate the transition.

Common Mistakes and Prevention

Do not delay the knowledge base migration. Tickets often reference existing knowledge articles, and breaking those links during cutover creates frustration. Migrate knowledge content before ticket cutover, with enough time so staff can validate that content appears correctly and links work.

Avoid bulk-updating historical tickets in ServiceNow after cutover. The effort is disproportionate to the benefit. Instead, keep ManageEngine running in read-only mode for a defined period so staff can search old tickets, then archive it. The risk of introducing errors into historical records outweighs the convenience of a unified view.

Do not underestimate the effort to rebuild approvals and escalations. Many teams assume they can export workflows from ManageEngine and import them into ServiceNow. In reality, almost every workflow requires redesign because the platforms model approval differently. Budget significant time for discovery calls with process owners and testing of the new approval experience.

Post-Cutover Stabilisation

The period immediately after cutover is critical. Your team will be overwhelmed with questions, issues and unexpected problems. Plan for this: have your consultants available, schedule extra support staff, and prepare for longer ticket resolution times as staff get familiar with the new system. Expect first-call resolution rates to drop noticeably for the first two weeks, then recover as staff gain confidence and expertise grow.

Prepare workarounds for common problems that may appear immediately after cutover. If the new system has known limitations, have a manual workaround ready so business does not grind to a halt while IT works to fix the issue. Document these workarounds and communicate them proactively to help users navigate the transition period effectively.

Calendars and SLA clocks are where ServiceDesk Plus timing quietly differs

ServiceDesk Plus administrators often inherit SLA settings that were tuned over years, including business hours, holiday lists and escalation thresholds that reflect how the organization actually works. When that timing moves to ServiceNow, the request forms look identical while the clocks behave differently. A ticket that met its target last quarter can breach on the first day of the new platform, purely because the calendar was copied without its exceptions. Treat the calendar and the SLA definitions as a single piece of work with its own test cases, rather than as configuration to be completed at the end.

Rebuilding the calendar before the SLAs

An SLA is only as accurate as the schedule it counts against. Start by reconstructing the working calendar from what the service actually delivers: which sites run which hours, which public holidays close which teams, and which after-hours cover is contracted rather than merely hoped for. The table lists the parts of the calendar that most often go missing.

Asset import without importing the mess

ServiceDesk Plus asset data is often a mixture of discovery output and hand-entered records. The discovered items are usually reliable on hardware identity and poor on ownership. The hand-entered items are the reverse. Before loading, separate the two sources and set a rule for which one is authoritative for each attribute. Load discovered items first, then reconcile the hand-entered records against them, and treat any record without a matching device as a question for the owner rather than a new configuration item.

1. Confirm the calendar and holiday data with the people who manage the sites, not only from the admin screens.
2. Build the schedules and attach them to the groups that use them.
3. Recreate the SLA definitions with their pause conditions and escalation steps.
4. Load a sample of recent tickets and compare the calculated targets with the values the old platform stored.
5. Import assets by source, then reconcile, then assign owners, in that order.

What goes wrong when the old clock is trusted blindly

The usual fault is accepting the new breach report without checking it. If the calendar is one hour out for part of the year because daylight saving was not modeled, the numbers look plausible for months. A second fault is counting paused time because the pause state was added after the migration, so tickets awaiting a customer breach while nobody is working on them. Both faults are found by comparing a known set of tickets against the old answers, which is why that comparison should be part of the acceptance test rather than an optional extra.

A third fault sits in the asset data. Devices re-discovered after the cutover can create second copies of records that were migrated by hand. The new platform then shows two servers with the same name, and the change board cannot tell which one a change affects. Run the identification rules before any manual asset is treated as final.

When to keep the old SLA settings as they are

If the SLA definitions were never reviewed against the contract, copying them forward preserves an agreement nobody can explain. Use the migration to check each target against the signed service terms. Where the old target is stricter than the contract, keep the stricter value only if the team is already meeting it. Where it is looser, raise it with the service owner rather than quietly tightening it on the new platform.

Questions ServiceDesk Plus teams ask about timing and assets

Should we migrate the historical breach data?

Migrate enough to support the reporting periods your contracts and reviews use, and keep the old reports available for the rest. Historical breach values were calculated under old rules, so do not present them as if the new definition produced them.

How do we handle a site that works a different week?

Give that site its own schedule and attach it to the locations or groups that serve it. Do not average the site into the global calendar, because the error will appear as breaches at the edges of the week.

Who should approve the new calendar?

The service owner for each region, with a sign-off from whoever holds the contracts. The platform team builds it, but the people accountable for the targets should confirm the hours.

The SLA mechanics are in the SLA design note, the pause and breach logic in the breach prevention note, and the asset scope in the first release scope note.