Moving to ServiceNow Update Sets and Release Management: Migration Considerations

What to Inventory from Legacy Systems

Before migrating to ServiceNow Update Sets and Release Management, inventory all current customizations (plugins, code changes, configuration), all integrations, all workflows and approvals. This inventory shows the scope of migration and helps plan the cutover. For each change, document the business purpose, deployment history, and owner so you can assess criticality and understand dependencies. Include configuration changes (tables, fields, workflow definitions), code changes (business rules, scripts, web services), plugin installations and versions, and any manual processes or documentation that support change deployment.

Data and Process Mapping

Map your current change management process to ServiceNow Update Sets. How are changes currently requested, approved, tested and deployed? Who are the decision-makers and approvers? What documentation is required before deployment? What testing must occur? Map your current change approval committee (CAB) to the change advisory board in ServiceNow. Identify the steps where Update Sets will streamline or change the process: instead of manual export/import procedures, Update Sets automate this. Document the target process before implementation; this becomes your configuration blueprint. If you skip this step, you end up configuring Update Sets to match old broken processes rather than improving them.

Update Set Strategy and Grouping

Decide how to group changes into Update Sets. One Update Set per change? One Update Set per environment promotion (dev to test to prod)? One Update Set per release? The approach affects traceability, risk management, and deployment timing. Many organizations use one Update Set per logical feature or fix; this allows selective deployment and rollback. Decide whether to use automatic generation (ServiceNow automatically collects changes) or manual curation (your team explicitly adds changes to an Update Set). Manual curation gives better control but requires more discipline. Automatic generation is easier but can include accidental changes.

Cutover Options and Sequencing

Option one: Big bang cutover where all change management moves to ServiceNow Update Sets at once. Faster but higher risk because all teams must adopt the new process simultaneously. Use this approach only if your current change management is very simple or nonexistent. Option two: Phased cutover by change type means moving standard changes first (low risk), then normal changes, then emergency changes (high risk). Teams learn with low-risk changes first and gain confidence. This is slower but lower risk. Option three: Phased cutover by team means moving one team to Update Sets first, then gradually adding other teams. This spreads the burden and allows you to refine the process based on early feedback. Choose based on your organization’s change volume and risk tolerance.

Risks of Migration and Mitigation Strategies

Risk one: Loss of change history if old records are not archived properly. Mitigation: export all change history from the old system and archive it in ServiceNow or external storage before decommissioning the old system. Risk two: Process chaos during transition if not managed carefully. Mitigation: clear communication about the new process before cutover, training for all teams, parallel running for a period set by the team where both old and new processes work. Risk three: Resistance from teams who are comfortable with old processes. Mitigation: involve teams early in design and demonstrate how Update Sets make their job easier (automated tracking, audit trails, version control). Risk four: Incomplete data migration or missing configuration. Mitigation: do a dry run migration first, verify data completeness and accuracy, have a rollback plan if something is missing.

Update Set Testing and Validation

Before cutover, validate that ServiceNow can handle your change volume and complexity. Create test changes and verify that Update Sets capture the changes correctly. Test deployment: do Update Sets deploy successfully from dev to test to production without errors? Test rollback: can you retrieve a previous Update Set and deploy it to revert changes? Verify the audit trail captures who made changes and when. Identify gaps in Update Set functionality and address them before full cutover. Common gaps: missing plugins or custom code not captured by Update Sets, integration changes not captured, or processes requiring approval routing not yet configured.

Version Control and Change Tracking

Update Sets provide version control and change tracking that many legacy systems lack. Establish naming conventions so Update Sets are easily identifiable, for example a project code, a short feature description and the month of the change. Document what each Update Set contains in a summary or description. Link Update Sets to change requests in your ticketing system so the relationship between business change request and technical Update Set is clear. Use Update Set tracking to produce change reports showing what was deployed when and by whom.

Deployment and Rollback Procedures

Document deployment procedures: who can deploy Update Sets, to which environments, with what approvals. Define a deployment window: during business hours or after-hours? Weekdays only or can you deploy on weekends? How long must you allow for deployment before rollback becomes too risky? Create a rollback procedure: if deployment fails or causes unexpected issues, how quickly can you revert to the previous version? Rollback should take minutes to hours, not days. Test your rollback procedure; do not assume it will work during a crisis.

Baseline the instance before moving anything

A migration into a managed release process starts from what already exists, not from the process as designed. Many instances carry changes that were made directly in production by administrators, customizations to standard records that were never recorded in any set, and scripts copied between environments by hand. Those changes are the ones that collide later. Build a baseline first: list the customized records, identify which were captured in a set and which were not, and note the changes that have no owner. The baseline is the input to every later decision in this list.

Deciding what the old process carries forward

Upgrade collision risk from earlier customizations

Customizations made directly on standard records can collide with later platform upgrades, sometimes long after the change was made. Those collisions tend to appear as a preview problem during the next release, which is why they are easy to blame on the new process. Identify each customization on a standard record, decide whether it is still needed, and where it is needed, move it into a named set so its history is visible. Where a customization can be removed in favor of the standard behavior, removing it is usually the cheapest way to reduce future collisions.

Stop criteria for the cutover

• Any production change in the last cycle has no matching set or change record.
• The back-out path has not been run in a lower environment against the same customizations.
• The approver for production commits is the same person who built the change.
• Collisions found in a rehearsal preview have not been decided and recorded.
• The team that supports the platform has not been briefed on the new approval route.

Keeping two change routes open during the transition

A period in which both processes are live is common and useful, but it needs a rule. Name the tool that is authoritative for each kind of change, and state the date from which the other tool stops accepting new work. Without that rule, the same change gets recorded twice, or not at all. Review the overlap at each release until the old process has no open items left. The implementation roadmap is a reasonable place to record the agreed end condition.

Questions about migrating into managed releases

Should we migrate the history of old change records?

Migrate what is needed to answer audit questions and archive the rest. Full history migration is expensive, and most of it is never read. Decide the retention need with the audit function before the migration scope is set.

What if a legacy customization is business critical and nobody knows how it works?

Treat it as a discovery item and keep it out of the first cutover. Document what it does by observing behavior in a test environment, then decide whether to rebuild, replace or retain it. Moving an unexplained change into a set only preserves the problem in a new place.

How long should the side-by-side period last?

Long enough to clear the open items, and no longer than the team can keep both records accurate. Set the end condition as an observable state, such as no open legacy changes, rather than a calendar date.

Next step

The migration reconciliation controls notes cover how to prove data integrity after a move.