Moving from Microsoft PWA to SPM - Do you have any pro tips or lessons learned that might help?

[jhain92]

Hi, we are active in the process of determining a migration strategy to go from Microsoft Project Web Access (PWA) to SPM.  While we have had SNOW for a while now, we have not really had the opportunity to manage projects end-to-end in SPM.  Are there any pro tips or lessons learned that might help specific to a PWA > SPM migration?

Thanks

[Dhiren Aghera]

@jhain92  This is going to be fun ride and yes migrations need deep planning. We went through the same migration few years back and the decision was right. As you start your journey few things to keep in mind na d hope that helps - 

1. Both system are different so be ready for some resilience to this change
2. All your Project Management prosses are well defined in ServiceNow
3. Be ready with process maps for each of the project management processes
4. Do not over complicate and start with OOTB first
5. Try to migrate as much less data as much possible or if possible close all projects in Microsoft PWA and start up fresh in ServiceNow
6. Understanding the OOTB process flows in ServiceNow will be really helpful
7. Also you can go through some available success packs available from ServiceNow

[eriksandber]

I agree with the recommendation to minimize legacy data and stay close to the ServiceNow operating model. I would add one architectural principle that I have found important in transformations like this:
Do not treat PWA to SPM primarily as a project migration. Treat it as a portfolio operating model transition.
Moving schedules is only one workstream. The more consequential decision is whether the organization wants to reproduce how it managed projects in PWA or use ServiceNow SPM to improve how strategy, demand, investment, prioritization, execution, capacity, financials, and outcomes are governed.
I would structure the transition around:
Decide → Design → Segment → Migrate → Govern → Measure
1. DECIDE: Define the decisions SPM must improve
Before mapping fields, determine what leadership expects SPM to help decide.
Which work should we fund?
Which work should we defer or stop?
How does proposed work align to strategy?
Where are the capacity constraints?
What financial commitment are we making?
What benefits were committed, and are they being realized?
Which investments should be reprioritized when conditions change?
This matters because the objective should not be to recreate PWA inside ServiceNow.
The objective should be to establish a stronger decision architecture from strategy through execution and realized outcomes.
2. DESIGN: Define the target SPM operating and information model before mapping the legacy system
I would establish the target relationships across Strategic Planning, Portfolio Planning, Demand Management, Project Management, funding and financial planning, resource capacity, risks, dependencies, and benefits before designing the migration.
Then map PWA into that model.
Reversing that sequence creates a common problem: hundreds of migration decisions get made based on what existed in the legacy system before the enterprise has decided what information should mean in the future state.
The target model should drive the migration.
The legacy data model should not design the target SPM architecture by accident.
3. SEGMENT: Do not migrate every project or every data element the same way
I would segment both the portfolio and the data.
A project that is nearly complete should not automatically receive the same migration treatment as a multiyear strategic initiative with significant remaining investment.
Projects can generally be evaluated for completion in PWA, transition into SPM, rebaseline in SPM, or historical retention.
I would apply a similar test to the data:
Operationally required: needed to continue active execution.
Decision relevant: needed for portfolio, funding, capacity, risk, financial, or benefits decisions.
Historical: required for reference, audit, or retention but not necessarily as active production data.
That changes the migration question from:
“How much can we move?”
to:
“What information must participate in the future operating model?”
That is a much more useful boundary.
4. MIGRATE: Treat Microsoft Project import as a mechanism, not the migration strategy
ServiceNow can import Microsoft Project information into Project Management, but the existence of that capability should not determine the architecture.
Field mappings, resource identities, schedule constraints, dependencies, project structures, financial information, and related records still need deliberate reconciliation.
I would also avoid an extended period where PWA and SPM are both treated as authoritative for the same active work.
Establish explicit cutover rules:
What becomes authoritative in ServiceNow?
When does that authority transfer?
What remains read only in PWA?
How are exceptions handled?
Dual authority is where reconciliation problems, reporting conflicts, and governance ambiguity begin.
5. GOVERN: Define decision rights before configuring workflow
This is where I would spend substantial design attention.
Who owns demand intake?
Who determines strategic alignment?
Who can move work from demand into execution?
Who owns portfolio prioritization?
Who can commit funding?
Who owns resource capacity?
Who owns financial assumptions?
Who owns benefit realization?
Who has authority to stop or redirect an investment?
ServiceNow can operationalize those decisions extremely well once they are defined.
It cannot compensate for decision rights the organization has never resolved.
That distinction becomes increasingly important as SPM moves beyond project administration into enterprise investment governance.
6. MEASURE: Design reporting backward from executive decisions
I would not begin by asking which dashboards can be recreated from PWA.
I would begin with the decisions executives, portfolio owners, and delivery leaders need to make and determine what information SPM must govern to support them.
For example:
Are investments aligned to strategy?
Are we funding the highest priority work?
Are resource constraints making the approved portfolio unrealistic?
Are actual costs diverging from the investment case?
Are committed benefits being realized?
What changes when funding, capacity, priority, or business conditions change?
Portfolio Planning and the broader SPM model can support prioritization, scenario analysis, financial planning, demand and project decisions, and alignment of work to enterprise objectives.
That is substantially more valuable than reproducing the legacy project reporting model.
My guiding principle would therefore be:
Migrate what is necessary to continue the work.
Redesign what is necessary to improve the decisions.
Archive what no longer needs to participate in the operating model.
If the organization finishes the transition managing essentially the same projects in essentially the same way, only in ServiceNow, it completed a system migration.
If it finishes with stronger traceability from strategy and demand through investment, prioritization, execution, capacity, financial performance, and realized outcomes, it implemented SPM.
That is the distinction I would design the migration around.