Moving to ServiceNow UI Builder and Workspaces: Migration Considerations

From Classic Forms to Modern Workspaces: Understanding the Shift

Moving users from classic forms into UI Builder workspaces is mostly a question of what to carry across and in what order. The sections below start with an inventory of the client scripts and form customisations that must be rebuilt or dropped, then set out workspace design by persona, a phased rollout, data and process checks, training, performance and browser testing, and the parallel-running and rollback arrangements that keep the classic interface available until each group has moved.

Assessing Current Interface Customizations

Inventory all custom forms, scripts, and client-side customizations in your current ServiceNow deployment. Client scripts that perform validations, dynamically show/hide fields, or populate fields based on user selections must either be rebuilt in UI Builder or removed. Server-side business logic (workflows, database access, calculations) is not affected; UI Builder calls the same APIs. However, deeply customized forms that depend on specific CSS styling or JavaScript may need reworking to function in UI Builder. Assess the complexity and prioritize: high-value customizations worth rebuilding in UI Builder, others can be deferred or archived if they are rarely used.

Workspace Design Strategy and User Roles

Before building workspaces, understand your user personas and how they work. An IT support agent needs fast access to tickets and knowledge; a project manager needs visibility into tasks and timeline; a finance administrator needs report dashboards and approval queues. Each persona should have their own workspace tailored to their workflow. Avoid one-size-fits-all workspaces; they work for nobody. Start by identifying 3-5 primary user personas, then design a workspace for each. Include mock users in the design process; ask them if the workspace makes their job easier or adds friction. Workspace design is iterative; plan time for refinement based on user feedback before launch.

Migration Approach: Phased Rollout by Persona

Phase 1 – Foundation: Build core workspaces for your primary user personas (support agents, managers, administrators). Keep these simple initially; add advanced features in later phases. Phase 2 – Pilot: Roll out workspaces to a subset of users in each persona group. Collect feedback on usability, completeness, and performance. Identify what is missing or confusing. Phase 3 – Refinement: Based on pilot feedback, refine workspaces before broader rollout. Add missing capabilities, simplify confusing sections, optimize performance if dashboards are slow. Phase 4 – Full Rollout: Expand workspaces to all users in the persona group. Phase 5 – New Personas: Repeat the process for secondary user personas (reporting users, workflow designers, data managers).

Data and Process Considerations

Workspaces display data but do not change how data is stored or processed. Your data model (fields, tables, relationships) remains the same. The workspace is the presentation layer; underlying business logic in ServiceNow (workflows, event rules, scripts) continues to work. However, ensure that the information users need in their workspace is accessible through APIs and data queries. If a workspace needs to show custom fields, ensure those fields exist and are populated. If a workspace needs to perform actions, ensure those actions are exposed as APIs or workflow triggers. Coordinate with your data and process teams to ensure the workspace has what it needs.

Adoption and Training Planning

Users have workflows built around the old interface; moving to a new workspace disrupts those workflows. Expect resistance initially. Provide training early: let users explore workspaces in a sandbox before launch. Explain what changed and why (usually: better organization, faster navigation, easier on mobile). Show quick wins: a workspace that completes a common task in 3 steps instead of 7. Support early use intensively; have trainers and subject matter experts available the first week to help users transition and answer questions. Track adoption metrics: how many users are using their assigned workspace? If adoption lags after two weeks, investigate what is wrong (too complex, missing data, performance issues) and adjust before expanding.

Performance and Browser Compatibility

Workspaces with many widgets and real-time dashboards can be slow on older browsers or slower networks. Test workspace performance with realistic data volume (full data, not test samples) and in different network conditions. Optimize heavy dashboards by limiting data, using filters to reduce records fetched, and deferring non-critical widgets until after initial load. Test on the browsers your users actually use (not just Chrome on a fast corporate network). Mobile experience is important; test workspaces on phones and tablets and adjust layouts for smaller screens.

Parallel Running and Rollback

Keep the old interface accessible during initial rollout so users can fall back if the workspace is incomplete or confusing. Parallel running should last as long as users need to adopt the workspace. Once adoption is widespread, you can retire the old interface. Document the rollback procedure: if a workspace has a critical issue, can you revert users to the old interface quickly? Plan for this scenario and test it.

Inventory what the classic experience quietly does for people

Moving a team from a classic form or list into a workspace breaks habits that nobody wrote down. Bookmarks point at old addresses. Email notifications contain links that open the classic record. A saved list view was set up years ago and is the only thing that shows one team its work. Before any screen is rebuilt, list what the current experience gives people in ways that are not part of the design, because those are the things users miss on the first morning. The explanation of UI Builder pages is useful for mapping each classic element to its new equivalent.

Keep the classic address working until people have moved

A common cutover failure is a link that stops working on the day the workspace goes live. An employee clicks a notification from last week, lands on an error, and concludes that the new tool is broken. Plan the parallel period as a period in which both addresses resolve, and make a deliberate list of which notifications will be re-pointed and when. Only retire a classic address after the notification that uses it has been changed and the change has been checked with a real message. The mistakes that often appear at this stage are covered in the common mistakes guide for these workspaces.

An ordered cutover sequence

1. Build the inventory above for each classic view that the target group uses, and name the owner of each item.
2. Decide which items move, which are rebuilt and which are dropped, and record the reason beside each decision.
3. Re-point notifications and saved links in a test environment first, and send a real test message to a member of the pilot group.
4. Release the workspace to the pilot group while keeping the classic view available to them.
5. Track which people still open the classic view each day, and contact them directly rather than waiting for the numbers to drop on their own.
6. Retire the classic view for the group only after the notification links, saved views and mobile routes have been confirmed by the group’s own lead.

Where the migration should stop

Not every classic view deserves a workspace, and the implementation roadmap explains how to sequence the views that do. Some views serve a small audience that the workspace would not improve, and rebuilding them costs more than the benefit. A second reason to stop is when the business process behind the view is about to change. Migrating a screen that is due for redesign means twice the work. Mark these views as deferred, keep them running and review them again when the process has settled.

Questions teams ask during cutover

Will users lose their personal settings when they move?

Some personal settings, such as favorite lists and default filters, do not move automatically. Tell users which settings will need recreating, and give them a short written guide that matches the new screen rather than the old one.

Should the old view be hidden or left visible during the transition?

Leave it visible to the pilot group and make the new route the default in navigation. Hiding the old view completely forces people to ask for help on day one, and that help desk load is easy to underestimate.

How do we know a classic element is still in use?

Ask the group’s lead to walk through a normal week, then check the usage of the view and its related notifications over the same period. Usage data shows what is opened, and the walk-through shows what people rely on without opening it.

Can a workspace keep the classic form’s exact layout?

It can, but usually should not. Copying a layout faithfully keeps the layout’s weaknesses, and the client script explanation helps identify which old behavior is worth carrying forward. Use the classic layout as a checklist of fields and actions, then design the screen around the task the group performs.