Moving to ServiceNow Problem Management: Migration Considerations

This guide helps teams decide how to move problem records into ServiceNow Problem Management from a legacy system. It covers taking stock of current records and workflows, mapping fields, deciding how much history to migrate, choosing between a parallel run and a hard cutover, and planning a rollback.

Understanding What You Are Migrating

Before you move to ServiceNow Problem Management, inventory what you have in your current system. How many problem records are currently open, and how many are closed? What data fields does your current system track? Who manages the current workflow, and what does their day look like? What reports does your leadership depend on? This inventory shapes your migration strategy.

Many organisations discover that their current problem management is underdeveloped. They may track problems in email threads, Excel spreadsheets, or a ticketing system that conflates incidents and problems. ServiceNow will force you to establish clearer processes, which is valuable but creates initial disruption. Your team will need to learn new categories, new workflows, and new ways of working.

Data Mapping and Cleansing

Once you understand your current state, map your existing problem data to ServiceNow table structures and fields. Your current system might track priority on a single scale; ServiceNow derives priority from impact and urgency. Your system might use one status field; ServiceNow uses workflow states that map to specific actions and transitions. Field mapping is not one-to-one, so you need to convert your data to fit the ServiceNow model before loading it.

Plan a data cleansing phase before migration. Old problems in your current system may lack important details, have inconsistent categorisation, or include resolved issues that should be archived rather than migrated. Decide upfront: Do you migrate all historical problems, or do you migrate only open problems and leave closed ones in the legacy system? Migrating everything preserves history but creates noise; migrating only actives keeps the new system clean but limits historical trending.

Cutover Strategy: Parallel Run or Hard Cutover?

A hard cutover switches all problems from the old system to ServiceNow on a specific date. Advantages: you achieve a single system quickly and avoid the complexity of running two systems in parallel. Disadvantages: if discovery reveals issues, you have no easy fallback because the old system is offline.

A parallel run keeps both systems active for a period. New problems start in ServiceNow; old problems remain in the legacy system until they close or you migrate them. This gives your team time to adapt to new workflows and discover gaps before fully committing. Disadvantages: running two systems creates confusion about which system is authoritative, requires ongoing synchronisation, and extends the migration timeline.

Process Redesign Effort

Your current problem management workflow likely does not match ServiceNow’s default workflow. You will need to decide: what are your states (submitted, assigned, investigation, resolution, closure)? Who approves moving between states? When do you escalate? Do you require change requests for every problem fix, or do you integrate Problem Management with Change Management loosely?

This redesign is not trivial. You are not just porting the old process; you are modernising it. ServiceNow enables practices your legacy system did not support: automated problem detection from correlated incidents, integration with knowledge management, or automated notifications. The migration is an opportunity to improve—but only if you invest time in process design, not just data loading.

Training and Adoption

Your team has developed muscle memory working with the current system. ServiceNow looks different, behaves differently, and requires different mental models. Plan training before cutover: not just how to fill out fields, but why Problem Management matters and how to recognise when to escalate an incident to a problem.

Adoption is driven by leadership. If your incident management team understands that Problem Management prevents recurring incidents, they will use it. If they see it as overhead, it will become a checkbox exercise. Invest in showing early wins—”this recurring email issue has cost us ten incidents this month; proper problem investigation would have solved it once.”

Technical Integration Decisions

Decide upfront how Problem Management integrates with adjacent modules. When a problem links to a change request, what happens? Does closing the problem automatically close the related change? Does approving a change move the problem forward? These integration points shape your workflow and affect which team owns different stages.

Plan your reporting strategy. What reports do your incident managers need to see? What trending should your leaders see? Build these reports before cutover so you have them available during the critical first weeks when adoption is being decided.

Governance and Approvals During Migration

Establish clear approval gates during migration. Who approves starting data migration? Who approves the cutover to go live? Who approves moving from parallel running to full production? Having named decision-makers prevents confusion and ensures accountability. Document the approval criteria: data quality meets thresholds, testing passed, user acceptance obtained, risk mitigation strategies verified. This clarity prevents ad-hoc decisions made under pressure.

