---
title: "ServiceNow ITSM Agent Workspace Deprecated: 2026 Migration Guide"
slug: servicenow-itsm-agent-workspace-deprecated-2026-migration-guide
date: 2026-07-10
author: Roopi
categories: [ServiceNow]
excerpt: "ServiceNow deprecated ITSM Agent Workspace in late 2024. What the SOW Migration Utility covers, what you must rebuild in UI Builder, and your 2026 options."
tldr: "ITSM Agent Workspace is deprecated and classified as custom code. The free SOW Migration Utility handles basic config, but landing pages, roles, and custom UI must be rebuilt manually in UI Builder."
canonical: https://clonepartner.com/blog/servicenow-itsm-agent-workspace-deprecated-2026-migration-guide/
---
# ServiceNow ITSM Agent Workspace Deprecated: 2026 Migration Guide
ServiceNow ITSM Agent Workspace is deprecated. It entered the **Deprecation State** in late 2024, and ServiceNow will not ship new features, bug fixes, maintenance patches, or technical support for it going forward. The workspace plugin remains active in your instance — ServiceNow isn't pulling the plug — but it is now classified as **custom code**. That classification matters: ServiceNow's technical support team is no longer obligated to help you with it.
The official replacement is **Service Operations Workspace (SOW)**, a configurable workspace built on ServiceNow's Next Experience UI Builder that unifies ITSM and ITOM workflows. ServiceNow provides a free Migration Utility to move configurations from the legacy workspace to SOW. But the utility has hard limits, and the architectural gap between the two workspaces is wider than the surface-level similarity suggests.
This guide breaks down what the deprecation means technically, what the Migration Utility covers, what you'll have to rebuild manually, typical migration effort ranges, and whether this is the right moment to leave ServiceNow entirely.
*Last verified against Migration Utility v2.3.1, May 2025. This guide is updated with each major utility release.*
## What "Deprecated" Actually Means for Your ServiceNow Instance
**Deprecated does not mean removed.** Your ITSM Agent Workspace will continue to function. Agents can still log in, work incidents, and manage changes. But the implications are real and compounding:
- **No bug fixes.** If a defect surfaces in a future platform upgrade that breaks your workspace, ServiceNow has no obligation to patch it.
- **No maintenance patches.** Security vulnerabilities discovered in the legacy workspace code will not be addressed.
- **No new features.** Every capability ServiceNow ships — Now Assist, Agentic AI workflows, the L1 Service Desk AI Specialist — is being built for configurable workspaces, not the legacy one.
- **"Custom code" classification.** If you open a support case that touches your Agent Workspace, ServiceNow can decline it.
Once deprecated, the workspace "will no longer be deployed, enhanced, upgraded, improved, or supported" and "will be considered custom code" — ServiceNow's technical support is "not obligated to provide any services for it, including but not limited to the customer or technical support, maintenance patches, and/or bug fixes."
The practical risk isn't that your workspace disappears tomorrow. It's that every ServiceNow platform upgrade becomes a gamble. The longer you stay on the deprecated workspace, the higher the probability that an upgrade introduces a breaking change nobody at ServiceNow will fix for you.
One detail that helps with planning: Agent Workspace and configurable workspaces can coexist on the same instance. ([servicenow.com](https://www.servicenow.com/community/next-experience-articles/learn-about-the-differences-between-agent-workspace-legacy-and/ta-p/2332026)) That gives you room for pilot groups instead of a hard cutover. The catch is that some shared elements — including ribbons and form headers — can affect both workspaces, so a parallel run is useful but not fully isolated.
> [!WARNING]
> ServiceNow's AI capabilities — including Now Assist and Agentic AI workflows — are being built exclusively for configurable workspaces. Staying on the deprecated Agent Workspace means falling further behind on AI-powered ITSM features with each release cycle.
## What You Gain by Moving to Service Operations Workspace
Before diving into migration mechanics, it's worth understanding what SOW delivers beyond feature parity. This is not a lateral move — SOW introduces capabilities that Agent Workspace cannot match:
- **Unified ITSM and ITOM views.** SOW merges IT service management and IT operations management into a single agent experience. Agents can see alert-to-incident correlation, health log analytics, and event management data alongside their ticket queue without switching workspaces.
- **Next Experience performance.** SOW is built on ServiceNow's Next Experience framework, which uses client-side rendering and component-level lazy loading. Organizations with 500+ concurrent agents have reported measurably faster page load times compared to Agent Workspace's server-rendered architecture.
- **AI feature access.** ServiceNow demonstrated the L1 Service Desk AI Specialist within the Service Operations Workspace UI, showing that agentic AI capabilities — including auto-triage, suggested resolutions, and conversational case handling — are surfaced in configurable workspaces specifically. Now Assist's generative AI summarization, field auto-population, and knowledge article recommendations are also exclusive to configurable workspaces.
- **Theme Builder with accessibility feedback.** SOW's branding system provides real-time WCAG contrast ratio checks, which Agent Workspace's color picker did not.
- **Page variants and audience targeting.** While more complex to configure, SOW's audience-based page variant system is significantly more powerful than Agent Workspace's role-to-landing-page mapping, supporting combinations of role, group, location, department, and custom conditions.
Understanding these gains matters for your business case. The migration has real costs, but the destination is a materially better platform — not just a reskinned version of what you had.
## How the SOW Migration Utility Works (and What It Misses)
ServiceNow provides the **Migration Utility for Service Operations Workspace** as a free app in the ServiceNow Store (application ID: `sn_sow_migration`). It's designed to move common configurations and customizations from ITSM Agent Workspace to SOW.
### Version Compatibility Matrix
| Migration Utility Version | Minimum ServiceNow Release | Key Additions |
|---|---|---|
| 1.0.x | Washington DC | Initial release — core form/list migration |
| 2.0.x | Washington DC | Added support for additional declarative action types |
| 2.3.1 | Washington DC | Added ITSM child task table migration support |
The utility requires the Washington DC release or later. Verify your exact platform version and utility dependencies before scoping your migration — check the [ServiceNow Store release notes](https://www.servicenow.com/docs/r/store-release-notes/store-rn-itsm-migration-utility-sow.html) for the latest compatibility details.
### What the Utility Does
The utility supports two modes: **partial migration** (select specific features to migrate, return later for the rest) and **complete migration** (migrate everything at once). Once a feature has been successfully migrated, it cannot be migrated again.
During migration, the utility creates separate update sets, one for each SOW scoped application. You can export each update set as XML and apply it to other instances independently — useful for organizations managing multiple sub-production environments.
If features fail to migrate, you can re-run the migration for those specific features after correcting the errors. But successfully migrated features are locked. There is no revert. If something migrates incorrectly, your options are to fix it manually in SOW or reset the entire sub-production instance and start over.
At a high level, this is the split you should plan around:
- **Usually migrates:** UI actions and layouts, ribbons, view rules, new record menu items, highlighted fields, list actions, list categories/modules, form headers, search configurations, agent assist, related list declarative actions, and field decorators.
- **Already works in both workspaces:** Workspace notifications, agent chat, activity stream, Advanced Work Assignment (AWA), playbooks, email client, templates, record tags, and list export/import/refresh prompts.
- **Will not migrate:** Landing pages, workspace roles and permissions, branding colors/logo, workspace modules, and custom UI components.
### Custom ITSM Tables Require Explicit Inclusion
If you have custom ITSM tables, the utility will not automatically pick them up. You must add each table to the `sn_sow_migration.itsm_aw_migration_tables` system property for the utility to include associated list categories, list actions, related list actions, and **New record** menu items. ([servicenow.com](https://www.servicenow.com/docs/r/it-service-management/service-operations-workspace/configure-migration-custom-table-to-sow-itsm.html))
### What Cannot Be Migrated
This is where the migration gets expensive. The utility cannot handle:
| Configuration | Why It Can't Migrate | What You Must Do Instead |
|---|---|---|
| **Landing pages** | SOW uses UI Builder page variants and audiences — a fundamentally different architecture | Rebuild in UI Builder using page variants and the `sys_ux_applicability` table |
| **Workspace roles** | Agent Workspace used the `sys_aw_list` table with a Roles column; SOW uses audience-based visibility | Create audiences via `sys_ux_applicability` and map them with `sys_ux_applicability_m2m_list` |
| **Branding / colors** | SOW uses Theme Builder, not workspace-level color settings | Configure via Theme Builder, which also provides WCAG accessibility contrast feedback |
| **Custom UI components** | Legacy components use different action models | Rebuild as UXF Client Actions with Declarative Actions in UI Builder |
| **Workspace modules** | Different navigation architecture | Recreate in SOW's navigation model |
> [!NOTE]
> The Migration Utility must be run on a **non-production instance** first. Always create an update set before starting the migration to capture all changes. If a successfully migrated feature turns out to be wrong, there is no undo button — your real safety net is backup, restore, or re-clone discipline.
## The UI Builder Bottleneck: What You Have to Rebuild Manually
At first glance, SOW looks similar to Agent Workspace. The layout is familiar — tabs, lists, forms, a record page. But the underlying architecture is fundamentally different, and this is where most migration timelines blow up.
**Agent Workspace** used checkbox-based configuration. You toggled settings on and off in configuration tables. It was opinionated but predictable.
**Service Operations Workspace** uses UI Builder — a component-based, JSON-configured framework. The workspace experience utilizes UI Builder to provide a modular foundation which can be amended or extended according to customer specific requirements. That modularity comes at a cost: complexity.
ServiceNow's own guidance is direct: "When migrating from Agent Workspace to a configurable workspace, treat the migration as a re-implementation." That's not a throwaway line. Budget accordingly.
### Estimated Migration Effort by Complexity Tier
Based on observed migration patterns, these ranges provide rough planning guidance:
| Customization Level | Typical Indicators | Estimated Migration Effort |
|---|---|---|
| **Light** | <20 custom UI actions, no custom landing pages, standard form layouts, minimal client scripts | 4–8 weeks, 1–2 developers |
| **Moderate** | 20–75 custom UI actions, 2–5 role-based landing pages, custom ribbons, some client-side scripting | 8–16 weeks, 2–3 developers |
| **Heavy** | 75+ custom UI actions, complex role-based landing pages, extensive client scripts, custom UI components, bespoke navigation | 16–30+ weeks, 3–5 developers with UI Builder experience |
These estimates cover the UI layer rebuild only. Server-side configurations (business rules, Flow Designer flows, table structures) generally carry over without rework.
### Specific Areas That Require Manual Rebuilds
**Custom ribbons.** SOW does not have the ribbon functionality built in like Agent Workspace did. If your agents rely on custom ribbon configurations showing key record data at a glance, you'll need to recreate that layout directly in UI Builder. The underlying `sys_aw_ribbon_setting` table configuration does not carry over.
**UI Actions on forms.** UI Actions are supported in configurable workspaces but only in limited areas, such as the Action Bar component on the record page — they are not supported on lists. If you have client-side UI Actions that trigger modals, navigate to custom pages, or manipulate form fields, you'll need to rebuild them as Declarative Actions implemented as either Server Scripts or UXF Client Actions.
**Role-based landing pages.** In Agent Workspace, different roles saw different landing pages through relatively straightforward configuration. In SOW, your landing page is determined by the first audience you are identified as being a member of, where audiences are collections of users identified by attributes such as roles or group membership. Setting up role-based landing pages requires configuring page variants in UI Builder and linking them to audience records — more powerful but significantly more complex.
**Client scripts.** ServiceNow support has indicated that you can't bind client scripts to UXF Client Actions. If your existing workspace customizations rely heavily on client-side scripting, expect to refactor them as event handlers in UI Builder or as server-side Declarative Actions.
### Common Post-Migration Failure Modes
These are specific issues observed during SOW migrations that the documentation doesn't always surface:
1. **AWA routing rules with workspace-specific conditions.** If your Advanced Work Assignment rules reference Agent Workspace-specific conditions (e.g., workspace name in assignment criteria), they may silently stop evaluating after migration. Audit all AWA rules that reference `sys_aw_*` tables.
2. **Declarative Actions with UI Component implementation type.** Actions that were implemented as "UI Component" in Agent Workspace fail in SOW. The remediation requires clearing the Workspace and View fields, checking **Experience Restricted**, changing **Implemented as** to **UXF Client Action**, and adding **SOW Actions** in Action configuration. ([servicenow.com](https://www.servicenow.com/docs/r/it-service-management/service-operations-workspace/migrate-related-list-ui-component-aw-sow.html))
3. **Form view mismatches.** Agent Workspace and SOW can use different form views for the same table. If your Agent Workspace used custom views (e.g., `ess` or `agent`), verify which view SOW resolves to — it defaults to the `Default view` unless a view rule is explicitly configured.
4. **Contextual search scope drift.** Agent Workspace search configurations that scoped results to specific tables may not carry over with the same precision. Verify search result relevance after migration, particularly for knowledge and catalog item searches.
5. **Notification action misrouting.** Workspace notifications that included deep links to Agent Workspace records will point to the wrong workspace URL post-migration. Update notification templates to use SOW's URL structure.
### Rebuilding Custom UI Components as UXF Client Actions
To migrate custom UI components, you transition them to the new framework by updating the `Implemented as` field to **UXF Client Action** and writing the action configuration payload in JSON. Instead of checking boxes to define behavior, you define event handlers and payloads programmatically.
**Before (Agent Workspace):** A custom "Resolve Incident" button was configured via the Declarative Action table with a UI Component implementation, pointing to a widget that set field values through client-side GlideForm calls.
**After (SOW):** The equivalent action requires a JSON payload defining the table, sys_id reference, and field updates:
```json
{
"name": "resolve_incident_custom",
"actionType": "UXF_CLIENT_ACTION",
"payload": {
"table": "incident",
"sysId": "@context.props.sysId",
"fields": {
"state": "6",
"close_code": "Solved (Permanently)",
"close_notes": "Resolved via automated workspace action."
}
}
}
```
**Before (Agent Workspace ribbon):** The `sys_aw_ribbon_setting` table allowed you to select fields (priority, assignment group, SLA due date) to display in the record ribbon via checkbox selection.
**After (SOW):** You must create a custom component in UI Builder, bind each field to a data resource querying the record, and position the component in the record page's header region. There is no built-in ribbon component.
The ServiceNow community has been vocal about the learning curve. As one community member put it: "there's no such thing" as the base that Agent Workspace provided, and "UI builder skips between its own UI and back to core UI, documentation is very limited and we've regressed from checkboxes to having to write JSON in a tiny window."
### The Server-Side Silver Lining
As a general rule, anything that happens server side should work as before when migrated to SOW, but anything client side should be reviewed, checked, and may need to be refactored or reimplemented. Your business rules, server-side workflows, Flow Designer flows, and table structures carry over. The migration cost is concentrated in the UI layer — which is exactly the layer that matters most for agent experience.
## How to Execute the SOW Migration Safely
If you choose to stay on ServiceNow and upgrade to SOW, follow these steps.
### Step 1: Freeze new Agent Workspace customizations
Stop adding Agent Workspace-only customizations before you audit. Every new AW-only change increases migration debt. Document what exists and categorize each item: migrate, rebuild, or retire.
### Step 2: Provision a dedicated sub-production environment
Clone your production instance to a dedicated sandbox. Never run the migration utility in production first. Because successfully migrated features cannot be reverted, you need an environment you can wipe and reset.
### Step 3: Install the utility and add custom tables to scope
Install the Migration Utility from the ServiceNow Store. Verify the utility version matches your platform release (see the compatibility matrix above). If you have custom ITSM tables, add them to `sn_sow_migration.itsm_aw_migration_tables` before running any migration.
### Step 4: Run a partial migration first
Do not select "Complete Migration" on your first run. Start with a partial migration of a low-risk feature set (e.g., standard Requests) to understand how the utility maps legacy configurations into the Next Experience architecture.
### Step 5: Review results and fix failures
After the utility runs, review the migration details and logs. If features failed, correct the errors identified in the logs and re-run the utility for those specific features only. Pay specific attention to the five common failure modes documented above.
### Step 6: Rebuild what the utility cannot migrate
Assign developers to rebuild landing pages using UI Builder page variants and audiences. Reconfigure workspace roles via the `sys_ux_applicability` table. Set up branding in Theme Builder. Convert custom UI components to UXF Client Actions with Declarative Actions.
### Step 7: Validate with a pilot group
Before full rollout, enable SOW for a small pilot group (10–20 agents across different roles) while keeping Agent Workspace active for the remaining population. Run both workspaces in parallel for 2–4 weeks. Collect feedback on: page load performance, missing functionality, broken navigation, and agent workflow efficiency.
### Step 8: Export update sets, test, and go live
Export each update set created during migration as XML. Upload and apply them to your staging instance. Validate form layouts, list configurations, landing pages, role-based access, and all rebuilt custom components end-to-end before enabling SOW for production agents.
## The 2026 Decision: Upgrade to SOW or Switch ITSM Platforms?
The deprecation creates a fork in the road. For organizations deeply invested in ServiceNow's broader ecosystem — ITOM, CMDB, SecOps, HRSD — upgrading to SOW is the natural path. But for teams that primarily use ServiceNow for ITSM and have accumulated significant customization debt, this is a legitimate inflection point to evaluate alternatives.
### Why 2026 Is the Inflection Point
Three forces are converging:
1. **The deprecation itself.** Every release cycle increases risk on the legacy workspace.
2. **ITIL Version 5.** ITIL Version 5 launched in 2026, introducing AI governance as an integral part of the framework, with structured guidance on adopting AI responsibly. SOW's configurable workspace architecture supports ITIL 5's emphasis on AI-assisted service management through Now Assist integration, automated categorization, and predictive intelligence — capabilities that require the Next Experience framework and cannot be retrofitted into Agent Workspace. Organizations modernizing their ITSM practice are simultaneously adopting SOW and ITIL 5, making this a natural moment to align tooling with methodology.
3. **ServiceNow's AI investment.** ServiceNow demonstrated the L1 Service Desk AI Specialist within the Service Operations Workspace UI, showing that their agentic AI capabilities are surfaced in configurable workspaces specifically. Staying on the legacy workspace means missing these capabilities entirely.
### When Upgrading to SOW Makes Sense
- You use ServiceNow for ITSM **and** ITOM, and SOW's unified workspace is a genuine operational improvement
- Your customizations are relatively light — primarily form layouts, list configurations, and standard UI policies (see "Light" tier above)
- You have ServiceNow platform developers on staff who can work in UI Builder
- Your organization is investing in Now Assist or Agentic AI features
- You rely on CMDB-linked workflows, change management, or SecOps integrations that are tightly coupled to the ServiceNow platform
### When Switching Platforms Makes More Sense
- Your ServiceNow instance is primarily used for ITSM with heavy UI customizations that will be expensive to rebuild (see "Heavy" tier above — 16–30+ weeks of re-implementation work)
- You don't have — and don't want to hire — dedicated ServiceNow developers to maintain a UI Builder-based workspace
- Your team has been frustrated by the platform's complexity and this deprecation is the last straw
- You're paying enterprise ServiceNow licensing primarily for ITSM ticket management without using ITOM, CMDB, or cross-platform workflows
- You're evaluating lighter-weight alternatives that don't require a dedicated platform team to operate
### Alternative ITSM Platforms
**Jira Service Management:** For engineering-heavy organizations, JSM offers a developer-friendly, agile ITSM alternative. Published per-agent pricing (Standard: $17.65/agent/month, Premium: $44.27/agent/month for cloud) with no requester or approver seat costs. Integrates natively with Jira Software, bridging IT support and development. Weaker fit for organizations needing deep CMDB, ITOM, or enterprise change management workflows. Read our [ServiceNow vs Jira Service Management Architecture Guide (2026)](https://clonepartner.com/blog/blog/servicenow-vs-jira-service-management-architecture-guide-2026/) for a detailed technical comparison.
**Freshservice:** Provides out-of-the-box ITIL workflows (incident, problem, change, release, asset management) without requiring JSON payloads or UI Builder configuration. Admin-level configuration through point-and-click interfaces. Suitable for teams with 50–500 agents who want rapid time-to-value. Lacks ServiceNow's depth in ITOM, GRC, and cross-enterprise workflows. See our [ServiceNow vs Freshservice: The CTO's 2026 Architecture Guide](https://clonepartner.com/blog/blog/servicenow-vs-freshservice-the-ctos-2026-architecture-guide/) for a technical breakdown.
**Zendesk:** Strongest fit when your actual use case is employee request handling, knowledge management, and conversational support rather than deep ITSM. AI-powered internal support with out-of-the-box intent detection and automated resolution. Weakest fit of the three if you rely on ServiceNow for change management, CMDB, or ITOM-linked workflows.
### The Cross-Platform Migration Complexity
Switching platforms does not erase migration work — it changes where the work sits. Instead of rebuilding inside UI Builder, you spend effort on data mapping, workflow translation, and deciding which ServiceNow-specific behaviors should survive.
ServiceNow's data model uses `sys_id` references across tables extensively. Incident, problem, change, and CMDB records are all relationally linked. Any cross-platform migration needs to:
- **Preserve relational integrity** — parent/child ticket relationships, CMDB CI associations, and change-to-incident linkages
- **Map ITIL process data** — ServiceNow's task table hierarchy (`task` → `incident`, `problem`, `change_request`, `sc_request`) doesn't map 1:1 to flat-ticket platforms
- **Handle journal fields** — work notes and comments are stored in `sys_journal_field`, a separate table from the main record, requiring joins on `element_id`
- **Extract attachments** — stored in `sys_attachment` and `sys_attachment_doc`, with binary data chunked across rows
For a deep dive into these specific hurdles, see [10 ServiceNow Data Migration Challenges & How to Overcome Them](https://clonepartner.com/blog/blog/10-servicenow-data-migration-challenges-how-to-overcome-them/).
## How ClonePartner Handles ServiceNow Workspace Migrations
Whether you're upgrading to SOW or migrating to a new ITSM platform entirely, the challenge is the same: moving complex, relational ITSM data without losing history, breaking workflows, or taking your service desk offline.
ClonePartner has executed 1,500+ data migrations across ITSM platforms, including ServiceNow-to-ServiceNow and ServiceNow-to-external migrations. Our approach:
- **Customization audit first.** Before touching any data, we map every customization in your legacy Agent Workspace — custom ribbons, form layouts, client scripts, UI policies, Declarative Actions — and categorize them: migrate, rebuild, or retire. This prevents you from carrying forward technical debt that should have been left behind.
- **Zero-downtime execution.** Your IT service desk stays fully operational during migration. Agents keep working tickets while we handle the data layer in parallel.
- **Relational data integrity.** For cross-platform migrations, we programmatically map ServiceNow's `sys_id` reference chains to the target platform's data model — preserving parent/child relationships, CMDB associations, and full conversation history.
- **SOW configuration assistance.** For intra-platform upgrades, we help teams navigate the UI Builder rebuild — handling the landing page, role-based audience, and Declarative Action configurations that the Migration Utility can't touch.
## Making the Call
The ITSM Agent Workspace deprecation is not a fire drill — your workspace won't stop working tomorrow. But it is a forcing function. Every ServiceNow release that passes without migrating increases your exposure to breaking changes with no support safety net.
If you're staying on ServiceNow, start the SOW migration in a sub-production instance now. Run the Migration Utility, assess what breaks, and budget for the UI Builder rebuild. The utility handles the straightforward configurations; the landing pages, roles, custom UI components, and client-side scripting are where the real engineering effort lives. For a lightly customized instance, expect 4–8 weeks; for a heavily customized one, plan for a quarter or more of dedicated developer time.
If this deprecation has you questioning whether ServiceNow is still the right fit, that's a valid conversation — especially if your team's primary pain point is the platform's increasing complexity. The migration to SOW isn't a simple upgrade; it's a re-implementation. For some organizations, re-implementing on a simpler platform makes more sense than re-implementing on a more complex one.
Either way, the worst option is doing nothing and hoping the deprecated workspace keeps working forever. It won't.
> Whether you're upgrading to Service Operations Workspace or migrating off ServiceNow entirely, ClonePartner's engineering team can audit your customizations, map your data, and execute the migration with zero downtime. Book a 30-minute call to scope your project.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)
## Frequently asked questions
### Is ServiceNow ITSM Agent Workspace being removed?
No. The workspace plugin remains active in your instance, but ServiceNow will no longer provide bug fixes, maintenance patches, new features, or technical support. It is classified as 'custom code,' meaning ServiceNow support can decline cases related to it.
### What does the ServiceNow SOW Migration Utility do?
The free Migration Utility (application ID: sn_sow_migration, available in the ServiceNow Store) migrates common configurations from ITSM Agent Workspace to Service Operations Workspace. It supports partial and complete migration modes. It cannot migrate landing pages, workspace roles, branding, or custom UI components — those must be rebuilt manually in UI Builder.
### Can I revert a migration done with the SOW Migration Utility?
No. Once a feature has been successfully migrated, it cannot be reverted or re-migrated. If something migrates incorrectly, you must fix it manually in SOW or reset your sub-production instance and start over. Features that failed can be corrected and re-run. Always run the utility in a non-production environment first.
### What is the difference between Agent Workspace and Service Operations Workspace?
Agent Workspace used checkbox-based configuration and was built on legacy workspace technology. Service Operations Workspace (SOW) is built on ServiceNow's Next Experience UI Builder, using JSON-based, component-driven configuration. SOW is more flexible and supports ITSM and ITOM in a single workspace, but requires more technical skill to customize.
### Should I migrate to SOW or switch to a different ITSM platform?
If you use ServiceNow broadly (ITOM, CMDB, SecOps, HRSD) and have platform developers on staff, upgrading to SOW is the natural path. If you primarily use ServiceNow for ITSM, have heavy customization debt, and lack dedicated platform developers, switching to a lighter platform like Jira Service Management or Freshservice may be more cost-effective than re-implementing in UI Builder.