Moving to ServiceNow Agile Development: Migration Considerations

This page covers how to move existing project and backlog work into ServiceNow Agile Development. It walks through inventorying current practice, classifying work as active, archived or on hold, mapping old terms to the new ones, planning the data load, and setting rollback and sign-off criteria before cut-over.

Inventory Existing Development Work and Practices

Before moving to Agile Development, understand what exists today. Where are requirements stored? How are development tasks tracked? What project management practices are currently in place? What tools are being used?

Discovery should include: interviews with development teams, review of current tool usage (spreadsheets, Jira, Azure DevOps, email threads), assessment of process maturity, and identification of what works well and what causes friction.

Common findings: requirements are in email or documents, not in a tracking system. Tasks are tracked by individual developers, not centrally. Testing is ad hoc. No clear handoff between development and deployment. Scope creep is frequent because changes are approved informally.

These discoveries are not failures; they are inputs for design. Agile Development on ServiceNow will standardise processes, but it should build on what works and fix what does not.

Classify Work for Migration: Active, Archive, Transform

Not all existing work should move to Agile Development. Some projects are complete, some are active, some are waiting. Classify work in three buckets: Active work that needs to migrate, completed work that archives to history, and on-hold work that will migrate if resumed.

Active work: projects currently in development or backlog. These migrate to Agile Development with history preserved. Create an epic in Agile Development for each project and migrate stories and tasks into it.

Completed work: projects that finished and are now maintenance only. These move to archive status. Keep them visible for history and rollback reference but do not track them as active.

On-hold work: projects paused but not cancelled. Decide case-by-case: do they resume soon (migrate) or are they unlikely (archive)?

Map Data and Process From Old System to New

Agile Development uses specific terminology: Epic, Story, Task, Defect, Test. Old systems may use different terms (Work Item, Feature, Bug, Action). Map the old terms to the new ones so data migrations are accurate.

Mapping example: In the old system, a “Feature” maps to an Epic in Agile. A “User Story” maps to Story. A “Bug” maps to Defect. A “Test Case” maps to Test. Effort estimates in the old system (hours) map to Story Points in the new system (story points are a relative measure, not hours).

For each data type, decide whether to migrate it or start fresh. Old requirements and work items should migrate (history and context matter). Old estimates can migrate but should be recalibrated in the new system. Old test results can be archived but do not need to be active.

Process mapping: In the old system, work flows from Requirements > Development > Testing > Deploy. In Agile Development, work flows from Backlog > Sprint > Development > Testing > Deploy. The stages are different, so workflow automation must change.

Plan Data Extract and Transform

Data migration is a technical task requiring careful planning. Source data may be messy (incomplete fields, inconsistent status values, old data mixed with new). The target system expects clean data.

Plan the migration in stages: Extract old data to a staging area. Inspect and clean (remove duplicates, fill required fields, standardise values). Transform to match the new system structure. Load into Agile Development. Validate (counts, spot checks, sample reconciliation).

If the old system has millions of records, batching is necessary. Migrate active data first, archive historical data later. This reduces risk and allows time to validate before committing to the full migration.

Plan for downtime. Most migrations require freezing the old system during the data load so changes do not happen twice. Coordinate timing with the business to minimise disruption.

Identify Integration Points

Agile Development must integrate with other tools on the platform: change management, release management, deployment, testing. It may also integrate with external systems: CI/CD pipelines, code repositories, incident management.

List each integration: what data flows where, how often, what happens if an integration breaks. Agile Development should link to Change records for deployment coordination. It should link to Release records to track what is being released. It should update test results in the testing tool as tests run.

Integrations must be in place before full go-live. Test them with small data sets first. Ensure they handle failures gracefully (if an integration fails, what happens to the work item in Agile Development?).

Choose Cutover Approach: Big Bang or Phased

Big bang cutover: all work moves to Agile Development at once. Risk is high (if something breaks, all teams are stuck), but uncertainty is short (one day of pain). Suits small teams with low release frequency.

Phased cutover: one team or project moves first, others follow as they are ready. Risk is lower (one team at a time), but uncertainty is longer (weeks of partial operation). Suits larger organisations with many teams.

