ServiceNow Migration Services

What the Service Covers

ServiceNow migration services help organisations move from legacy ITSM, ITOM or ITAM systems into ServiceNow. This includes assessing the current state, designing the target ServiceNow configuration, preparing and validating data, training teams and managing the cut-over. The goal is a functioning ServiceNow instance with data integrity, team capability and low operational disruption on day one.

Who Needs Migration Services

Organisations typically engage migration services when moving from on-premise or competing commercial platforms (such as BMC Remedy, HP Service Manager or others) into ServiceNow on the public cloud. Some organisations also need migration when consolidating multiple ServiceNow instances into a single environment or when retiring a legacy system that has operated in parallel.

How an Engagement Runs

Discovery takes as long as the legacy system requires. The engagement team interviews stakeholders across IT operations, service delivery, compliance and finance to understand current processes, data volumes, integrations and pain points with the legacy system. The team documents current workflows, access control structures and custom automations that must either migrate or be retired.

Planning length depends on the size of the instance. The team designs the target ServiceNow configuration, maps legacy data to ServiceNow tables, identifies gaps between current and future state and proposes a phased rollout if the instance is large. A detailed cutover plan specifies data extraction, validation, user communication and rollback procedures. This phase also defines success criteria—performance targets, data quality thresholds, user adoption metrics—so both parties agree on what ‘complete’ looks like.

Delivery length depends on the volume and complexity of the data. Data is extracted from the legacy system and transformed into ServiceNow format. Parallel runs test both systems side-by-side to catch discrepancies. Users receive training on ServiceNow workflows specific to their role. The team documents all custom configurations, integrations and workarounds so the client’s support team understands the instance after handover.

Go-live runs the actual cutover: final data load, user access setup, confirmation that integrations are functioning and legacy system shutdown. This is usually scheduled for a low-traffic window to minimise user disruption. Post-live support covers the first two weeks when teams adjust to new workflows and data questions arise.

What the Client Provides

The client must nominate a migration lead and a steering committee for go/no-go decisions. The client also provides access to legacy system data, documentation of current workflows, and dedicated time from subject matter experts who understand the current processes. The client typically owns cutover logistics, user communication and legacy system shutdown.

How Success is Judged

A successful migration delivers ServiceNow operational by day one without critical data loss, meets the performance targets defined in planning, and has trained users who can perform daily tasks without escalating to the migration team. The target is that the engagement team can hand over to the client’s own support team within a month of go-live.

Service Delivery Timeline

Small instances (single module, limited data) are shorter. Medium instances (multiple modules, larger data volumes) take longer. Large instances with complex integrations and many custom fields take longest and may require parallel teams. The timeline also depends on client availability for decisions and access to systems.

Phases and Milestones

• Discovery Complete: Documented current state, pain points and gap analysis.
• Design Approved: Stakeholder sign-off on target configuration, data mapping and cutover plan.
• Build Complete: ServiceNow instance configured, data load tested, training materials ready.
• Parallel Run Complete: Both systems live side-by-side for one pay cycle, no critical discrepancies found.
• Go-Live: Legacy system retired, ServiceNow carries production load.
• Handover: Client team trained and signed off as capable of supporting the instance.

Managing Data Quality During Migration

Data quality is critical to migration success. Historical incident data, change records and asset information must be validated before migration. If legacy data has incomplete or incorrect information, migrating it as-is perpetuates problems. Decide upfront: which historical data is worth migrating, and which can be archived as read-only reference? This reduces both migration effort and complexity.

Parallel Run Best Practices

During parallel run, both systems operate simultaneously. Teams perform transactions in both and compare results. Discrepancies are investigated and resolved before legacy system shutdown. Parallel run length depends on transaction volume and the discrepancies found. Running too long wastes effort; running too short risks missing discrepancies. The right length balances thoroughness with efficiency.

Communication and Training Timeline

Users should know about the migration well in advance. Announce the project, communicate milestones, and conduct training at the right time—in the weeks before cutover so knowledge is fresh but not so far ahead that people forget. After cutover, continue communication: share tips for using the new system, address common problems, celebrate quick wins.

The data decisions that determine a clean cutover

Migrations from a legacy ITSM tool are often described as moving the tickets, but the tickets are the least difficult part. The harder decisions are about what each record means in the new system. A legacy status may not correspond to any ServiceNow state. A custom field may hold a value that users filled in differently for years. Users may have been identified by email address in one system and by a staff number in another, so historical ownership breaks if the match is not built. These decisions are better made as a set, with an owner for each, before any data is extracted.

A practical way to frame them is by data class. Open work has to move because someone will act on it after cutover. Recent closed history is often needed for trend reporting and for repeat-incident checks. Older history is usually reference material. Attachments, comments and linked documents each need their own rule, because they tend to be large, uneven in quality and not always related to the record that holds them. Teams moving off spreadsheets and shared mailboxes start from a different set of records, covered in the guide to migrating from spreadsheets and email.

