Project Online Views Migration: Rebuilding Filters, Tables, and Dashboards

Every team that completes a Project Online views migration hits the same surprise. Schedules arrived. Resource pools look intact. Custom fields are mapped. The go-live demo begins, and the first question from the project managers is: where are our views?

The answer is uncomfortable: they did not migrate. They never do.

Project Online views, filters, and tables are configuration artifacts stored in the PWA site collection, not project data stored with your schedules. When you export .mpp files or pull OData feeds, the view definitions do not come along. Every view your PMs use daily has to be rebuilt from scratch in your destination tool: the task sheet formatted for weekly status, the resource usage view that surfaces allocation conflicts, the project center view the PMO director runs before every steering committee.

Context: this post is one piece of the 180-day Microsoft retirement window, the consolidated reference covering all three Microsoft Project ecosystem retirements happening in 2026.

TL;DR Project Online views migration is a rebuild, not a data transfer. PWA views, filters, and tables are site configuration; they do not export with project data. Before cutover, inventory every view by type, interview your PMs to identify the top-used views, and build a priority list. The top 20 percent of views drive 80 percent of daily PM usage. Rebuild those before any PM logs in to the new tool. Use the pilot migration project to validate rebuilt views against source data before mass rollout.

Why Project Online Views Migration Is Always a Rebuild

Project Online's view architecture sits one layer above your project data. A view in PWA is a combination of four components: a table (which columns appear), a filter (which rows appear), a grouping (how rows are organized), and a sort order. Each of these is stored as XML configuration attached to the PWA site collection, not inside the project files themselves.

When a migration tool exports your data via OData or .mpp, it reads project entities: tasks, assignments, resources, custom field values, baselines. It does not read the view configuration layer. That layer is effectively invisible to every standard export path.

The practical consequence: view rebuild time is non-trivial and needs a dedicated slot in your migration project plan. A mature Project Online tenant accumulates views over years. PMOs add views for new departments, new reporting requirements, new cost structures. A tenant running since 2015 can carry 80 to 120 custom views across task, project, and resource categories. Rebuilding them after cutover, when PMs are already frustrated with the new tool, is the wrong sequence. Inventory first. Rebuild in parallel with data migration.

Microsoft Project Online retires September 30, 2026, which means the view rebuild needs to be completed well before that date, not treated as post-migration cleanup.

How to Inventory Project Online Views Before You Exit

The inventory step takes half a day and prevents a month of post-migration firefighting. There are three places to look.

Enterprise views live in PWA Admin, under Look and Feel > Views. This screen lists all views by category: Task views, Project views, Resource views, and Assignment views. For each view, record the name, type, the table it uses, any filter applied, the grouping, and the sort order.

Project-level views are the subset of enterprise views that individual PMs have customized locally for their own projects. These do not appear in the admin list. The only way to capture them is to open representative projects from different departments and inspect the view menu on each one.

Project Center views (the portfolio-level views the PMO uses to see all projects in a single grid) are configured separately under Look and Feel > Project Center. These are often the most politically loaded views in the tenant: the one the PMO director shares with the steering committee, the one finance uses for budget tracking, the one the CIO checks before quarterly reviews.

The output of this inventory is a spreadsheet: view name, category, column list, filter definition, grouping, sort order, primary users (which team uses it most), and a priority ranking. You assign the priority ranking after the user interviews in the next step.

Which Views to Rebuild First

Prioritizing the view rebuild is a user-research exercise, not a technical one. Talk to five PMs from different departments and ask one question: which three views do you open in the first 30 minutes of every workday?

Those answers almost always cluster around the same small set: a task sheet formatted for weekly editing, a filter showing only "my assigned tasks," a project center filter scoped to a specific department or budget owner. These are your priority-one views. Build them in the destination tool before any PM logs in.

The diagram below shows how view types sort by rebuild priority.

Portfolio analysis views are often rebuilt as part of a broader PMO process redesign rather than a like-for-like migration. Treat those as a separate project, not a migration task, and budget accordingly.

Tables and Views: The Distinction That Trips Every Migration

Many teams inventory "views" and then miss half the rebuild scope because they conflate views with tables. The distinction is specific and consequential.

In Project Online terminology, a table is a column definition: which fields appear, in what order, and at what width. A view is a table combined with a filter, a grouping, and a sort order. One table can underlie many views. The default "Entry" table, for example, appears in more than a dozen standard PWA views.

