What is a project merge?
Merging combines a source project into a target project. After the merge, the source project is permanently deleted and most of its data moves over to the target. Some records are intentionally left behind — see the deletion list below.
This action cannot be undone. Use it when two projects represent the same work and you want a single canonical record going forward.
What moves to the target
Listed in order of how often it matters in practice; the top five are the records most teams worry about first.
Tasks. Every task on the source project — including descriptions, dates, assignments, comments, dependencies, and external links — is moved to the target.
Milestones and phases. All milestones on the source move to the target, along with their phases.
Team members and roles. Project Users on the source are added to the target with their existing roles.
Companies (client and third-party). The source's client and third-party companies come over to the target.
Time entries. All time-tracking records on the source — billable, non-billable, with and without notes — are reassigned to the target.
Also moves to the target
Attachments. Every file or link attached to the source becomes an attachment on the target.
Risk register. Individual risks the team tracked on the source — title, severity, mitigation notes — all move to the target.
Activity log. The source's history of changes (status updates, task completions, etc.) is preserved on the target. A new "Project merged" entry is added showing when the merge happened and what the source project was called.
Forms and responses. Project forms attached to the source, including share links and submitted responses, are migrated.
Applied templates. If the source had any templates applied to it, those template applications are recorded against the target.
Favorites. Anyone who had favorited the source now has the target favorited.
Holidays. Project-specific holidays move to the target.
Billing rates. Any project-level billing rate overrides come along.
Conflict handling
A few records need extra rules when the source and target overlap. You can skip this section if you're confident the two projects don't have conflicting setups.
Team members already on both projects. If a user is on both projects, the target's role for that user is kept; the source's role is discarded. The user doesn't gain or lose access on the target.
Two PMs or two Champions. A project can only have one Vendor PM and one Client Champion. If the source has a Vendor PM and the target already has one, the source's PM is added to the target as a Vendor Contributor instead. The same rule applies to Client Champions, who become Client Contributors. The target's PM/Champion is never changed.
Two clients. If both source and target have a client company and they're different, the target's client is preserved and the source's client is added to the target as a third-party company. If the target had already listed the source's client as a third-party, no duplicate is created.
Same company on both projects. If the source and target both list the same company (in any role), only the target's row is kept.
Phases shared between the projects. If both projects have a phase with the same name (e.g., both have a "Discovery" phase), the source's milestones in that phase are slotted into the target's existing phase rather than creating a duplicate phase on the target.
Two Statement of Work files. A project can only have one designated SOW. If both source and target have an SOW file, the target's SOW is preserved and the source's SOW becomes a regular attachment on the target.
Same template applied to both projects. Template application stats aren't double-counted. If both projects had the same template applied, the target shows the template as applied once.
Same-day holidays. Project holidays are de-duplicated by their start and end dates only — names are not considered. If both projects have a holiday with the exact same start/end dates, the target's holiday is kept (even if it's named differently from the source's).
Favorited by the same user. If a user had favorited both source and target, only the target favorite remains after the merge.
What's permanently deleted
These records are tied to the source project specifically and don't transfer. The target's equivalent records are untouched.
Project notes. The narrative notes content on the source project. The target keeps its own notes.
Baselines. Saved baseline snapshots on the source — both the project-level baseline and per-task baselines — are deleted. The target keeps its own baselines.
Custom field values. Any custom field values entered on the source project are not migrated to the target.
Status history. The chronological log of status changes (Planning → Doing → Paused, etc.) on the source. The target's status log is unchanged; the merge does not write a status entry on it.
Project settings. Per-project setting overrides on the source (notifications, integrations, dependency dateshift rules, etc.). The target's settings are unchanged.
Also deleted
Project health log. Past red/yellow/green health entries logged against the source.
Welcome message. The Welcome message text shown to invitees on the source project.
Summary share links. Any externally-shared "project summary" URLs created from the source.
Time-to-value tracking. TTV records on the source. (This is the project-level metric, not individual time entries — those move with the merge.)
Risk score history. The aggregated/historical project-risk score computed from the source's risk register. The risk register entries themselves move to the target, and the target's score will recalculate after the merge.
Integration sync state. Sync logs and state from Hubspot, Salesforce, and other integrations that referred specifically to the source project.