Agile Development 2.0 → Collaborative Work Management: What Changed?

If your team has been running agile delivery on ServiceNow using Agile Development 2.0, you need to understand what is happening with that module, because the decision has been made, the timeline is set, and waiting until renewal to look at it is the wrong approach.

ServiceNow deprecated Agile Development 2.0 in new instances with the Australia AI Platform release in May 2026. End of Sale took effect in April 2026. End of Renewal for the Agile Teams SKU is currently planned for January 2027. Agile Development 2.0 is planned for deprecation in August 2030. Collaborative Work Management (CWM) is the designated replacement for team-level Agile work.

This is not a situation where you can defer indefinitely. Once your subscription term ends, Agile Development 2.0 becomes custom code, meaning your team owns the maintenance, the compatibility testing on each release, and any breakage it causes. The path forward is CWM, and the question teams should be asking now is what that transition actually involves.

Deprecation Timeline

April 2026	End of Sale, Agile Development 2.0 no longer available for new purchases
May 2026	Australia release, Agile Development 2.0 disabled by default in all new instances
September 2026	End of Renewal for Agile Teams SKU
At your renewal	Agile Development 2.0 becomes custom code, your team is responsible for maintenance
August 2030	Full platform deprecation, Agile Development 2.0 (com.snc.sdlc.agile.2.0) fully removed

What Is CWM and Why Did ServiceNow Move Here?

Agile Development 2.0 was built to handle team-level agile execution, sprints, backlogs, stories, scrum tasks. It did that well in its context. What it did not do is handle the reality of how delivery teams actually work in most organisations: across multiple work types, pulling in incidents and problems alongside stories, connecting team-level work to programme-level visibility, and operating in environments where not every team runs pure Scrum.

CWM is built around a different model, a unified workspace where teams can manage work regardless of type, run kanban or scrum workflows, connect records from across the ServiceNow platform, and operate with more flexibility in how they structure their work hierarchy. It is work orchestration as a discipline, not just sprint tracking as a feature.

The Functional Differences: What Actually Changed

Feature Area	Agile Development 2.0	CWM
Sprint Board	Sprint planning board with native sprints	Board + Sprint Planning view (separate)
Backlog	Built-in backlog within the sprint board	Backlog section within Sprint Planning view
Work item hierarchy	Fixed: Products → Epics → Stories → Scrum Tasks	Custom, create your own hierarchy; no built-in Products, Releases, or Themes
Importing other work types	Unified Backlog, separate triage step to convert into stories	Connected Work, source records brought directly into board backlog, no triage step
Kanban tracking	Sprint tracking board	Kanban view within CWM
Epic backlog	Built-in epic backlog	Requires Enterprise Agile Planning (EAP) integration, not available in CWM alone
Sprint data history	Stored in Agile Development 2.0 sprint table	New sprint table in CWM, historical data does not automatically migrate

Important: Sprint, story points, and acceptance criteria managed within the CWM story panel are not written back to the classic story form. If you open a story via Detailed Form View, the Sprint field on the classic form will appear empty. This is expected behaviour in CWM and catches teams off guard during transition. Do not run CWM and Agile Development 2.0 simultaneously for the same stories.

The Key Conceptual Shifts to Understand

Work Item Hierarchy Is Now Flexible - Not Fixed

• Agile Development 2.0 gave you a predetermined hierarchy: Products, Epics, Stories, Scrum Tasks
• CWM removes that prescription, you define the work item types and hierarchy that suit your team's structure
• This is more powerful but requires more upfront design thinking, teams that just want to click and sprint may find the initial CWM setup less intuitive
• Spaces in CWM separate product areas; Goals connect work to business objectives, these replace the Product and Epic layers from Agile Development 2.0 at the conceptual level

Connected Work Replaces the Triage Board

• In Agile Development 2.0, pulling in incidents or defects meant a separate triage step that converted them into stories
• CWM's Connected Work feature brings records from any ServiceNow application directly into the Board backlog by defining filter conditions, no separate conversion step
• Teams can plan incidents, problems, and changes into sprints alongside stories from a single backlog view
• Status updates made on the board sync back to the source record, the data does not duplicate, it connects