When you rebuild a view, you need all four components. Capturing only the column list, which is the easiest part to document, produces a rebuild that looks right but behaves wrong. A view designed to show your assigned overdue tasks, filtered by Resource Name equals [Me] and Finish Date less than Today, returns a flat unfiltered list if you rebuild only the columns. The PMs see every task in the project and assume the data is corrupt.

In your inventory spreadsheet, add four separate columns per view: Table (column list), Filter definition, Group by, Sort by. Do not close the inventory session until all four are documented for every priority-one and priority-two view.

How to Rebuild Views in the Destination Tool

The rebuild sequence for any individual view follows five steps.

1. Locate the view in your inventory spreadsheet and confirm its priority tier.
2. In the destination tool, create a new view starting from the column set, mapping Project Online field names to the destination tool's field schema.
3. Apply the filter logic, translating PWA filter syntax to the destination tool's filter interface.
4. Add the grouping and sort order from the inventory record.
5. Validate by opening three to five representative projects and confirming the view returns the same rows the source view returned.

Step two is where field-mapping gaps appear. Some Project Online custom fields need to be recreated in the destination tool before you can include them in a view. If you have not completed the enterprise custom fields migration, that work must precede the view rebuild for any view that filters or groups on a custom field.

Tie the view rebuild milestones to your overall Project Online migration checklist so the work does not slip into post-cutover stabilization without a plan or a resource assignment.

Translating Filters from PWA to Modern Search

Project Online filters use a simple syntax: field, operator, value. Resource Name equals [Me]. Finish Date is greater than Today. Flag1 equals Yes. Most modern PM tools use the same underlying concept with different UI metaphors: saved filters, smart lists, or preset searches.

Before rebuilding each filter, verify the underlying field exists in the destination tool's schema. Dynamic filters that reference the current user ([Me]), today's date (Today), or relative periods (This Week) are particularly important to preserve. A "My Tasks" filter that works for every PM without manual updates is a daily productivity multiplier. A broken dynamic filter that returns everyone's tasks is a daily frustration multiplier.

For filters built on Project Online enterprise custom fields, the corresponding custom field must exist in the destination tool before the filter can function. A filter referencing a missing field returns zero results with no useful error message, and PMs assume the migration dropped their data.

What Does Not Translate Directly

Some Project Online view types have no direct equivalent in many modern PM tools. Knowing these gaps before the demo prevents credibility problems.

Resource usage views in Project Online display assignment data across time, with rows for each resource and columns for each time period. Modern tools typically represent this information as a resource heatmap or utilization chart. The underlying data is the same; the interaction model is different. Brief your resource managers on the new format before cutover, or the first capacity review becomes a support session instead of a planning conversation. If your team relies heavily on resource utilization data, the Resource Heatmap handles this view category natively.

Portfolio Analyzer views use a visualization engine to compare projects on multiple dimensions: cost, risk, and strategic alignment. Most modern PM tools have portfolio dashboard equivalents, but they are built differently and require two to four days to recreate a typical analysis view.

Timesheet-linked task views that show hours reported versus hours estimated do not port directly unless the destination tool has integrated timesheet functionality. Coordinate those during timesheet migration planning, not during the view rebuild sprint.

Using the Migration as a View Rationalization Opportunity

The forced rebuild is an opportunity worth taking deliberately. In a mature Project Online tenant, a significant fraction of views exist because someone created them for a project that ended years ago and never removed them. The rebuild is a natural forcing function to ask whether each view still has active users.

For any view you cannot find a current user for after brief interviews, park it. Do not rebuild it immediately. If someone asks for it post-migration, rebuild it then. Roughly 30 to 40 percent of views in a mature tenant fall into this dormant category. Not rebuilding them saves real effort and produces a cleaner view library in the destination tool. Future PMs inherit a curated set of views, not a ten-year accumulation.

Set expectations before cutover: the first four weeks after go-live are when view change requests arrive at the highest volume. Budget one day per week of PMO resource time for view requests during stabilization. After four weeks, the request rate typically drops to normal maintenance levels.

The Project Online Inventory Checklist guides you through your tenant's views, custom fields, and project data in one structured session, so you capture everything in a single pass rather than returning to the admin console three times before you find the dashboard filter definition you forgot to record.

Run the free Project Online Inventory Checklist Walk through your views, custom fields, and project data in about 10 minutes and get a structured export plan you can hand to your migration team. No signup required. Open the checklist

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