A hybrid approach: run old and new systems in parallel for a set period. Teams work in the new system; a bridge system copies critical data to the old system for stakeholders who are not ready to switch. After that period, old system is read-only and new system is live.

Whichever approach is chosen, plan for rollback. If the migration fails, how quickly can we go back to the old system? Having a rollback plan reduces risk and increases confidence.

Establish Validation and Sign-Off Criteria

Before declaring the migration successful, validate that the new system is working correctly. Validation includes: data counts match between old and new, critical workflows execute correctly, team members can access their work, reports produce expected results.

Define sign-off criteria: Who decides the migration is complete? What evidence is needed? How many days does the new system need to run with no critical issues before sign-off?

Plan for stabilisation: after go-live, expect to fix issues for a period. Keep resources available for rapid fixes and support. Do not go live on a Friday when support is not available.

Plan Training and Change Management

Agile Development works differently from the old system. Teams need training: how to create a story, how to estimate and commit to sprints, how to update status. Managers need to understand how to see progress and identify blockers in the new system.

Conduct training after data migration but before go-live. Use data from the old system in training so people see their own work. Have train-the-trainer sessions so team leads can support their teams after migration.

Plan for a support phase: dedicated people answering questions and fixing issues in the first two weeks after go-live. Have a clear escalation path (team lead > support specialist > platform team).

Rehearsing the cut-over before anyone relies on it

A migration plan is only as good as the rehearsal behind it. Teams that move work into a new agile tool often run the data load once, check the counts and declare victory, then discover on go-live day that the story hierarchy broke, that attachments did not follow their parents, or that a report reads the old status names. A rehearsal should be a full run against a copy of the production data, timed from start to finish, with the same people who will do the real cut-over. Record how long each step took, which steps needed a manual fix, and which checks failed the first time.

Rehearse the reverse route too, not only the forward load. A rollback that has never been run is a hope, not a plan. Ask the team to reverse the cut-over on the copy and confirm that the old system returns to a state the business can use.

Deciding what must not move

Moving everything is tempting because it feels safe. In practice, copying every old record carries the old system’s mess into the new one. Set a short list of rules for what migrates. Open work with a current owner should move. Work that was closed more than a few cycles ago can stay in the old system as a read-only reference. Duplicates, test items and abandoned drafts should be removed before the load rather than cleaned up afterwards. The aim is a new backlog that people trust, not a complete archive of everything that was ever typed.

A rollback decision table for the cut-over window

Set the rollback triggers before the window opens, while everyone is calm. Waiting until a problem appears invites a debate about whether it is serious enough to reverse, and that debate can run past the point where reversal is still easy.

What the first cycles after cut-over should look like

The first two cycles in the new tool are a probation period. Teams will be slower than usual while they relearn the work, and the instinct to speed them up by adding process should be resisted. Ask each team to read back its own sprint commitment at the first review and to point out anything in the tool that does not match the work. Those comments are the most useful source of defects in the first weeks, and they often surface problems that the test scripts missed.

Keep the old system in read-only mode for a defined period so people can check history without editing it. Once the period ends, remove the edit rights, and make sure the links from old reports point to the new location. Leaving the old system writable is a common reason work splits across two places for months.

Common questions about the move

Should we migrate the velocity history from the old tool?

Usually keep the history as a reference, not as a baseline. Velocity measured in a different tool, with different sizing habits, does not translate directly. Let the new team build its own baseline over several cycles and note in the record that the earlier figures came from another system.

Who should confirm that the data is clean enough to load?

The product owner for each product should sign off the backlog extract, because they can tell whether an item is still real. A data specialist can check formats and counts, but only the owner can say whether a story should exist at all.

Can the move be done without any downtime for teams?

Sometimes, with a hybrid run, but it adds effort and confusion because two systems must agree. For many teams a short, planned freeze on the old system during the final load is simpler and easier to reconcile. Choose the freeze window with the people whose work it will interrupt.

What do we do with attachments and linked documents?

Decide category by category. Attachments that are needed to understand active work should move with their records. Linked documents that live in a shared repository may be better left where they are and linked by address, provided that the link will still resolve after the move.

Related reading on the cut-over itself is in the data migration validation and cut-over guide.

For the broader sequence of phases and deliverables, see the implementation phases and deliverables guide.