Epic Management Requires EAP

• This is the gap most teams discover late: CWM does not have a built-in Epic backlog
• If your teams run scaled agile with Epics and need programme-level visibility, you need Enterprise Agile Planning (EAP) running alongside CWM
• Teams doing straightforward team-level Scrum can operate in CWM alone; teams doing scaled agile cannot

What CWM Adds That Agile Development 2.0 Did Not Have

The migration conversation often focuses on what is missing or different. It is worth being clear about what CWM actually adds.

Otto AI - Task Generation from Unstructured Content (Brazil Release)

• In the Brazil release (EA from September 24, 2026), CWM adds Otto-powered task generation, teams feed meeting notes, planning documents, or PDFs to Otto and it extracts and creates tasks automatically
• Child task generation is also available: any CWM task can be split into assignable sub-tasks with a single click; Otto generates the sub-task structure rather than requiring leads to draft each one
• Both features require CWM Advanced or CWM Professional Plus

These new Otto capabilities also show how AI is becoming part of everyday work management, alongside broader AI development services for enterprise automation. 

Cross-Platform Work Visibility

• Work from any ServiceNow application can be pulled into a CWM board, not just SDLC-specific records
• For teams supporting both product delivery and operational work, this creates genuine cross-functional visibility in one workspace

Multiple Workflow Models in One Space

• CWM supports Scrum, Kanban, and hybrid approaches within the same platform, teams do not have to choose a single methodology
• Sprint Planning view for teams running structured sprints; Kanban view for teams running continuous flow; both available without separate tool setups

What to Do Before You Migrate

The migration guide ServiceNow published covers eight phases, from understanding the conceptual changes through to day-to-day execution in CWM. Before starting any of those phases, there are a few things worth doing first.

Audit Your Current Agile Development 2.0 Usage

• Document which teams are using Agile Development 2.0 and in what capacity, sprint-based, kanban, scaled agile, mixed
• Identify integrations and automations that reference Agile Development 2.0 tables or fields. These dependencies may require ServiceNow integration services before migration. 
• Check your Epic usage, if your teams use Epics heavily, your EAP licensing conversation needs to happen before your CWM migration plan is finalised

Understand the Sprint History Situation

• Sprint historical data in Agile Development 2.0 sits in a different table from CWM's sprint table
• This data does not migrate automatically; decide upfront whether you need historical sprint data in CWM or whether it can be archived in the legacy table
• Metrics, velocity charts, and burn-down history built on Agile Development 2.0 data will not carry across without specific migration work

Check Your CWM Licensing

• CWM is a paid subscription; it has been since the Zurich release pricing update
• CWM Base, CWM Advanced, and CWM Professional Plus have different feature sets; the Brazil AI features (Otto task generation) require Advanced or Professional Plus
• Confirm your entitlements before building a migration plan that assumes features your license tier does not include

The Migration Is Eight Phases - Not One Event

ServiceNow's official migration guide structures the transition across eight phases: understanding the changes, setting up the CWM Space, creating the Sprint Board, connecting work items, recreating custom fields and columns, setting up sprint planning, establishing day-to-day Kanban execution, and addressing migration gaps and known limitations.

That structure matters. This is not a data migration with a cutover date. It is a workflow migration; teams need to learn a new interface, configure a new structure, and shift their daily habits before the old system goes away. Running it as a phased transition, with teams moved across gradually, is significantly less disruptive than a hard cutover approach.

The teams that handle this migration well treat it as a re-implementation of their agile workflow, not a like-for-like data move. CWM is different enough from Agile Development 2.0 that trying to recreate the old setup exactly in the new tool misses the point and produces a CWM environment that does not take advantage of what CWM actually does better.

Conclusion

Whether your renewal is six months away or two years away, the right time to start planning the CWM migration is before that pressure point arrives, not when the renewal conversation forces the issue. Dotsquares works with ServiceNow customers across the full migration lifecycle: from dependency auditing and licensing review through CWM configuration, agile team onboarding, and post-migration support. If you want to understand what this transition looks like for your specific instance and teams, our team can walk through it with you.