Project Online IT Services Migration: Client Workflows, Billing, and Timesheets

Here is the failure mode that hits Project Online IT services firms harder than any other industry. The migration team completes the technical cutover on a Friday. Project schedules, resource assignments, and custom fields all move cleanly to the new tool. Saturday morning, someone in finance runs the weekly billing export. The export script points at Project Online's OData feed. The feed is gone. The pending invoices for six client engagements are stuck. Nobody on the migration team knew the billing system consumed Project Online data directly.

This is not a hypothetical. It is the most predictable failure mode for professional services PMOs migrating off Project Online IT services-configured tenants, and it happens because billing integrations are never on the project management team's radar during migration planning.

IT services firms and professional services organizations use Project Online in ways that look similar to corporate PMOs on the surface but are fundamentally different underneath. The difference is that in a PS firm, the PM tool is not just a planning and reporting layer: it is the source of truth for billable hours, and anything that reads those hours to generate invoices will break at cutover if it is not explicitly migrated.

TL;DR IT services and professional services firms have three migration risks that generic Project Online migration guides skip: the timesheet-to-billing chain that breaks at cutover if finance is not in scope, client isolation controls that must be reproduced in the destination tool before go-live, and utilization rate cards that flatten on migration and break past-period billing calculations. Address these three things first. The schedule data is the easy part.

Why Project Online IT Services Configurations Are Different

A corporate PMO uses Project Online to track project progress and resource load. An IT services PMO uses it to do those things and, additionally, to record the billable hours that drive invoices.

The distinction matters because migration risk is proportional to how many systems consume data from the tool being replaced. A corporate PMO might have one or two consuming systems: a Power BI dashboard and an executive status report. An IT services PMO may have four or five: a billing system, a client portal, a utilization report for the resource manager, a bench report for the sales team, and a finance reconciliation export.

Every one of those consumers breaks at cutover unless it is explicitly migrated. The technical migration handles the project data. The consuming integrations have to be handled separately, by the teams that own them, on a schedule that aligns with the cutover window.

The Timesheet-to-Invoice Chain

The core billing workflow in a Project Online IT services configuration runs like this: team members log hours against project tasks in the PWA timesheet. The timesheet manager reviews and approves the hours. A billing administrator exports the approved hours, typically via the OData feed or a custom report, and loads them into the billing system to generate invoices.

That chain has four links: time entry, approval, export, and billing system ingestion. The migration disrupts all four.

The diagram below shows the full timesheet-to-invoice chain and the two cutover points where firms must take deliberate action.

Time entry: In the new tool, team members log hours using the new timesheet interface. Before cutover, they need training on the new entry workflow and the mapping between old task types and new ones.

Approval: The approval workflow in Project Online is a PWA-specific flow. In most destination tools, approval is configured separately as a policy rule or notification workflow. This must be built and tested before cutover, not after.

Billing export: The OData feed URL changes at cutover. Every system that pulls from the OData feed needs a new data source configured and tested in the destination tool. Finance must be part of the cutover planning call, not a notification-after-the-fact.

Invoice generation: The billing system ingestion is the most firm-specific step. Some firms export a CSV. Some use a direct API. Some use Power Automate. Whatever the format, it must be validated end-to-end in the new tool before go-live.

The only safe cutover timing is at a timesheet period boundary: close and approve all outstanding timesheets in Project Online before the cutover weekend, export the final period data, then open the first period of the new billing cycle in the destination tool on Monday.

Multi-Client Portfolio Isolation

Project Online IT services configurations typically use PWA permission categories to isolate client data. A resource working on Client A's projects should not be able to browse Client B's schedule or budget. The PM for Client A should not be able to see Client B's resource pool.

Most destination tools implement an equivalent access control model using role-based access, portfolios, or workspace isolation. The critical step is to verify that the isolation model in the new tool actually works before migrating client data into it.

The test is simple: after standing up the destination tool and configuring access controls, log in as a resource assigned only to Client A's projects and attempt to navigate to Client B's project list. If Client B's data is visible, the isolation is not configured correctly.

This test catches a class of misconfiguration that is easy to introduce when translating PWA's category-based permissions into a modern role model. PWA's categories are an all-or-nothing view by project set. Modern tools use hierarchical permissions that can have subtle inheritance rules. An administrator who configures the top-level portfolio as visible to all users and then restricts at the project level may find that project listings are still accessible at the portfolio level.

Run the isolation test for every client boundary in the pilot phase, before any client data is imported.

