Microsoft Project vs Primavera P6: Baseline Management

This is a series of posts that will help to dispel myths, understand the capabilities and limitations of Microsoft Project and Primavera P6, and reveal the real, bias-free differences.

Let’s examine how baseline management is implemented in both tools. Because baselines are handled differently, planners often compare the systems from a preferred, and often biased, perspective. A side-by-side view helps reveal the real capabilities and gaps.

In Primavera P6, a baseline is essentially another schedule stored as a baseline version. This is a good approach as it stores the full snapshot, not only some data points. However, the system does not have native fields to store baseline data points (for example, baseline start or finish dates) within the same schedule.

Primavera has a large set of baseline fields available for users.

Still, there are many baseline data points that not available for Primavera P6 users. Dependencies, resources and assignment data, just to mention.

Microsoft Project, in contrast, has only a limited set of baseline fields within the schedule itself.

Baseline data fields are limited to these 14 data points only. There are also no baseline fields to store dependency, resource and assignment information.
The desktop version provides eleven (0-10) sets of baseline fields, while Project Online supports Enterprise fields, allowing the creation of practically unlimited additional baseline fields. However, Project Online is no longer a practical option, as this component is scheduled for retirement in September 2026. Project Server users still have this capability, but this alternative has its own downsides.

Noticeable difference between systems is the ways baseline data is stored. In Primavera it is a separate schedule that must be provided to external users together with the schedule but for Microsoft Project data points are stores within schedule.

However, this is not the only way to store baselines. Nothing prevents Microsoft Project and Primavera P6 users from saving a separate schedule as a baseline snapshot, and many schedulers do so. More importantly, how can users use baselines later.

Both systems include functionality to compare schedules, allowing users to compare a current schedule with a Baseline. Additionally, the schedule comparison analysis in Microsoft Project can be enhanced with third-party add-ons, but gaps in the core system make it difficult to perform comparison analysis properly. Primavera P6 supports user-configurable unique activity codes – a critical mechanism for reliable data comparison. This capability is missing in Microsoft Project. Using task UID (autogenerated System ID) is a common workaround, but it has limitations because the recreated activity has a new UID.

By comparing UID sequences, users can infer structural changes in the schedule: higher UID values typically indicate newly added tasks, while gaps in the sequence reveal deletions. However, this approach has a fundamental limitation. Once a task is deleted, its UID is permanently lost, and any recreated activity will be assigned a new identifier. This breaks traceability and complicates rigorous change analysis.
The highest numbers indicate new tasks, and missing UIDs suggest deleted tasks, but there is no way for a recreated activity to have the same ID. Primavera P6 doesn’t have this issue.

Primavera P6 users, in contrast, do not suffer from this specific limitation in the same way. However, it has a different constraint: each activity is assigned a system-generated ID, but this identifier is not exposed to users on the frontend. It exists only in backend structures and XER exports, effectively preventing planners from leveraging it for day-to-day analysis or audit purposes. It is possible that the same Unique Code is reassigned to a different task. It may lead to incorrect baseline analysis. 
Schedule comparison capability is a major topic worth a separate post.

Primavera P6 provides an explicit way to convert a schedule into a baseline. Microsoft Project doesn’t.
Primavera P6 allows users to store a theoretically unlimited number of baselines, along with a timestamp, but does not allow adding metadata describing each baseline version.

In practice, P6 administrators impose limits, commonly around ten baselines per project. It is insufficient for many projects to analyse progress over large periods.

Primavera supports baseline classification.

The list can be modified. A Primavera Administrator can adjust Baseline Types.

In Microsoft Project Baseline0–Baseline10 are simply unnamed containers. Usually, schedules address this by setting business rules that define which baseline belongs to which category. Primavera P6 planners instead set baseline naming rules, but they can’t set multiple project baselines for a single project. Microsoft Project users may apply up to 11 project baselines per project, but each includes only a few data points.

Many organisations confuse baselines and snapshots. The term ‘baseline’ lacks a single generally accepted definition. General rules:
1. Each baseline is a snapshot but not each snapshot is a baseline.
2. Baseline represents commitment, snapshot may not.

