Resource capacity planning after Project Online: what to preserve, what to rebuild

When clients ask us where the hard part of a Project Online migration lives, the answer is almost always resource capacity planning. The plans themselves migrate cleanly enough. The reports can be rebuilt. The customizations are usually small in count, if not in pain.

The resource model is different. Project Online’s enterprise resource pool, with its calendars, cost rate tables, RBS hierarchy, and generic resources, is the part that successor platforms most often do not replicate fully. Decisions made here shape the PMO for years afterward.

This is what we tell clients about that decision.

What Project Online’s resource model actually contains

Project Online’s resource side has six layers worth understanding before you migrate:

1. The enterprise resource pool. The master list of named individuals, plus generic placeholders.
2. Resource calendars. Per-person availability, exceptions, holidays, time off.
3. Cost rate tables. Up to five rate tables per resource, often used for billing rate vs. internal rate.
4. The Resource Breakdown Structure (RBS). A hierarchical organization model used for filtering, security, and capacity reports.
5. Custom resource fields. Often dozens, used to categorize, filter, or drive custom logic.
6. Capacity views and modeling. What-if scenarios, demand vs. supply views, portfolio-level capacity reporting.

The reason this is hard is that successor platforms typically replicate one or two of those layers, not all six. Microsoft Project for the web has a flat resource list. Most lightweight PM tools do not have the RBS concept at all. Reporting tools can rebuild capacity views, but only if the underlying data model supports it.

What you actually need

The right starting question is not “how do we move all this.” It is “how much of this does our PMO actually depend on day to day?”

We work through this with clients in a structured way:

• Named vs. generic resources. Most PMOs use a mix. The named pool migrates cleanly to almost any target. The generic resources tied to capacity planning are the harder piece.
• Calendars. If your PMO uses individual calendars actively (sick days, vacation, regional holidays), you need a target that supports them. If calendars are mostly default, you can simplify.
• Cost rates. If you are doing billable work, you almost certainly need rate tables. If you are running internal projects only, you may be able to flatten this to a single rate per resource.
• RBS hierarchy. This one is binary. You either use it for filtering, security, or capacity rollup, or you do not. Teams that use it heavily need a target that can replicate it.
• Custom fields. Audit them. Most PMOs have a dozen they need and a dozen they do not. Migrate the first set, retire the second.
• Capacity modeling. This is the hardest to replicate and often the most valuable feature. Confirm the target platform can do what you need before committing.

What different successor platforms preserve

Microsoft’s successor (Project for the web) loses most of this. It has named resources, basic calendars, and that is roughly it. No RBS, no cost rate tables, no enterprise capacity modeling.

For mid-market PMOs whose Project Online use was mostly the basics, that is fine. For PMOs running enterprise-scale capacity planning, it is not.

The full landscape of options:

• Microsoft Project for the web. Lightweight, integrates with Planner. Right for simple PMOs. Wrong for capacity-heavy use.
• Smartsheet, Wrike, Monday, ClickUp, and similar. Mostly task and project tracking. Resource modeling is light.
• Dedicated enterprise PPM platforms. Planview, Clarity, OpenText. Heavy, expensive, capable.
• Onplana. A modern cloud alternative we built specifically for the Project Online migration use case. It preserves the multi-layer resource model, supports RBS, and is meaningfully cheaper than the legacy enterprise PPM tools. Onplana publishes a layer-by-layer guide at Resource capacity planning migration that walks through preserving each of the six layers.

The right choice depends on what your PMO actually needs. We help clients work through this assessment when they are not sure.

What to validate before cutover

A migrated resource model is not done when the data is loaded. It is done when the capacity views match the source within a tolerance you can defend.

The validation checklist we use:

• Resource list count and attribution. Every named resource accounted for, every generic placeholder mapped.
• Allocation totals across active projects. The resource hours allocated in the source should match the target within plus or minus 5%, lower if your reporting depends on tighter accuracy.
• Cost calculations. Rate-table-driven costs should match within plus or minus 1%. Variance here is usually a rate-table mapping problem.
• Calendar exceptions. Spot-check holidays and time-off entries on a sample of resources.
• RBS rollup. If you use it, run capacity reports at each level and compare.

Tolerance bands matter because exact matches are rarely possible. Different platforms round differently, treat overtime differently, allocate fractional days differently. Define what “acceptable” means before you migrate, not after.

What we tell clients

The resource model is where Project Online migrations succeed or fail. Plan it deliberately. Pick the target before you start exporting. Validate against tolerance bands rather than exact matches. And do not assume any successor platform replicates Project Online’s full feature set, because almost none of them do.

If you are mid-migration and the resource model is the part keeping you up, it usually is. We have done enough of these to be useful here.