Resource Migration: Capacity Planning from Microsoft Project

Project Server's value, for the PMOs that run it well, is rarely the project plans themselves. It was the operational layer underneath: a single enterprise resource pool that every project drew from, costed timesheets that fed billing and revenue recognition, calendar exceptions that propagated automatically, and cross-project views that let resource managers make weekly staffing decisions on real allocation data. That operational layer is what's at risk. The plans migrate. The operational layer often does not.

Three failure modes show up consistently when PMOs underestimate this:

• The "we'll re-add resources later" trap. A team migrates the project plans cleanly, then plans to re-add the resource pool the following sprint. By the time they get to it, individual project owners have already added duplicate resources to their projects, and the resource manager has lost the single-source-of-truth contract that made cross-project capacity views work.
• The "cost rates aren't critical for go-live" trap. Standard rates are deferred to a phase 2 cleanup. Two months later, Finance discovers their monthly close requires costed timesheet data that no longer exists in the new platform because rates weren't loaded at timesheet-entry time. The data can't be retroactively reconstructed; revenue recognition stalls.
• The "Planner Premium will work" trap. A PMO assumes Microsoft's cloud product covers the same use cases. It doesn't, for resource modelling. Planner Premium ships no enterprise resource pool, no costed timesheets, no cross-project resource view. Discovery after migration is too late.

The structural reason all three happen: the resource model is the part of Project Server that's least visible in casual product demos and least covered in vendor comparison checklists. Project plans, Gantts, and dashboards demo well. Enterprise resource pools demo poorly. So buyers underweight resource-model coverage in platform selection, then discover the gap in production. This guide is structured to surface the model first, before the migration tactics, on the assumption that the biggest decision is which target platform you pick.

Before deciding what to migrate, take inventory of what you have. Project Server's resource model has six layers, each of which migrates differently:

Not every PMO uses every layer. The right inventory question is "which of these does our team actually rely on for decisions?" If you don't run costed timesheets, the rate-table layer is decorative; you can drop it without consequence. If you don't use generics for demand modelling, you can collapse them. If you do use generics for demand modelling, that capability is non-negotiable in the target platform.

Run the inventory before you compare platforms. The outcome of the inventory is a list of must-have capabilities for the target platform, and that list shapes the rest of the migration. The next section assumes you have that list in hand.

Platform comparisons narrow when you filter for resource-model coverage. Here's the honest picture, organised by the six layers above. Pass / partial / no for each:

Microsoft's cloud product (Planner Premium / Project for the Web, same product under different SKU labels) drops most of the resource-model surface. That's a deliberate product positioning choice, it's a team-task tool with project veneer, not a PMO platform. PMOs using Project Server's resource model in earnest cannot replace it with Planner Premium without losing significant capability.

Smartsheet's Resource Management module and Workfront both keep the enterprise pool concept. They differ on the details: Smartsheet RM is a separate SKU and adds notable per-seat cost; Workfront's enterprise pool is strong but the per-seat pricing is the highest of the four. Onplana has no separate resource pool: each person is one member of the organization, and its resource model is that person's weekly capacity across every project (on the Professional plan and up), rate cards at three levels (person, role, organization default) and working calendars with named exceptions, with no paid add-on. It has no generic resources, no per-person calendars and no formal RBS. Per-seat pricing starts at $12/seat/month (Professional). The honest comparison vs Planner Premium is on our Planner comparison page.

One more dimension that's hard to put in a table: the cross-project capacity view's quality varies a lot between platforms even when the basic capability is present. Some show only direct task assignments; some include sub-project rollups; some include placeholder generic allocation. If your resource manager makes weekly staffing decisions from this view, run a side-by-side comparison during evaluation using the top 25 resources by allocated hours.

Before exporting anything, build a complete inventory of the resource model. This is a different inventory than a project-list inventory: that one catalogues projects; this one catalogues the resource layer underneath them. The deliverable is a Resource Migration Readiness Report that lists every resource artifact, where it currently lives, where it's going, and who owns the move.

