You can make your
Powerproject can export to and import from two different Microsoft Project-compatible file formats:
- XML - used by Microsoft Project from version 2002 onwards.
- MPP - Microsoft Project's native file format. Note that you can export to and import from this file format only if you have Microsoft Project installed on the same computer as Powerproject.
If you have Microsoft Project installed on the same computer, you can also choose to export only the current branch or view to XML or MPP format, and to import Microsoft Project projects that have been saved as MPP or XML files into specific charts or summary groups within existing Powerproject projects.
Powerproject and Microsoft Project file formats
Due to the limitations of the MPP and XML file formats, some of the information from your Powerproject projects may be lost if you export them into one of these formats. Similarly, some of the information in an MPP or XML file may be modified or lost when you import it into Powerproject. For this reason, once you have imported an MPP or XML file into Powerproject, you are advised to save the project subsequently in Powerproject's file format - as a PP file - to avoid losing information that is not supported by the MPP and XML formats.
When exporting a Powerproject file to MPP or XML file format, note the following points.
Microsoft Project does not support bars as such, and therefore it does not support Powerproject's subheadings - bars with a name but with no tasks. You can choose during the export whether to ignore subheadings during export, or whether to convert them into hidden tasks that have the name of the subheading bar. Note that if you choose to do this, although the tasks that are used to represent subheadings in Microsoft Project are hidden from view, they will affect the summaries in which they are located.
As Microsoft Project does not support bars, any bar-level user-defined fields are lost during export.
Tasks that appear on the same bar in Powerproject appear on different lines after conversion:
Powerproject supports start milestones and finish milestones, while Microsoft Project supports only one type of milestone. All milestones are therefore converted into the same type during export.
Microsoft Project does not support expanded tasks. All expanded tasks are converted into summary tasks during export.
Microsoft Project does not support empty summary tasks. All empty summary tasks are converted into normal tasks during export.
Some users keep their hammocks together in a project, by locating them in a summary group that contains nothing but hammocks. If a summary group contains nothing but hammocks, the summary task is excluded when you export a project for use in Microsoft Project.
Microsoft Project does not support hammock tasks. All hammock tasks are lost during export.
Microsoft Project does not support buffer tasks. All buffer tasks are converted into normal tasks during export, with an associated deadline, but are marked as being buffer tasks using a custom field so that they are converted back into buffer tasks when files are imported back into Powerproject. Note that no additional constraint is applied to buffer tasks that have no incoming links (as Microsoft Project does not support more than one constraint on a task), so unless there is a preceding task on the same bar, buffer tasks with no incoming links are moved to the project start date.
Microsoft Project does not support interruptible tasks. All interruptible tasks are converted into normal tasks during export, using the current rather than the original duration.
Links with lead/lag
Microsoft Project supports only a single lead/lag value on one end of a link. If a link has more than one lead/lag value, the two are combined into a single value during export.
Percentage-based lead/lag on links is converted to the equivalent, unless links have more than one lead/lag value, in which case the lead/lag values are converted into time-based values so that they can be combined into a single value.
The following example shows how a link with 1 week lag at each end, a link with 50% lag on the start task and a link with 25% lag on both ends are converted:
Calendars in Microsoft Project are much less flexible than those in Powerproject: they must consist of seven recurring days with up to five working time periods. Any objects in a project that use a calendar that does not meet this specification are converted to use the default calendar during conversion.
Microsoft Project does not allow calendars to share a name, so if two or more calendars share a name in a project, the names of all but the first calendar are adjusted slightly during export. The "Calendars" folder itself is not exported.
Microsoft Project has a calendar name limit of 52 characters. If a project contains any calendars with names that are longer than 52 characters, the names are truncated during the export process.
Microsoft Project supports only two types of exception: working and non-working. All Powerproject exceptions must be one of these two types, regardless of their name, so they are converted to the relevant exception during export.
Cost and income rates
Resource cost rates are calculated differently in Microsoft Project. Cost and income rates recorded against permanent resources are lost during conversion, and resource cost rates are calculated from the rates that are recorded against allocations. Multiple cost and income rate assignments against an allocation are combined into a single value during export.
Resources in Microsoft Project can have up to five cost rate tables, with costs that can change over time: up to twenty-five times in total. In order to get around these limitations in the way that cost rates are dealt with in Microsoft Project, if there are more than five allocations of the same resource on the same day with different cost and income rates, or if the cost and income rate of an allocation changes more than twenty-five times in a day, duplicate resources are created (with suffixes of .2, .3, etc) during export. You are warned that the cost values for these resources will be incorrect.
Resources and costs
Microsoft Project supports only one assignment per resource to a task, which is insufficient to represent the multiple resource assignments that are allowed in Powerproject. If a task in Powerproject has more than one assignment of the same resource, duplicate resources are created (with suffixes of .2, .3, etc) during export. You can choose whether or not to export resource and cost allocations.
Negative costs and income
Powerproject supports positive and negative costs, and positive and negative income. Microsoft Project supports positive and negative costs, but has no concept of income. You specify how income should be handled during the export process. You can choose to convert any positive income into negative costs and any negative income into positive costs in the resulting file, or to remove any income from the resulting file altogether.
Overtime in Powerproject is incompatible with Microsoft Project where progress is involved. All overtime is converted into working time during export. Although the related costs are the same after export, it is not possible to identify the working time as overtime.
Microsoft Project does not support the concept of variable dates, so any variable dates within a project are converted into fixed dates during export, based on the date to which the variable date corresponds on the day of export. For example, if you export a project on 23/11/2019, a variable date of 'Today' is converted into the fixed date of 23/11/2019.
Code library assignments against each task and resource can be exported into a custom field of the "text" type, with the name "CodeLibrary:<code library entry name>". For example, if a "Subcontractor" code library entry has been assigned to a task, a custom field called "CodeLibrary:Subcontractor" will be created against the task during export. A number of custom fields relating to code libraries that have been created during export are illustrated below:
Each custom field lists the names of codes that have been assigned to the task or resource from the relevant code library, with each code library entry separated by a semi-colon. A hierarchy of code library entries is represented as a "dotted" list of levels. For example, assignments of the Floor Level code library illustrated below would be shown as "1st.1st North"; "1st.1st South"; "2nd.2nd West"; and so on:
As there is a limit to the number of text-type custom fields in Microsoft Project, you may need to limit the code libraries that you include in an export if you export a very large project or a project with a very large number of code library assignments. You can choose which code libraries to export during the export process.
Note that code library assignments that have been made against allocations are not exported. Note also that if a single code library contains multiple code library entries with the same name, these code library entries are effectively combined into one code during the export. For this reason, if you plan to export a project to Microsoft Project, it is advisable not to give code library entries within the same library the same name.
As it is not possible to colour the bar chart in Microsoft Project using colours and patterns that have been assigned to code library entries, code library appearance data is not exported.
Work breakdown structure
If a work breakdown structure has been defined in a project, the position of each task in the work breakdown structure is exported into a custom field of the "outline code" type. If a work breakdown structure exists in a project, entries from the WBS hierarchy are mapped directly into the first outline code custom field for each task, so that the WBS code is exported as the outline code value and the WBS name is exported as the outline code description, as illustrated below:
By default, Microsoft Project defines the period (full-stop) character to be its separator character. If any WBS codes include period characters, these characters are removed during the export; if this would result in an empty WBS code, a question mark is inserted as the WBS code. For this reason, if you plan to export a project to Microsoft Project, it is advisable not to use period characters in your WBS codes.
Each level in the Microsoft Project outline code lookup table requires a mask to be defined for it, to specify the format of entries at each level of the table. As Powerproject uses alphanumeric formatting at all levels of the WBS, each code mask is assigned an "any" length character sequence during the export. Microsoft Project only permits non-alphanumeric characters to be used as mask separators. If an alphanumeric character has been entered into the Path separator field on the Format tab of the Options dialog in Powerproject, this is replaced by a period character during export.
Unique task IDs
Microsoft Project does not support Powerproject's unique task IDs, but a project's unique task IDs are exported into a custom field so that they are not lost when files are imported back into Powerproject.
When you import an MPP or XML file into Powerproject, note the following points.
Microsoft Project does not support bars as such; however, it does support null tasks. Null tasks are converted into empty bars during import.
Deadlines in Microsoft Project are separate from constraint flags; in Powerproject a deadline is a type of constraint flag. If a task has both a deadline and a constraint flag, the deadline is removed during import.
Microsoft Project supports the concept of split tasks: tasks that are separated into multiple segments with specific gaps between them. Split tasks are converted into multiple tasks on the same line with a link between them - with the appropriate amount of lead/lag - during import:
Microsoft Project supports only one type of milestone, while Powerproject supports two. Milestones are converted into start milestones during import if they have more outgoing than incoming links, and into finish milestones in all other cases.
Links with lead/lag
In Microsoft Project, any lead/lag on links between tasks that use different calendars is always calculated using the successor task's calendar. In projects that are imported from Microsoft Project, lead/lag on links between tasks that use different calendars is calculated using the successor task's calendar. In addition to this, if a Microsoft Project file contains any links between tasks that use different calendars that have their lead/lag defined in terms of percentage rather than in terms of duration, this percentage lead/lag is converted to a fixed duration when the project is imported into
Versions of Microsoft Project from 2007 and later deal with costs in a different way to previous versions. If you import a project from Microsoft Project 2007 or from a later version, any cost resources that have been created in the project are imported as consumable resources with a cost of zero.
Resources in Microsoft Project can have up to five cost rate tables, with costs that can change over time: up to twenty-five times in total. A cost and income rate object is created during import for each cost rate table used on a resource, and each allocation is assigned the appropriate cost and income rate. If the cost rates change over time, more cost and income rate objects are created during import, with names that indicate the date at which the rate changes.
If an allocation uses a cost rate that changes midway through the allocation, the allocation is split into two during import and the appropriate cost and income rate is assigned to each resulting part.
Negative costs and income
Powerproject supports positive and negative costs, and positive and negative income. Microsoft Project supports positive and negative costs, but has no concept of income. You specify how negative costs should be handled during the import process. You can choose to convert negative costs in the Microsoft Project file into income, or to leave them as negative costs in the resulting file.
Overtime in Microsoft Project increases the availability per day of an allocation and enables you to adjust the amount of work for a day. If overtime has been reported against an allocation in Microsoft Project, the allocation value of the resource assignment is increased during import to ensure that the task duration and the amount of work on the allocation do not alter. Overtime work is associated with a corresponding calendar exception during import.
If a project in which code library entries have been assigned to tasks and resources has been exported to Microsoft Project, the hierarchy of codes is recreated if the file is imported back into Powerproject as a project in its own right.
As code library appearance data is not exported, a set of pre-defined appearances is assigned to the imported codes. These may not match the appearances of the codes prior to the original export to Microsoft Project.
Work breakdown structure
If a project in which a work breakdown structure has been defined has been exported to Microsoft Project, the work breakdown structure is recreated if the file is imported back into Powerproject.
Creation of Library Explorer objects
If you import an MPP or XML file into a chart or summary group rather than importing it as a project in its own right, a number of Library Explorer objects such as calendars, cost centres, cost and income rates and resources may be created as a result of the import. These are either placed in the root of the relevant Library Explorer hierarchies or in folders that are given the name that you are able to specify during the import.
When importing into a summary group, the default calendar cannot be modified and there is no attempt to match up imported resources or calendars to objects that already exist in the project. The standard calendar from the Microsoft Project project is imported and named "Standard". Any name clashes with existing objects are resolved by renaming the newly imported objects (a number in parentheses is added to their names).
Custom fields and user-defined fields
If you import an MPP or XML file into a chart or summary group rather than importing it as a project in its own right, custom fields from within the project are mapped by name to any user-defined fields in the Powerproject project where possible. If any additional user-defined fields need to be created within the Powerproject project to store custom field information, a dialog appears to inform you whether or not this is possible; if it is possible, you are given the choice of continuing with the user-defined field creation, importing the project without creating the additional user-defined fields and cancelling the import altogether.