Moving to ServiceNow Resource Management: Migration Considerations

Moving to ServiceNow Resource Management means replacing the spreadsheets, HR records and project timesheets that currently decide who works where. The page covers the data and decisions to settle first, including the skills model, the cutover date and the coexistence pattern, so a go or no-go decision can be made on evidence.

Inventorying Existing Resource Data and Tracking Systems

Before migrating to Resource Management, audit how your organisation currently tracks resources. Many organisations manage resources in spreadsheets, project management tools, or HR systems with incomplete visibility. Inventory all locations where resource information lives: project timesheets, resource tracking spreadsheets per business unit, HR systems tracking headcount and skills, or dedicated resource management tools. Map what data is in each system: who are your resources (people), what skills do they have, which projects are they allocated to, how much capacity does each person have, and what is their utilisation rate?

Understand your resource pools. Are resources managed centrally by a shared services organisation, or does each business unit own its own resources? Are resources shared across projects (one person works on multiple projects) or dedicated (one person per project)? This organisational structure affects how Resource Management should be configured. Some organisations have resource managers who allocate capacity; others have project managers requesting resources. Understanding current governance helps you define roles and workflows in Resource Management.

Defining Skills Taxonomy and Capacity Models

Resource Management depends on a clear skills taxonomy. Before migration, decide what skills you will track and how finely you will define them. Broad skills (Java developer) are simpler but less useful for precise resource matching. Fine-grained skills (Java 11 and Spring Boot developer, 5+ years experience) are more accurate but require discipline to maintain. Define skill proficiency levels (junior, mid-level, senior) if relevant. Map existing skills data from HR systems or spreadsheets to this taxonomy, recognising that legacy skill information may be incomplete or outdated.

Establish capacity models: how do you measure resource availability? Standard approaches include full-time equivalents (FTE), hours per week, or utilisation percentage. If your organisation uses different capacity models in different business units, decide whether Resource Management will enforce one standard or support multiple models. Also define how Resource Management treats administrative, leave, and training time: should a resource’s calendar reserve time for these activities, or should Resource Management assume complete or full availability for project work?

Integrating with Project Portfolio and Demand Systems

Resource Management is most valuable when integrated with work demand systems. If projects request resources through Resource Management, or if service requests automatically trigger resource demands, Resource Management can show resource conflicts before they occur. Before migration, define how demand flows into Resource Management: do project managers submit resource requests, or does work automatically create demand based on project scope? Does Resource Management feed into project planning, or are resources allocated after projects are approved?

Plan how you will handle multiple concurrent demand sources. If both Project Portfolio Management and the service desk create resource requests, Resource Management must visualise both to show true resource constraints. Resource conflict resolution must be clear: when demand exceeds supply, who decides which work gets resources? Is it based on priority, first-come-first-served, or management decision? Configuring Resource Management to support your conflict resolution process prevents it from becoming an advisory system that managers ignore.

Resource Allocation Methodology and Timescale Planning

Organisations allocate resources across different timescales. Some organisations do monthly allocation cycles (staff assigned for the coming month), others quarterly, and some continuously adjust. Decide what allocation cycles Resource Management will enforce. Shorter cycles (weekly or daily) give more flexibility but require frequent reallocation decisions. Longer cycles (quarterly) are more stable but less responsive to unexpected changes. Choose a cycle that matches how your organisation actually operates, not how you hope it operates.

Plan for forecast horizons. How far in advance do you need to know resource availability? Projects planned far ahead need resource forecasting; support work planned at short notice needs near-term scheduling. Resource Management should support both, but they use different configuration approaches. Define what forecast horizon matters most for your business and configure Resource Management to highlight conflicts at that horizon.

Data Migration and Resource Onboarding

Migrating existing resource allocation data is often complex. If projects are tracked in multiple systems with different resource names and allocations, consolidation and validation is necessary before import. Decide which data to migrate: current allocations only, or historical allocation data as well? Historical data shows past utilisation patterns to the people planning but adds migration complexity. Start with current allocations and add historical context after stabilising the system.

Plan how new resources will be added to Resource Management. If your organisation hires regularly, Resource Management should integrate with HR onboarding so new hires are automatically registered. If integration is not feasible, establish a manual process for registering new resources and their initial skill profile. Delayed resource registration creates gaps where work is assigned before people appear in Resource Management.

Stakeholder Training and Adoption Planning

Resource Management changes how resource managers, project managers, and resource contributors interact. Resource managers gain visibility into utilisation and can spot overallocation before it causes problems. Project managers must request resources and accept allocation decisions from Resource Management rather than unilaterally assigning people. Resource contributors (individual contributors and teams) see their allocation plan and can report actual work versus planned. This transparency is valuable but can feel intrusive initially. Training should explain how Resource Management helps each role and what new responsibilities they have.

The Cutover Question Comes Before the Data Question