As already mentioned, Primavera P6 has a critical constraint: it supports only one Project Baseline, plus three User Baselines. This often becomes a significant limitation in environments where multiple users work with the same schedule.

For example, suppose a planner wants to set slippage calculation against both the formal baseline and a last-month snapshot – beneficial metrics for any project. Because only one project baseline can exist, it is impossible to configure this comparison to guarantee that all users see the same baseline references.
Instead, each user must manually assign the same user baseline (beyond the first baseline). This approach is error-prone and can easily lead to inconsistent analysis.

Another scenario where this limitation becomes critical is system integration. When connecting Primavera P6 schedules to external systems via backend integrations, the single-project baseline restriction makes it difficult to analyse baseline dates and previous-period snapshots simultaneously – the common requirements in mature portfolios. Complex workaround solutions are required to overcome this limitation.

Microsoft Project does not have this restriction, but backend integration will be extremely difficult without Project Online. Each baseline is a project baseline. On the other hand, users don’t have user baselines. If they need to perform their own analysis, they must agree on how to share available baseline fields.

Neither system provides true version management.

Neither system supports trend analyse considering captured baselines. 

Primavera P6 provides comprehensive capability to update baselines, but some Primavera consultants recommend avoiding this feature completely. It was developed with a particular process in mind. The process is not documented and may not be suitable for every portfolio.

Also, it may be important to completely lock the baseline, but the system doesn’t provide configurable access to this module, and some users may make authorised changes to the baseline.

On the other hand, for companies that primarily use Primavera P6 to manage contract schedules may find this feature useful.

Microsoft Project doesn’t provide specialised capabilities to update baselines. Users just update baseline fields directly.

Microsoft Project has an “Inactivate tasks” feature that allows users to add tasks, assess their impact on the schedule, submit a change request, and then deactivate those tasks until approval is granted.

However, this feature should be used with caution. If all predecessors or successors of a task are linked to inactive tasks, it may create hidden open ends in the schedule that are hard to identify. 

Another interesting difference appears when a schedule does not yet have a baseline.
In Microsoft Project, baseline fields remain blank, clearly indicating that no baseline has been set.

In Primavera P6, baseline columns always display dates even when no baseline is assigned. These are not forecast dates, as many may assume, but Planned Dates — a concept unique to Primavera P6 and commonly misunderstood by users.
This Primavera P6 ‘feature’ can easily lead to misleading reporting. A project may appear to perform perfectly against a non-existent baseline.

At the portfolio level, the issue becomes even more problematic. When schedule data is exported to external tools such as Power BI, it becomes difficult to distinguish between projects with a baseline and those without one. As a result, portfolio reports may incorrectly classify projects without baselines as “on track.”
There are workarounds to mitigate this issue, but they require additional configuration, effort and assurance.

Both systems allow to visualise baselines on Gantt Charts.

Microsoft Project

Users can develop their own views or apply Tracking Gantt to see the two bars side by side for each task.

Primavera P6

Default layouts are not suitable for baseline analysis, but there are good, free layouts that can be imported easily.  

Finally, Project Online offers a capability that neither Primavera P6 nor Desktop Microsoft Project fully provides: the ability to restrict access to update dates by Role.

• Protected Baselines (Baseline 0–5): These are typically restricted to the Project Management Office (PMO) or administrators. Locking these ensures that high-level portfolio reporting and executive dashboards remain consistent and are not accidentally overwritten.
• Unprotected Baselines (Baseline 6–10): These are usually left open for PMs to use freely to track internal project versions.

As already mentioned, Project Online is at the end of life, and soon this capability will not be available for Microsoft Project users.

Baselines are handled differently in both systems. Each has its own advantages and gaps. Some capability gaps are common for both systems. Neither provides full capabilities for governing nor analysing baselines. Because provided baseline capabilities and gaps may or may not be critical to a particular program/portfolio, it is hard to say which system is better. There is room for improvement in both systems.