1. Resource list with attributes. Export the full enterprise resource pool with name, type (named/generic/cost), email (for named), max units, standard rate, role/title, RBS path. The OData /Resources endpoint is the canonical source; the Reporting Database has more derived fields but only on Project Server on-prem.
2. Cost rate tables. Microsoft Project supports up to 5 cost rates per resource (Rate A through Rate E) with effective-date ranges. Export every rate tier, every effective-date row. If your PMO uses only Rate A you can ignore B–E, but verify that's actually the case before assuming.
3. Calendar exceptions. For each resource, export the calendar exception list with exception name, date range, and working-time override. If your target platform doesn't preserve named exceptions, capture the names to a companion CSV so the rationale ("Conference week", "Holiday closure") survives.
4. RBS hierarchy. Export the Resource Breakdown Structure: every node, parent-child links, and the resources mapped to each node. The hierarchy is what enables resource managers to filter capacity views by their reporting structure.
5. Active assignments. Snapshot every active task assignment across every active project: which resource, which project, which task, allocated hours, actual hours, scheduled start/finish. This is the validation baseline; you'll compare allocation in the source vs target post-migration.
6. Custom resource fields. If your PMO defined Enterprise Custom Fields on resources (security clearance level, billable flag, contract type), export those alongside the resource list. Some target platforms will model these as built-in fields, others as custom fields, others not at all, drives the field mapping decision later.

The completed Readiness Report is what the rest of the migration runs against. To spot-check the export quality before committing, run a sample resource pool through the Migration Preview tool: upload a representative resource-pool slice and see exactly which fields, rates, and exceptions transfer cleanly.

Five phases, each with a deliverable and a go/no-go gate. Total elapsed time typically 3–5 weeks for a 100–250 resource pool, longer if you have heavily customised cost-rate tables or a large RBS.

Phase 1: Inventory + decisions (1 week)

Complete the pre-migration inventory above, then make the platform decision based on which resource-model layers are non-negotiable for your team. Document the decision with rationale; this is the section future-you will re-read when somebody asks why the chosen platform doesn't support feature X.

• Run the inventory against the live tenant
• Score each target platform against your must-have layer list
• Pick the target; document the decision rationale
• Get sign-off from PMO leadership on the platform choice

Gate: Resource Migration Readiness Report signed; target platform selected.

Phase 2: Export the pool (2–3 days)

Export from Project Server while it is still running, then check the export holds each layer below. Don't rely on .mpp file exports for the resource pool, those carry only project-local resource assignments, not the enterprise pool with its rates, calendars, and RBS.

• The resource list, from /Resources
• Calendar exceptions, from /Resources/Calendars
• Cost-rate tables (or the Reporting DB, on-prem)
• The RBS, from the SOAP API endpoints, which have no OData equivalent
• Active assignments, from /Assignments
• Counts that match the Readiness Report

Gate: Export count matches Readiness Report count for every layer.

Phase 3: Re-model in target (3–7 days)

Import the pool into the target platform, then handle the layer-by-layer translation gaps the platform comparison surfaced. Generics that don't translate get re-modelled as named placeholders. Calendar exception names that don't translate get archived. Custom resource fields get mapped to either built-in fields or custom field definitions in the target.

