Moving to ServiceNow Demand Management: Migration Considerations

This guide helps portfolio and IT leaders decide how to move demand records from spreadsheets, project tools and legacy intake forms into ServiceNow Demand Management. It covers data mapping, cutover options, in-flight demands, training and the first weeks after go-live.

Inventory Your Current Demand and Pipeline Data

Before you migrate to Demand Management, inventory what demand data currently exists in your organization. Demand or portfolio data is often scattered across multiple systems: spreadsheets where portfolio managers track projects, a project management tool where teams plan work, financial systems where budgets are tracked, and often different silos per business unit. List all current sources: which system owns customer demands, which owns internal initiatives, which owns resource constraints. Identify data gaps: is there a source of truth for demand priority, or do different teams prioritize differently. Identify who owns each data source and get their commitment to provide clean data for migration.

Data Mapping and Transformation Strategy

Demand has different structures across systems and you need to map it to Demand Management’s data model. Demand Management tracks each demand item with fields like title, description, submitted date, business value, effort estimate, priority, status. Your current systems probably use different field names and different structures. Create a mapping document: for each Demand Management field, identify which current system provides that data. Some fields are straightforward (title from the spreadsheet becomes title in Demand Management). Others require transformation: if one system tracks value in dollars and another in points, choose one format and convert everything. Some data may not exist: if nobody currently estimates effort, you will need to estimate or ask teams to estimate during migration.

Cutover Options and Timeline

Option one: big bang cutover. You stop accepting new demands in the old system on a date, migrate all outstanding data to Demand Management in a weekend, and everyone uses Demand Management starting Monday. This is clean and fast but risky: if migration problems occur, you have no fallback, and the disruption affects the entire organization. Big bang cutover works best when you have small demand volumes and good data quality. Option two: phased by business unit. You migrate one business unit at a time over weeks or months. The first unit acts as a pilot; their feedback helps you improve the process before rolling out to other units. This is lower-risk but slower and means different teams are in different systems for a period. Option three: parallel run. You keep the old system active and run Demand Management in parallel for a transition period. Teams feed demands into both systems. This is safest but creates double work and often fails because teams do not reliably keep both systems in sync. After transition, you cut over to Demand Management only.

Historical Demand Data and Archival Strategy

Decide what historical demand data to migrate. Demand Management is meant for active, current demands; storing years of old, closed demands clutters the system. Decide how far back to migrate based on what your reporting and audit needs actually require; archive older demands in a separate location (a database table, a report, or a read-only archive system). If your organization needs historical demand data for trend analysis or audit purposes, plan to export that before you turn off the old system. Some organizations migrate only the most recent demands and set a rule that teams can look up old data from the archive if needed, which keeps the active system clean.

Risks and Mitigation During Migration

Risk one: data loss. If you extract demand data incorrectly, you might lose detail or relationships. Mitigation: export the data, check it carefully against the source system, and validate that all records migrated. Risk two: demand rejection. Teams accustomed to their old system may resist switching to Demand Management. Mitigation: involve teams early in data mapping and cutover planning; run pilot phases with volunteers; provide training and responsive support at cutover. Risk three: priority conflicts. Different teams may have different demand priorities; migration forces a conversation about who prioritizes what. Mitigation: establish a demand prioritization governance process before migration; use the pilot phase to work out prioritization logic. Risk four: resource availability during cutover. Migration requires time from the portfolio team, the technical team, and business teams. If those people are unavailable, migration stalls. Mitigation: plan migration during a quiet period; secure commitment from key people that they will prioritize migration work.

Validation and Reconciliation After Cutover

After you migrate data to Demand Management, validate that everything migrated correctly. Spot check a sample of demands: do the titles match the source system, are descriptions complete, are effort estimates reasonable? Count demands in the old system and count demands in Demand Management; they should match (within archival decisions you made). Have portfolio managers review demands by area to ensure nothing was lost. Check relationships: if demand B depends on demand A, does that relationship exist in Demand Management? These validation steps take time but catch problems early when they are still fixable.

Process Changes and Governance During Migration

Demand Management changes how you manage demand. You are moving from ad hoc processes (people email requests, spreadsheets track priorities) to a structured process (all demands go into Demand Management, priorities are managed through a governance meeting). Define the new process before migration: who submits demands, who reviews and prioritizes them, what happens to approved vs rejected demands, how often you review and adjust priorities. Document this process; do not assume people will figure it out. Identify a governance board that meets regularly to prioritize demand. Run a kickoff meeting where you walk through the process and answer questions.

Training and Support Strategy

Different audiences need different training. Portfolio managers need training on how to prioritize demand in Demand Management and how to use dashboards for reporting. Teams need training on how to submit demands and track their status. Executives need training on how to access portfolio dashboards and understand capacity constraints. Provide role-specific training; do not give everyone the same training. Provide a guide on common tasks (how to submit a demand, how to check demand status, how to update estimates). After cutover, staff a support team to answer questions and resolve problems quickly; responsive support increases adoption.

Deciding what happens to demands that are in motion at cutover