Rollback Plan

If the migration exposes critical issues with ServiceNow or your process design, what is your fallback? If you are doing a hard cutover, rollback means restoring the old system and re-creating any work done in ServiceNow—painful and potentially data-losing. If you are doing a parallel run, rollback is easier—the old system is still live. This is another reason phased approaches, while slower, are lower-risk for large migrations.

Open problems are the hard part of the carry-over

Closed history can often be archived without much argument. Open problems are where migrations often go wrong, because each one carries a live investigation, a half-agreed workaround and people waiting on a decision. Before any data moves, sort the open records into the categories below. Each category needs a different path, and mixing them is a common reason a migration produces a backlog that nobody recognizes.

Reconciling links to incidents and changes

Problem records are valuable mainly because of what they link to. A migration that copies problem fields but loses the links has preserved the paperwork and lost the evidence. Build a reconciliation step that counts, for each migrated problem, the number of linked incidents in the legacy system and the number in the new one, and investigates any difference before the cutover is approved. Pay particular attention to incidents that were linked by a shared cause text rather than by a formal reference, because those links often do not survive an import without manual help. The cutover side of that check is in the data migration validation at cutover notes.

The same discipline applies to changes. A problem that was resolved by a change in the legacy system needs its change reference preserved, or the verification history can disappear. Where the changes themselves are migrating in a different wave, agree the order in advance, so a problem is never migrated ahead of the change it depends on.

A carry-over sequence that keeps evidence intact

1. Freeze new legacy problem creation for a short window before the extract, and announce the freeze so that teams know where to file during it.
2. Extract open and recently closed problems with their linked incidents, changes and notes, and store the extract with a checksum so it can be compared later.
3. Load the open problems first, then the linked incidents, then the changes, checking the link counts after each load rather than at the end.
4. Review a sample of migrated problems with their original owners and confirm that the investigation history reads correctly in the new record.
5. Record which legacy problems were intentionally left behind, along with why each one was left behind and who signed off that choice.

Protecting trend reporting across the switch

Leaders read problem trends over long periods, and a migration can break those trends without anyone noticing until a quarterly review. A problem closed in one system and re-opened as a new record in the other can count twice. A change in category labels can make a team look as if its failures have fallen when the records simply moved. Agree a mapping of old categories to new before the cutover, publish it, and restate the key trend figures on both bases for at least one reporting cycle, so the break in the series is visible and explained rather than hidden.

Signs the migration is ready to close

The migration can be treated as finished when the legacy system is read-only for problems, every open problem has a named owner recorded on the new record, link counts reconcile for the agreed sample, and the first post-cutover review has been held. A useful final signal is that a support lead can find the investigation history for a recent problem in the new system quickly, without asking the migration team where it went. The controls that show reconciliation has actually happened are described in the migration reconciliation controls notes.

Questions to resolve before the first load

Should we migrate closed problems at all?

Migrate the closed problems that are still referenced by open changes, known errors or recurring incidents. Archive the rest in a locked, searchable archive. Carrying the full closed history can slow reporting and bury the records that matter.

What do we do with problems that were never properly recorded?

Record them as migrated with a data-quality flag rather than inventing missing detail. A flagged record is honest, and the flag makes it easy to find and improve later.

How do we handle integrations that write to the legacy problem table?

List every integration before the freeze. Each one either moves to the new table in the same release or is switched off with a documented manual alternative. Integrations left pointing at the old system are a frequent source of missing records after cutover.

Who approves moving from the freeze to live use?

The service owner should approve it, on the evidence of the reconciliation results and the sample review. Naming that single approver avoids a long debate at the point when the team is most tired.

Describe the number of open problems and the systems they link to, and the conversation can start from there.

Related guides: ServiceNow Problem Management Implementation Roadmap.