Data class	Usual decision	Reason	What to verify after load
Open incidents and requests	Migrate, with mapped states	Someone must own them after cutover	Each open record has an assignee who exists in the new instance
Recent closed history	Migrate the window needed for trend reporting	Reports and repeat checks depend on it	Category mapping gives the same totals as the legacy report
Older closed history	Archive read-only, linked from a reference page	Rarely searched, and it slows the active tables	The archive is searchable by the people who need it
Attachments	Migrate selectively, by record type	Large and uneven, often unrelated to the open work	Links from migrated notes still resolve

A cutover sequence that keeps both systems honest

Cutover is where data quality problems become operational problems. A sequence that runs the migration in rehearsals, rather than one final load, gives the team time to see what is wrong while it is still cheap to fix. Teams moving off an in-house ticketing tool can use the homegrown ticketing migration guide, which covers the technical debt such systems tend to accumulate.

1. Build the state and category maps and have the process owner for each queue sign them off.
2. Match users between the two systems by a stable key, and list every legacy user with no match so the gap is decided, not discovered.
3. Run a full test load into a sub-production instance and compare record counts and totals against the legacy reports.
4. Repeat the load at least once more with corrected maps, and confirm the second run is clean before the production date is fixed.
5. Freeze the legacy system’s configuration change window, then perform the final load, the integration checks and the access setup in that order.
6. Hold the legacy system in read-only mode for a set period, so any late question can still be answered from the source.

Parallel running without double work

A parallel run is useful only when it tests something the rehearsals could not. Running both systems for a long period doubles the workload of agents, who must record every change twice, and the discrepancies it finds are often mapping errors that the rehearsal should have caught. A narrower parallel run, focused on the workflows with the highest risk such as major incident routing and change approval, gives most of the assurance for much less disruption. Knowledge content has its own migration path, described in the guide to moving knowledge management to ServiceNow.

Should we migrate every attachment from the legacy system?

Usually not. Migrate attachments that are linked from open records or that hold controlled documents, and archive the rest with a clear reference. Attachments are often the largest and least consistent part of legacy stores, and moving them all tends to slow the first weeks of use. Incident-specific considerations are covered in the guide to moving incident management to ServiceNow.

What is a common mapping mistake?

Treating a legacy status as a direct equivalent of a ServiceNow state when the two mean different things. A status that meant waiting on a supplier may need to become a state with a different assignment behavior. Map on meaning, then check the mapping against real examples.

How do we handle users who left the organization before cutover?

Decide the rule before the load. Typical options are to map their historical work to an inactive user record, or to a shared group. Either works if it is decided in advance, and both fail if each load handles them differently.

When can the legacy system be switched off?

When the new system carries all the open work, the final load has been checked against the reports, the integrations are confirmed and the people who need the archive can reach it. Turning it off before the archive question is settled removes the only source for a later audit.

When a migration should wait

If the legacy data has never been checked for completeness, a migration will move the gaps and make them harder to find. If the target process has not been designed, the new system will reproduce the legacy workarounds in new form. In both cases the first step is a data quality check and a process design decision. The migration can start once those are settled and the cutover rehearsal has a clear owner. Configuration item data has its own scoping question, covered in the guide to first-release CMDB scope.

Cutover rehearsals go better when the mapping decisions are made by people who know the legacy data.

Scope a migration from its data decisions, not its ticket count

A ServiceNow migration from a legacy ITSM tool is a mapping and reconciliation project before it is a data copy. The scope is set by three things: which records move, what each legacy status and category becomes in ServiceNow, and who signs off each of those maps. Teams that begin with a ticket count usually find the real work during the first test load.

Before anyone commits to a timeline, ask the legacy system for five lists it can produce itself:

• Record counts for each table, split by open and closed
• Every custom field, with a note on whether anyone still fills it in
• Each integration that writes to or reads from the old tool
• The reports the business opens every week
• The approval paths people actually follow, as opposed to the ones on paper

Those lists say more about effort than any estimate built from user numbers. A field nobody has filled since a process change is a mapping decision you can drop, while an undocumented integration is the most likely source of a surprise after go-live.

Then decide whether you are lifting or rebuilding. A lift keeps the legacy workflows and moves the data across, which suits a team whose process is sound and whose tool has simply aged. A rebuild redesigns the workflow in ServiceNow and migrates only the records that still matter, which suits a team that built workarounds into the old tool to make up for a missing process. Most engagements land between the two: open work and approval paths get rebuilt, while closed history comes across as read-only reference. For how each legacy product changes this picture, see the migration paths for each legacy product.

Two warning signs point to a scope that is not yet right. The first is a legacy report that cannot be reproduced from its source fields, which means its totals depend on a calculation nobody wrote down. The second is a custom field whose meaning changes by queue, so one field carries two or three meanings and needs a separate decision for each queue. Settle both before the mapping workshop rather than during it.

A homegrown tool or a product such as TeamDynamix raises the same questions about status meaning, ownership and history. Proof that the move worked is a set of matching counts and totals, so ask for the reconciliation evidence a cutover should produce before go-live.