Many migration plans describe the data and forget the work that is still moving. At any given moment some demands sit between stages. A requester has submitted an item that nobody has read closely, a coordinator has scored another one but the sponsor has not replied, and a third has been deferred to a later board sitting. Those are the items that generate complaints after go-live, because their owners remember a conversation the new system cannot show. Before the cutover date the demand lead should choose one rule for each in-flight stage and write it down where the team can find it. The realistic options are to finish the item in the legacy tool, to restart it in the new tool at its last agreed stage, or to close it and ask for a resubmission. Restarting is kinder to the requester, but it can double the assessor’s effort, so it suits a small set of high-value items rather than the whole backlog.

Mapping legacy statuses to the new lifecycle

Legacy tools often do not use the same status vocabulary as Demand Management, and the mismatch hides real decisions. A status called “in review” might mean a coordinator has the item, or it might mean the item is waiting on a person who left the company. Read each status against the records behind it before you map it, and treat any status that cannot be explained in one sentence as a question for the process owner rather than a field to translate.

A cutover sequence the team can run in order

1. Freeze the legacy intake form on an agreed date and announce the change to every requester group in the same message.
2. Take a snapshot of counts by stage, by requesting unit and by sponsor from the legacy tool. Keep the snapshot outside both systems so it can be used for reconciliation later.
3. Apply the in-flight rules from the table above, and log each decision against the original record identifier.
4. Load the migrated records into a test scope, then have two or three coordinators walk through a sample of items end to end, including one rejected item and one deferred item.
5. Open the new intake to requesters only after the walkthrough has raised no unresolved questions about routing or ownership.
6. Keep the legacy records readable for a defined period so that people can check history without asking for it to be restored.

When the move should wait for governance

Some conditions argue for delaying the data move. If the organization has not agreed who can reject a demand, the new tool will only make that disagreement visible to more people, and the first rejected item will become a dispute. If the capacity figures behind assessment are estimates no one has checked, an approval queue will look precise while resting on guesses. In those cases the more useful work is to agree the criteria, confirm which board decides, and run one live cycle on paper before any records move. The migration then becomes a transfer of a process that already works.

What to watch during the first weeks after go-live

Three signals show whether the cutover has taken hold. The first is intake volume compared with the pre-freeze pattern: a sharp fall often means requesters have stopped trying rather than stopped needing things. The second is the count of demands waiting at each stage, which should move steadily rather than pile up at one stage. The third is the number of resubmissions in which a requester says they could not locate their original item. Each of these needs an owner who reviews it weekly, and each should prompt a conversation with the coordinators rather than an automatic change to the workflow.

Can a demand still be edited in the legacy tool after the freeze?

Edits should be allowed only to correct a factual error that would change the migrated record. Substantive changes to scope or value belong in the new tool, because otherwise two versions of the same demand will exist and the board will decide on the wrong one.

Who owns a migrated demand whose sponsor has left the organization?

Assign it to the head of the sponsor’s unit as an interim owner, record that the assignment was made during migration, and ask that person to confirm or withdraw the demand within the first governance cycle. Leaving it with an unowned sponsor field is a common reason a dormant item later reappears at a board meeting with no one able to defend it.

Should requester identities and attachments be migrated?

Requester identities should be matched to current directory accounts, and records for people who no longer work for the organization should keep their name as free text rather than a live reference. Attachments are worth migrating for open items and skipped for closed ones, because a large attachment archive slows searching without helping anyone make a current decision.

How long should the legacy environment stay licensed after cutover?

Keep it only for as long as someone needs to query history on a regular basis. Once the reconciliation is signed off and the historical extract has been stored in a readable form, the environment can be retired. The retirement decision belongs to the owner of the legacy tool, with the demand lead consulted.

Next step

For the wider program, the demand management implementation roadmap shows where cutover sits in the sequence, and the SPM implementation service page describes the engagement for that stage.

Demand migration into ServiceNow: import tables, names and values to check

Moving demand records into ServiceNow Demand Management normally runs through an import set table and a transform map that writes into the demand table. Decide the coalesce field and the state mapping before loading anything, because those two choices decide whether a second run updates records or creates duplicates.

These are common out-of-box names. Check them on your own instance and release, because menu labels and defaults change between releases.

Run the whole path on a non-production instance first. Compare the staging row count with the source, then the demand count with the staging count, and write down every row that fell out and why.

Example (hypothetical): a team loads a small test set from a spreadsheet and finds the date column arrived as text, so every submitted date is blank. They fix the format in the source, run the load again, and because the transform map coalesces on a legacy identifier column, the second run updates the same demands instead of creating twins. Only then do they plan the full load.

Which field should be the coalesce field?

Use a field that holds the legacy record identifier, ideally a dedicated custom column. Coalescing on a title is risky, because two different demands often share a title and a corrected title would create a new record.

Should the first load go straight to production?

No. Load into a sub-production instance cloned from production, reconcile the counts, and let a portfolio manager review a sample by area. A production load should repeat a path that has already worked.

How do you keep the original submitted dates?

Whether an import can set the system date fields depends on how the transform map is written, so test that on a sub-production instance before relying on it. Keep the legacy date in a separate custom field as well, so reports can use it whichever way the system fields behave.

See also the data migration and import sets guide, the reconciliation and cutover service and the demand management section.