- Article
- Quick Fixes Teil 2
- Ressourcen Assignments
- automatic baselines
- Automatic baselines (video)
- Templates
- Prefixes
- Calendar
- Summary Tasks & Milestones
- Hammock Tasks & E-Days
- User administration
- Quick fixes part 1
- Projekt updates
- Import options
- User Modes
- Baseline Import
- proimporter vs. P6-Import from Microsoft Project
- Release updates
- Webinar

proimporter Release 26.4.0
Discover the new Features of proimporter: Release 26.4.0 now available!

proimporter Webinar on August 21, 2026
proimporter enables you to import projects and datasets from Oracle Primavera P6 and MS Project into your P6 target databases in a simple, precise, and secure way. All in one, fast and without manual cleanup!

Imports are a continuous process
Why Stable Processes Matter More Than the Perfect Start
Imports between Microsoft Project and Primavera P6 are standard in many projects—and at the same time one of the most common causes of inconsistent schedules.
When introducing new planning systems or switching tools, the focus is often on the first import. Data is prepared, structures are defined, and processes are aligned to ensure the cleanest possible start. In many cases, this works: the initial import functions properly, the data is consistent, and the schedule is usable.
But this is often exactly where the real problem begins.
Imports are usually treated as a one-time step—such as the initial transfer from Microsoft Project to Primavera P6 or the consolidation of different project versions. These scenarios are easy to plan and are implemented with appropriate care. At the same time, it is often underestimated that import processes recur regularly in day-to-day project work and that is where problems arise.
Import Processes in Practice: More Than Data Transfer
In environments with Primavera P6 and Microsoft Project, two typical scenarios arise. On the one hand, data is exchanged between systems—for example, when schedules are transferred from MS Project to P6 or consolidated between different project stakeholders. On the other hand, new versions are regularly imported within a single system, projects are updated, or versions are merged.
These processes are not simple data transfers. Structures, calendars, resources, and progress logic must be interpreted and transferred. Particularly when switching between systems, differences arise that are not immediately visible but have a long-term impact on data quality.
The Real Challenge: Repetition
As a project progresses, new import requirements arise regularly. Schedules are updated, progress is incorporated, and new data is integrated. With each iteration, small deviations begin to creep in.
Mapping logic is slightly adjusted, decisions are made situationally, or changes are applied manually. Especially between Microsoft Project and Primavera P6, this quickly leads to different interpretations of calendars, progress, or constraints. But inconsistencies also arise within a single system when multiple versions of a plan exist and are handled differently.
The result is not an obvious error, but a gradual loss of quality and traceability.
Where Problems Arise
The root cause lies in the fact that import decisions are not made consistently over time. With every import, implicit decisions are made again about how data is interpreted and transferred.
Individual adjustments may seem reasonable, but they lead to multiple variations of the same logic. Comparability decreases, developments become harder to trace, and confidence in the schedule declines.
Thinking of Imports as a Process
The crucial step is to understand imports as a repeatable process. The goal is a stable logic that delivers consistent results regardless of the individual case.
To achieve this, rules for mapping, data transfer, and interpretation must be defined once and then applied reproducibly. Import processes thus evolve from a one-off task into a structured workflow.
How to Stabilize It
In practice, this means fewer situational decisions and more standardization and transparency. Import logic is defined and reused instead of being reinterpreted with each run.
This is exactly where proimporter comes in. The focus is on making the underlying import logic visible and repeatable. Import rules can be defined and applied consistently so that recurring updates follow the same principles. In addition, issues are identified early and can be corrected before the actual import takes place.
The key point is not only improved control, but also the economic impact:
A standardized import process significantly reduces manual rework, lowers coordination effort between stakeholders, and prevents errors that would otherwise require costly corrections later. Especially with regularly recurring imports, these effects quickly add up to a measurable advantage in terms of time and cost.
This creates a more stable and efficient overall process—particularly in scenarios with frequent updates or system transitions between Microsoft Project and Primavera P6.
Conclusion
Imports are not a one-time step, but an integral part of modern project control—both between Microsoft Project and Primavera P6 and within the systems themselves.
The decisive success factor is not the perfect initial import, but a consistent process across many iterations.
This is precisely where the added value of proimporter lies. By defining, reusing, and making import logic transparent, dependence on individual decisions is reduced. At the same time, manual effort, error costs, and coordination requirements decrease over the course of the project.
The result is not just a more efficient import in individual cases, but a stable and economically viable overall process. And it is exactly this difference that determines whether schedules remain reliable in the long term—or lose quality with every update.
In Short - proimporter
Users of Oracle Primavera P6 know the problems that arise when importing external XER and MPP files into their own P6 database. proadvise GmbH offers an in-house solution to this problem: proimporter! In this short video, we show you how our handy tool works.