The resource heatmap tool can help identify which resources sit at client boundaries (shared across multiple client portfolios) before migration, so access control policies can be configured with those boundary resources in mind.

Rate Cards and Utilization Tracking

Professional services firms often use Project Online's resource cost rate tables to handle billing rate complexity: different billing rates for the same resource on different contracts, rate escalation clauses that change rates at mid-project, and different rates for different work types (design, implementation, QA).

Project Online supports up to five time-phased rate tables per resource. Most destination tools support a single rate per resource, or at most a rate per resource per project type. The migration typically flattens the complex rate structure to the current active rate.

This creates two problems. First, new project billing calculations use the flattened rate, which may not match the contracted rate for a given client. Second, historical earned value calculations that depended on the time-phased rate structure become incorrect in the new tool's view.

The mitigation is to document the current active rate for every resource before migration and validate that the billing system produces correct invoices for a test period using the migrated data. For resources with mid-project rate changes coming, plan the rate-change workflow in the new tool before cutover.

Utilization tracking is the other data dependency that breaks silently. IT services PMOs track utilization against target ranges: a resource at 70% billable utilization is healthy, at 90% is burning out, at 40% is a bench cost. That calculation in Project Online runs against the Enterprise Resource Pool and the timesheet data. In the new tool, both data sources must be populated and the utilization formula must be configured before the PMO can produce accurate utilization reports.

If the new tool does not have built-in utilization reporting at the level the PMO needs, the migration plan must include rebuilding the utilization report in Power BI or a similar tool, pointed at the new data source. That rebuild belongs in Phase 1 scope, not discovered after go-live.

Status Reporting to External Clients

Many IT services PMOs produce weekly or bi-weekly status reports for clients directly from PWA data: milestone status, hours burned this period, hours remaining to completion, and risk register updates. After migration, those reports need to come from the new tool.

The risk here is not technical. It is perceptual. A client that has been receiving a consistent status report format for two years will notice when the format changes at migration. If the PMO does not proactively communicate the format change and the reason for it, the client may interpret the change as a signal that something went wrong with their project.

The right approach: tell clients about the migration before cutover, explain that the report format will update, and send a side-by-side comparison showing that the new format covers the same information. A status report generated from the new tool's actual project data makes the format transition feel like an upgrade rather than a disruption.

The Migration Sequence for IT Services Firms

The standard phases apply, but the IT services firm must sequence them differently.

Phase 1: Inventory. Standard migration inventory plus: map every system that consumes PWA timesheet data, document the approval workflow for each client engagement type, list all billing rate tables and the contract clauses that govern them, identify which client portal or reporting tools pull from the OData feed.

Phase 2: Tool selection. Standard evaluation plus: verify that the destination tool supports multi-client access control isolation, test timesheet approval workflow capability, confirm billing export formats match what the billing system expects, and run a rate card migration test. The free Migration Preview runs a .mpp round-trip and shows custom field migration quality, which is where rate card data lives.

Phase 3: Pilot. Run the pilot on a completed engagement, not an active one. A completed engagement lets you validate the historical timesheet data migration without disrupting a live billing cycle. Compare approved hours, rates, and billing summaries between PWA and the new tool. If the numbers match, the migration is validated. If they do not, diagnose before proceeding.

Phase 4: Billing handoff rehearsal. Before the live cutover, run a full billing period end-to-end in the new tool with test data. Finance approves the simulated period, the billing export runs, the invoices are generated. This rehearsal catches configuration gaps in the billing integration before they affect a real client.

Phase 5: Wave migration and billing handoff. Cut over at period end. On the cutover weekend: lock and export the final PWA period, import the data to the new tool, configure the billing export connection, verify it with finance before Monday morning. The project online migration checklist covers the general cutover steps; add the billing handoff rehearsal and the client isolation test to your version.

Per Microsoft's lifecycle documentation, Project Online retires September 30, 2026. IT services firms that handle the billing chain, client isolation, and rate card migration explicitly will have a smooth October 1. The ones that treat the billing integration as an afterthought will have a war room with finance instead. The full migration guide covers the governance structure for coordinating the business stakeholders who need to be part of the cutover plan.

Run the free Migration Preview before committing to a destination tool Upload a real .mpp file from an active client engagement to see dependency fidelity and custom field migration quality. Rate card complexity surfaces in the preview report. No signup required. Open Migration Preview

Microsoft Project Online™ is a trademark of Microsoft Corporation. Onplana is not affiliated with Microsoft.