Moving to ServiceNow Project Portfolio Management: Migration Considerations

Migrating to ServiceNow Project Portfolio Management means moving project and demand data out of the systems that track work today. This page helps a reader plan that move: inventory the current systems, assess data quality, define prioritisation and weighting schemes, decide which system is the master for each data type, and sequence the first board cycle.

Inventory Current Project and Work Management Systems

Before migrating to Project Portfolio Management, audit all systems currently tracking projects and work: project management software (Microsoft Project, Smartsheet, Jira), spreadsheets tracking portfolio health, portfolio review meeting notes, demand request systems, or informal project tracking. Map what exists in each system: project metadata (name, status, business owner, completion date), costs and resources (budget, team allocations, skill requirements), dependencies between projects, and portfolio prioritisation criteria. This inventory reveals how fragmented current portfolio management is and what data must be consolidated into Project Portfolio Management.

Understand current portfolio governance: who makes project prioritisation decisions, how often does the portfolio get reviewed, what criteria guide investment decisions? If portfolio governance is informal or varies by business unit, Project Portfolio Management migration is an opportunity to standardise. Document existing governance so you can improve it intentionally during migration rather than accidentally losing important decision-making practices.

Assessing Existing Demand and Project Data Quality

Portfolio data quality affects Project Portfolio Management usefulness. If existing project records lack clear business justification, accurate cost estimates, or realistic resource requirements, Project Portfolio Management will inherit these gaps. Conduct a data audit: how many existing projects have defined owners, clear status updates, and current cost and resource information? How many projects are stalled or completed but never closed in tracking systems?

Categorise projects by maturity: initiated but not yet approved, approved and underway, completed, or abandoned. During migration, archived or abandoned projects can be marked closed in the legacy system before migration rather than cluttering Project Portfolio Management with stale records. This data cleanup improves the initial quality of your Project Portfolio Management database and prevents confusion about what is active.

Defining Portfolio Prioritisation and Weighting Schemes

Project Portfolio Management enables prioritisation, but requires clear criteria for ranking projects. Before migration, define what drives prioritisation in your organisation: strategic alignment, expected financial return, risk mitigation, compliance requirements, operational necessity, or a combination. Establish a weighting or scoring methodology so projects can be compared fairly. If business units use different criteria, decide whether Project Portfolio Management will enforce unified criteria (simpler, but may create friction) or allow business-unit-specific prioritisation rules (more flexible, but adds complexity).

Document the prioritisation scheme so it can be configured into Project Portfolio Management workflows. Include decision criteria, scoring or weighting methodology, approval authority for priority decisions, and frequency of portfolio reviews. This discipline prevents prioritisation from becoming a political process where loudest voices win rather than strategic decisions driving investment.

Integration with Resource Management and Demand Tracking

Project Portfolio Management works best when integrated with Resource Management and demand fulfillment workflows. Portfolio decisions must account for resource constraints: you can’t approve five projects if you have resources for two. Demand workflows that create work items (change requests, project initiations, improvements) should feed into Project Portfolio Management so all work is visible in one portfolio. Plan these integrations before migration so new project creation workflows route through Project Portfolio Management, not around it.

Clarify how projects relate to other work in ServiceNow. If your service desk creates change requests, should high-priority changes feed into Project Portfolio Management? Should operational requests compete for the same resources as strategic projects? These are business decisions that should be made before implementation, not discovered during configuration.

Data Migration Strategy and Legacy Project Handling

Decide how to handle projects currently underway in legacy systems. Full migration brings all existing projects into Project Portfolio Management; phased migration starts with future projects only, allowing current projects to complete in the legacy system. Hybrid migration brings active projects into Project Portfolio Management but archives completed projects from the legacy system separately. Each approach has trade-offs: full migration requires more data remediation but provides complete portfolio visibility; phased migration is simpler but creates a transition period where two systems operate in parallel.

Plan how you will migrate project hierarchies and relationships. Legacy systems may represent project dependencies or parent-child relationships differently than Project Portfolio Management tables expect. Mapping this structure requires understanding both the legacy model and Project Portfolio Management’s project hierarchy to ensure relationships translate correctly and maintain meaning after migration.

Portfolio Review Process and Stakeholder Communication

Establish portfolio review cycles before go-live: how frequently does leadership review the portfolio, which stakeholders participate, what decisions are made, and how are outcomes communicated? Project Portfolio Management provides visibility needed for these reviews, but the review process itself is organisational, not technical. Plan portfolio review meeting cadence, attendees, escalation procedures, and how Project Portfolio Management will provide needed dashboards and reports for these meetings.

Communicate to project managers and business owners what will change. Project Portfolio Management introduces new workflows for project proposal and approval. Existing project managers may need to migrate their project data into the system. Business owners need to understand how portfolios will be prioritised and what information Project Portfolio Management requires from them. Change communication and training are often underestimated; allocate sufficient time before go-live for stakeholder preparation.

Settling which system is the master for each kind of portfolio data

A portfolio move often breaks down over a question nobody asked out loud: after go-live, which system is the source of truth for a given number? Project scope and status may belong with the delivery team’s own tool, budget actuals with finance, and allocated hours with resource planning. If the portfolio register holds a copy of a figure that is also edited elsewhere, the two will drift, and the board will decide on whichever copy it opened last. Settle the master for each kind of data before migration begins, then make the other systems read from the master rather than hold their own edited copy. Where the master cannot be agreed, the portfolio should show the figure with its source named beside it, so that the disagreement is visible rather than hidden.

Sequencing the move so the first board cycle is credible

1. Confirm the master for every field in the table above, and record the answer where the portfolio team can see it.
2. Migrate one portfolio, with its full set of projects and their dependencies, as a pilot rather than moving every portfolio at once.
3. Reconcile the pilot’s budget totals against the finance system, and resolve every difference before the next step.
4. Run one full board cycle on the pilot, using the new register as the only source for the papers.
5. Extend the migration to the remaining portfolios only after the pilot’s decisions and figures have been accepted by the people who will be held to them.

Carrying hierarchies and identifiers across without breaking them

Legacy tools often store a parent program as a loose label, and the child projects carry the label as free text. Converting that to a true hierarchy means choosing one parent per project and dropping the rest, which forces a conversation about shared projects that the old system allowed to avoid. Keep a crosswalk table that maps each legacy identifier to its new one, and keep it for as long as finance or audit might query a historic figure. A migration that cannot trace a project back to its original code can generate disputes that no amount of cleansing will resolve.

Can we keep the old register running in read-only mode for a period?

Yes, and it is often the safest choice for the first cycle, provided the read-only copy is labeled so that nobody updates it by habit. A frozen copy used only for lookup prevents the reconciliation work from being lost when the old tool is retired.

Should completed projects come across at all?

Only the ones that are still referenced by live budgets, benefits or contracts. The rest can be summarized in a single record per program, which keeps the register focused on the work the board still has to decide on.

Who should sign off that the migrated portfolio is correct?

The sponsors of the largest portfolios should review their own projects, and finance should confirm the totals. A single sign-off by the migration team is not enough, because the people who will rely on the register are the ones who notice missing context first.

What if a project’s dependency points to a project that was never migrated?

Record the dependency as an external item with a note explaining its origin, rather than dropping it. Silent removal of dependencies is a common reason a delay in one area fails to reach the people it affects.