Migrating from Resource Plans to Resource Assignments - Support and Troubleshooting

Migrating from Resource Plans to Resource Assignments .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Migrating from Resource Plans to Resource Assignments Resource Assignments represent the next generation of resource management in ServiceNow SPM, replacing Resource Plans with a more streamlined, workspace-native experience. This article helps you plan and execute a successful migration by covering change readiness, assessing your data landscape, and choosing the right migration strategy.

Change and Communication A successful migration starts well before any data moves. Your teams need to understand what is changing, why it matters, and how their day-to-day workflows will be affected. Invest in communication and training early to avoid disruption.

#

Action

Why It Matters

1

Understand the new process and functionality

Resource Assignments introduce a different workflow, workspace layout, and approval model compared to Resource Plans.

2

Understand the new financials

Review how labor cost plans are generated with Resource Assignments - cost plans are now attribute-based and driven by planning attributes like Employee Type, Expense Type, and Role.

3

Communicate in advance

Give stakeholders time to prepare. Surprise changes to resource workflows cause resistance and adoption issues.

4

Train on new process and solution

Both Resource Managers and Project Managers need hands-on training with the Resource Management Workspace before go-live.

5

Plan for the migration

Define timelines, ownership, rollback criteria, and success metrics before starting.

6

Test thoroughly in a non-prod environment

Validate all use cases including approvals, heatmap accuracy, and financial calculations before production migration.

7

Test migration strategy and measure duration

Run a dry migration to estimate time, identify issues, and build confidence in the process.

Assess Your Maturity and Data Landscape Before choosing a migration strategy, assess three factors that directly impact complexity and risk.

Factor

What to Assess

Impact on Migration

Instance Maturity

How long have you used Resource Plans? What is your degree of customization and process maturity?

Heavy customizations increase migration complexity and require more testing.

Data Volume

Number of active projects and demands, resource plans, and resources in your instance.

High volume environments should migrate in phases to reduce risk.

Version & Licensing

Your instance version (e.g., Washington, Yokohama) and entitlement for SPM Workspaces.

Resource Assignments require the latest Next Experience components.

Migration Strategies Choose the strategy that best fits your organization's size, risk tolerance, and readiness. There is no one-size-fits-all approach.

1. Big Bang Best for: Organizations with limited or no active resource plans and minimal customizations.

Approach: Migrate all existing resource plans at once and switch all projects and demands to resource assignments in a single cutover. This simplifies governance by eliminating a period where both systems run in parallel, but it requires thorough pre-validation and testing to avoid disruption.

Key consideration: This strategy has the least operational overhead but the highest single-point risk. Ensure your non-production testing is comprehensive before committing.

2. Phased Migration Best for: Large enterprise customers with many active, ongoing projects across multiple business units.

Approach: Migrate in phases by business unit, department, or portfolio. Each phase follows the full migration lifecycle: plan, test, migrate, validate. Learnings from each phase are applied to the next, reducing risk progressively.

Key consideration: During migration, some teams will be on Resource Plans while others are on Resource Assignments. Plan for this co-existence period and ensure cross-team visibility is maintained.

3. Pilot then Scale Best for: Organizations that need to test process impact or train teams before committing to a broader rollout.

Approach: Start with a single department, business unit, or portfolio. Use this pilot group to validate the end-to-end process, train users, gather feedback, and refine your approach. Once the pilot group signs off, scale to the rest of the organization using a phased migration.

Key consideration: Choose a pilot group that is representative of your broader organization but also willing to work through early issues. Avoid picking your most complex or your simplest team—aim for the middle.

Strategy Comparison

Big Bang

Phased Migration

Pilot then Scale

Risk Level

Higher (single cutover)

Moderate (spread across phases)

Lower (validated before scaling)

Duration

Shortest

Longer

Longest

Co-existence

None (clean switch)

Yes (during transition)

Yes (during pilot + rollout)

Testing Need

High (must get it right first time)

Moderate (learn between phases)

Moderate (pilot catches issues)

Best For

Small/simple instances

Large enterprises

Risk-averse organizations

Choosing the Right Strategy

Ask yourself these questions to guide your decision:

· How many active resource plans do you have? Fewer than 50 with minimal customization points toward Big Bang. Hundreds or more points toward Phased or Pilot.

· How heavily customized is your instance? Significant customizations (business rules, UI policies, integrations) require more testing and favor a Pilot approach.

· How comfortable are your teams with change? If teams need hands-on experience before trusting a new process, start with a Pilot.

· What is the cost of getting it wrong? High-stakes environments (regulated industries, mission-critical project portfolios) should avoid Big Bang and opt for Pilot then Scale.