Tips on avoiding potential conflicts when restoring data

On rare occasions, it is possible for conflicts to arise when restoring previously-archived data. Conflicts can occur if you archive data from a project, recreate items in the project that have the same ID as the archived items - or that share some other value that must be unique within a project - and then attempt to restore the previously-archived data. If a conflict of this type occurs during a restore, you are notified of the conflict.

To avoid conflicts of this type:

Do not assign work breakdown numbers or unique task IDs that were assigned to items that have been archived to items that are added subsequently to a project. If you were to do this, then attempted to restore the archived items, the duplicate work breakdown numbers or unique task IDs would cause conflicts during the restore procedure.
Do not delete time units that were related to items that have been archived, then recreate similar time units – using the same abbreviation or compact abbreviation – in a project . If you were to do this, then attempted to restore the archived items, the duplicate time units would cause conflicts during the restore procedure.
Do not delete users that were related to items that have been archived, then recreate similar users – using the same user name – in a project. If you were to do this, then attempted to restore the archived items, the duplicate users would cause conflicts during the restore procedure.
Do not delete embedded borders that were related to items that have been archived, then recreate similar borders – using the same name – in a project. If you were to do this, then attempted to restore the archived items, the duplicate embedded borders would cause conflicts during the restore procedure.

Conflicts can also arise on rare occasions when restoring data if the structure of a project differs from its corresponding baselines greatly, or if bars, tasks and allocations are moved from one branch of a project to another after the project has been baselined. Again, if a conflict of this type occurs during a restore, you are notified of the conflict.

More details of this type of conflict and how they can arise

Consider a scenario in which a project - Project A - has two baselines - Baseline 1 and Baseline 2. Baseline 1 and Baseline 2 both contain a task - Task 1 - that does not exist in Project A, because it has been deleted after the project was baselined. In this scenario, the structure of Project A was changed substantially after Baseline 1 was created, and before Baseline 2 was created. The structure of Baseline 1 is therefore very different to that of Baseline 2.

When data is archived from Project A, the difference in the structure of the two baselines means that Task 1 is archived from Baseline 1, but not from Baseline 2.

If Project A is then reverted to the state it was in when Baseline 2 was created, Task 1 is brought back into Project A from Baseline 1.

This could cause a conflict if Project A was subsequently merged into Baseline 1: Task 1 would be added to Baseline 1, even though Task 1 has been archived from Baseline 1. If this happened, and data was subsequently restored into Baseline 1, the restore would attempt to restore Task 1 into the baseline but would not be able to, as the task already exists in the baseline. In this situation, a conflict would be reported during the restore process and Task 1 would not be restored from the archive into Baseline 1; the version of Task 1 that exists in the baseline would be maintained.

A further conflict could occur if the following steps were carried out:

Data from Project A was subsequently archived into a new archive, thereby removing Task 1 from both the main project and from Baseline 2.
The original archive was restored into Project A, restoring Task 1 back into Baseline 2.
Part of Project A was reverted to the state it was in when Baseline 2 was created, thereby re-adding Task 1 to Project A.

In this situation, Task 1 exists in Project A, but Task 1 is listed as having been archived from Project A. This could cause a conflict if the data in the second archive was restored into Project A. In this situation, a conflict would be reported during the restore process and Task 1 would not be restored from the archive into Project A; the version of Task 1 that exists in the project would be maintained.

As you can see, the circumstances that are required for such a conflict to occur are comparatively rare.

To avoid conflicts of this type:

Try to keep the structure of a project and its associated baselines as similar as possible.
If you have baselined a project and you want to subsequently move bars, tasks or allocations from one branch of the project to another, cut and paste the bars, tasks or allocations rather than moving them by dragging them in the bar chart.
Revert to baselines as seldom as possible, especially in situations where you have deleted data from a project that was previously incorporated into an archive of a different baseline.