• Import the resource list (target's bulk-import or API)
• Re-create the RBS hierarchy and re-map resources to nodes
• Load standard rates and cost-rate tables before loading any assignment data
• Apply calendar exceptions per resource
• Translate generic resources per the platform's model
• Map custom resource fields

Gate: Resource pool count, RBS hierarchy, and rate-table count all match source.

Phase 4: Assign + validate (1 week)

Migrate task assignments project-by-project, in waves grouped by owner team. After each wave, the receiving team validates allocation in target vs source for their projects within 48 hours. Don't roll forward until the wave validates clean; chasing accumulated allocation drift across many projects is much harder than fixing it project-by-project.

• Migrate assignments in waves of 10–25 projects
• Per-resource, per-project allocation diff: source vs target
• Investigate any variance > 5%
• Reconcile costed-timesheet calculations on a sample of past timesheets

Gate: Per-resource allocation diff < 5% across all projects.

Phase 5: Capacity views + reconciliation (1 week)

Recreate the capacity views resource managers actually use, then run them in parallel with Project Server for at least 5 working days. Daily diff reports highlight any place the new platform's capacity calculation differs from the old platform's. Investigate every diff. Document any genuine differences as known limitations.

• Re-build the top 5 capacity views in the target
• Run daily diff reports for top 25 resources by allocated hours
• Investigate variance > 5%; document genuine platform differences
• Train resource managers on the new capacity-view UI
• Cut over: target becomes source of truth, Project Server read-only

Gate: 5 consecutive working days of clean daily diff reports; resource managers signed off on the new capacity-view UI.

The five resource-model failure modes that surface most often, with the prevention for each:

The pattern across all five: each one is a "we'll figure it out later" decision that's cheap at the moment of decision and expensive in production. The reconciliation work is one of the costs most often underestimated in initial budgets; on the migration cost calculator it sits under parallel operation.

The validation phase has three checks, each producing an evidence artifact. File them with the Resource Migration Readiness Report; together they're the audit trail of the migration.

1. Per-resource allocation reconciliation. For the top 25 resources by allocated hours over the next 90 days, compare allocation in source vs target. Tolerance: ±5%. Larger variance means either the assignment migration was lossy or the target's capacity calculation differs structurally from Project Server's. Both need investigation. Evidence: a per-resource diff report.
2. Costed timesheet sample reconciliation. Pick the most recent 10 closed timesheets across 5 different resources. Re-run the cost calculation in the target against the same time entries. Tolerance: ±1% (this is dollars; the tolerance is tighter than allocation diff). Variance > 1% indicates a rate mismatch, a calendar exception loss, or both. Evidence: side-by-side cost calculations.
3. Cross-project capacity view parity. Reproduce the top 3 capacity views resource managers use most often. Side-by-side compare against the last Project Server run for the same time window. Differences in how the two views categorise allocation (direct vs sub-project, named vs generic) are expected. Document them as known platform differences in the post-migration runbook. Evidence: side-by-side screenshots with documented diff.

The validation phase output is a Migration Outcome Report covering what migrated, what didn't, and what's open. Pair it with the Readiness Report from Phase 1, the two together document the full audit trail.

The PMO owns the migration runbook, but the resource model has consequences finance teams discover after cutover unless someone surfaces them up front. Three patterns come up in every migration that involves costed resources, and each one bites differently than PMO-side issues do.

Three rate concepts that get conflated

Project Server tracks three different per-resource rates that sound similar and are NOT interchangeable: standard rate (the cost of an internal hour for allocation modelling, often fully-loaded labour cost), cost rate (the rate used to compute a timesheet's accounting cost, sometimes broken into rate tables A through E for different activity types), and bill rate (the rate charged to a client for billable hours on engagements). Some PMOs use one rate across all three concepts; some use distinct rates per concept; some use rate-table tiers within concepts.

Before exporting, ask finance which rate concepts they actually use, which rate-table tiers map to which activities, and which target-platform fields each rate populates. The export is one row per rate per resource; the import is a mapping decision that determines whether next quarter's revenue-recognition reports reconcile. A common and recoverable mistake is loading bill rates into the cost-rate field. Costed timesheets then compute against the bill rate, P&L reports show inflated costs, the fix is a re-export and re-load. A worse and harder-to-recover mistake is loading cost rates into the bill-rate field. Invoices generated against the wrong rate need to be reissued and the customer-facing remediation conversation is not free.

Capitalisation rules don't auto-move

PMOs in regulated or capex-heavy organisations often have labour-capex policies that say "engineering hours on capitalisable projects roll up to a balance-sheet asset rather than expense." In Project Server these rules typically live as views or reports built on top of the OData feed, sometimes with a per-project flag and a per-task flag. None of that infrastructure migrates automatically. The flags export (custom field values), the views and reports do not. Finance has to rebuild the capitalisation reporting on the new platform from scratch, against the same flag-bearing data.

The risk is a quiet quarter where capitalisation reporting wasn't rebuilt, hours that should have capitalised were expensed instead, and the period closes with the wrong numbers. Material errors here are a control finding. Have finance scope the capitalisation rebuild as a parallel workstream to the migration, not a follow-up, and gate cutover on at least one closed period of side-by-side capitalisation reporting that reconciles.

Billable utilization reporting needs explicit setup

Professional services PMOs live and die on billable utilization (billable hours divided by paid hours, per resource and rolled up). Project Server produces this from the combination of timesheet data plus a "billable" flag at the assignment or task level. The flag exports cleanly; the report does not. As the platform-comparison matrix above shows, target-platform support for native billable utilization reporting varies. Onplana, Smartsheet RM, and Workfront all ship the report as a first-class artefact; Microsoft's Planner Premium does not have a billable concept at all.

For PMOs migrating to a platform that does support billable utilization, gate cutover on producing a side-by-side report for the most recent 4 weeks and reconciling within ±2%. Any larger variance points at a rate-mapping mistake, a missing billable flag, or an assignment that didn't migrate. For PMOs whose target platform does not support billable utilization natively, plan to feed the OData snapshot into a downstream BI tool (Power BI, Looker, Sigma) and rebuild the report there. Either way, finance should sign off on the report's accuracy before the legacy platform is switched off. Otherwise the first month-end on the new platform is when the gap surfaces, which is the worst possible time.

Why finance needs to be in the room before cutover

In every migration where finance was looped in late, the same three issues repeat: rate mappings need re-doing because finance disagreed with the PMO's read of which rate is which; capitalisation reporting wasn't rebuilt and the first quarter-end on the new platform misreported labour capex; billable utilization variance was larger than the PMO's tolerance because finance applies different rules. None of these are platform problems; all of them are coordination gaps. The fix is cheap: add finance as a named approver on Phase 1 (inventory) and Phase 4 (assign + validate). Their sign-off is what closes the loop on the rate mapping, the capex reporting, and the billable-utilization tolerance. Without it, the PMO ships the migration and finance discovers the cost weeks later, almost always at month-end, almost never on a calendar that allows for a graceful re-do.

The migration is the catalytic event; the long-term question is whether your PMO's capacity-planning practice still functions on the new platform. Four habits that differentiate teams that maintain rigor from teams that drift:

• Single source of truth, enforced. The enterprise resource pool is authoritative; project-local resource creation is a leading indicator of drift. Some platforms can lock down the per-project create permission. Use it if available; if not, run a weekly audit comparing per-project resource lists to the enterprise pool.
• Quarterly rate review. Standard rates that go un-reviewed for 12+ months drift away from actual fully-loaded labour cost. Costed timesheets then drift away from finance reality. Set a quarterly cadence to review rate tables and re-baseline.
• Named-exception discipline. Calendar exceptions accumulate silently. A resource with 30 named exceptions over 3 years is normal; without a review cadence the exceptions fossilise. Annually, review per-resource exception counts and prune anything older than the policy retention window.
• RBS evolution. The reporting hierarchy that was right at migration time gradually goes stale as the org reorganises. Plan a 6-monthly RBS review as part of the broader org-design review cadence so the capacity-view slicing stays meaningful.

The questions PMOs ask most often about the resource-model migration. The full FAQPage schema is embedded in this article's structured data so these surface in Google's "People Also Ask" feature.

Expand