Teams planning a move into resource management usually spend their energy on how to load the data, and only later ask when the old method stops. That order invites a long period in which both systems are authoritative for different people, and the planning picture is wrong in both. Settle the cutover decision first: the date on which allocations are confirmed only in the new system, the last date on which the old method is still accepted, and the person who can authorize a return to the old method if the new one fails. Those three decisions shape every data task that follows.

Choosing a Coexistence Pattern

Integration choices affect the pattern. The integration patterns for resource management guide covers how supply and demand feeds connect, so read it before choosing one.

A Go or No-Go Procedure for the Move

1. Confirm that every active person is registered once, with a single identifier that the HR and platform records share.
2. Reconcile the current allocation totals for each team against the old system, and record any difference with its cause.
3. Run one full allocation cycle in the new system with real open requests, and have the resource managers sign off the output.
4. Test the return path: switch a non-production copy back to the old method and confirm the allocations can be recovered from it.
5. Name the owner who makes the cutover decision, and record the evidence they reviewed before deciding.

Keep the acceptance evidence for each step with the step itself, using the resource management testing checklist as the scenario list.

What Usually Goes Wrong in the Move

A frequent error is moving allocations without moving the reasons behind them. A person booked at half time on a product may have that booking because of a commitment to train a colleague, and the reason disappears in the transfer. Ask the resource managers to annotate the top conflicts before migration. Those annotations are the context the new system will need to make sense of an apparent overbooking.

The second failure is leaving the old spreadsheet open for quick edits. Once a resource manager has an alternative that looks easier, the planning work splits silently between two places. Make the old file read-only on the cutover date and say so in the announcement.

The third is underestimating the change in conversations. In the old method, a manager could move someone in a meeting and the record followed later. In the new method, the record has to change first. That shift takes a few cycles to settle, and it is easier to plan for than to repair after complaints start.

Signs the Move Has Settled

• Resource managers open the platform before the meeting rather than an extract.
• No one maintains a parallel allocation file.
• Conflict reports are discussed as a normal part of the agenda, not as a special exercise.
• The old archive is consulted for history only.

When Migration Should Wait

Do not migrate while the resource model is still changing. If the organization is about to restructure teams, change its skill categories or move a major group into a new business unit, the migrated data will be out of date on arrival. Stabilize the model first, then migrate. A short delay to finish the restructure is often cheaper than a second migration. A pause like this fits before the first migration wave, not during it. Plan the timeline against the resource management implementation roadmap.

Questions About Moving Resource Data

Should historical allocations be migrated at all?

Only if someone will analyze them. Most planning decisions use current and near-future allocations. Keep history in the archive, and migrate it into the platform later if a specific analysis needs it.

How should non-employee workers be recorded?

Give them a record with a source flag and an end date that follows the contract. Their allocations then appear in the same views as employees without being mistaken for permanent headcount.

Can we move one team first and keep the rest on the old method?

Yes, if shared specialists are either moved with the team or kept in one place, so that no one is planned in two systems at once. Pick a team whose work rarely depends on people outside it.

Who should sign off on the cutover?

The accountable owner for resource allocation, with the resource managers confirming the reconciliation. Platform staff should confirm that the return path has been tested, but they should not make the business decision.

Next Step

A move whose cutover decision is still open benefits from an early look at the coexistence pattern and the rollback path. The guide to ServiceNow implementation pitfalls covers common implementation challenges.

ServiceNow Resource Management migration: table names and values to map first

Moving to ServiceNow Resource Management means mapping people, skills and commitments onto platform records. The deciding fact is that commitments and people live in different tables: resource_plan and resource_allocation typically hold the commitments, while sys_user and sys_user_has_skill hold who can be committed, so each source column needs a destination before any load.

These are common out-of-box names. Check them on your own instance and release, because labels, plugins and defaults change between releases.

Example (hypothetical): a planning office keeps one spreadsheet per business unit, each listing people by first name, a free-text skill and a weekly hours column. Before loading anything, the migration lead builds a mapping sheet that gives every column a destination table, flags the free-text skills that need a cmn_skill match, and lists people who appear in two spreadsheets so each is registered once in sys_user.

The Resource Management guides describe the module, the strategic portfolio management section shows where it sits in the wider suite, and the project portfolio management governance model is the place to settle who approves the work that creates demand.

Which tables do skills load into?

Skill definitions typically belong in cmn_skill and the link between a person and a skill in sys_user_has_skill. Load the definitions first and the person links second, because a link row needs an existing skill and an existing user to point at. Check both tables on your release before writing import maps.

What should be loaded before any allocation rows?

People first, then groups and group membership, then skills, then the projects or demand that allocations refer to. Allocation rows reference those records, so loading allocations before those records exist leaves broken references. Run a small test load and read it back before the full import.

How can a duplicate person be caught before the load?

Pick one identifier that exists in both the spreadsheet and the user table, such as an employee number held in the user record, and sort the source by it. Any identifier that appears twice is a duplicate to resolve before import, not after it.