Preview environment — data may be reset without notice. Do not use for real work.

Backup

Import & export

The project ZIP is a single-file backup you can re-import into any workspace you own. The plan and the conversation come along; some workspace-specific bits do not. Here's the line between the two.

When to use it

  • Backup before a big change — fork a copy, try a destructive replan, restore the ZIP if it goes sideways.
  • Moving a project between workspaces — for example, exporting from a client's workspace into your own.
  • Handing a snapshot to someone outside MadiPlan — the ZIP opens in any MadiPlan account, no shared workspace required.

Exporting

Open the project's Actions menu and pick "Export project (ZIP)". The download bundles tasks, phases, subtasks, dependencies, comments, progress notes, attachments and the project's key dates into one archive.

There's a second option — "Export project (ZIP, redacted emails)" — that replaces every email address inside the archive with an opaque hash. Use it when the recipient should not see your members' addresses (a client handover, a public sample). The trade-off: a redacted ZIP can still be re-imported, but every comment, note and assignee will fall back to the person doing the import. See "Redacted exports" below.

What carries over

  • Tasks, phases and subtasks — names, dates, progress, milestone flag, priority, color, description, constraint type.
  • Dependencies between tasks (FS / SS / FF / SF and any lag) — relinked to the new task IDs on import, so chains keep working.
  • Comments and progress notes, including @-mentions inside their text.
  • Attachments — re-uploaded into the destination project's storage. The download URLs in the new project will be fresh.
  • Project key dates (kickoff / workshop markers, multi-day events).

What gets remapped

Two pieces of data need to be reconnected to the destination workspace because the original IDs don't exist there. We match by the human-readable label, not by ID, and warn you if we can't find a match.

  • Assignees — matched by email against the destination workspace's members. A match is reassigned; a miss is left unassigned and listed in the import warnings so you can fix it by hand.
  • Comment and progress-note authors — also matched by email. If the original author isn't a member of the destination workspace, the comment is preserved verbatim but attributed to you (the importer). The original author's email is not stored.
  • Statuses — matched by status name. If the destination project uses a different template (different status names), unmatched statuses fall back to the project's default. Set up matching status names before importing if this matters.

What does NOT travel with the ZIP

These belong to the workspace, not the project, and a fresh import starts from a blank slate for each. Re-create whatever you need on the destination side.

  • Activity history / audit log — the new project starts a fresh timeline; the old one isn't merged in.
  • Project member list and roles — who has lead / editor / viewer access is decided by the destination workspace's invitations, not the ZIP.
  • Per-project guest invitations — guest seats are tied to the originating workspace and need to be re-issued.
  • Stakeholder list (the public-facing names visible on a share link).
  • Baselines — frozen plan snapshots stay with the original project and are not re-created on import.
  • Saved views and per-user filter saves.
  • Cross-project references — phases pinned in from other projects need to be re-pinned on the destination side. Phases this project exposes to others are also detached.
  • Sharing settings — public / private toggles and existing share links are project-scoped to the original. The new project starts as private; re-enable sharing if needed.
  • Slack DM bindings — those connect each member's MadiPlan account to their Slack identity in one workspace, and do not transfer.

Append vs Replace

When you open a ZIP into an existing project, the import dialog asks for a mode. Picking the right one matters more than usual because Replace is destructive.

  • Append — adds the ZIP's content on top of whatever is already there. Existing tasks, comments and attachments stay; new ones are inserted alongside. Use this to merge a backup back into a project you've been editing, or to migrate in chunks.
  • Replace — wipes the destination project's tasks, dependencies, comments, progress notes and attachments first, then imports the ZIP into the empty shell. Use this for a clean restore. There is no undo.

Redacted exports

The "redacted emails" export is for sharing the project outside your workspace without leaking member identities. Every email in the archive — assignees, comment authors, note authors — is replaced with a hash. The archive still imports cleanly into any MadiPlan account.

What you lose: on re-import, every email-keyed remap (assignees, comment authors, note authors) fails to match, and everything collapses onto the importer. Treat a redacted ZIP as a one-way artifact — fine to read, lossy to round-trip.

Smoother cross-workspace moves

Invite the people who own the most comments and assignments into the destination workspace before importing — they'll be re-matched by email and keep their authorship. Anyone added later cannot be back-stitched to historical comments.

If your destination uses a different template, give the new project the same status names as the source before importing — that makes the status remap a no-op instead of falling back to defaults.

Quick reference

  • Comes along — tasks, dates, dependencies, comments, notes, attachments, key dates.
  • Re-matched by email — assignees and comment/note authors. Misses warn or fall back to the importer.
  • Does not travel — activity history, member roles, guests, baselines, saved views, cross-project refs, sharing, Slack bindings.
  • Replace mode — wipes the destination project first. No undo.