Migrate your Nozbe data

Projects are the top-level container in Nozbe's hierarchy. They support visibility controls (team-wide vs. limited access to specific members), project groups, and completion status. We map Projects 1:1 to the destination Project object and preserve visibility settings as project-level permissions.

Tasks are the core work unit in Nozbe. They carry due dates, recurrence rules, priority levels, assignees, and a Done/undone state. We map Tasks to the destination's Task or To-Do object and preserve Priority, Due Date, and Recurrence as native fields. Assignee mapping requires a user cross-reference table since user IDs differ between systems.

Comments are threaded under Tasks as the primary communication mechanism in Nozbe's task-based model. We preserve the full comment history under each Task, including author, timestamp, and @mentions. Mentions do not transfer as live links to the destination unless the destination supports an equivalent mentions system.

Nozbe supports Tags for labelling tasks across projects. Tags are a flat list per workspace. We map Tags to the destination's Label or Tag system, but since Nozbe Tags have no hierarchy, nested label structures in the destination must be flattened or manually reorganised after migration.

Categories are part of Nozbe's GTD implementation and allow grouping tasks by context type (e.g., @calls, @home). They are distinct from Tags and appear in the left sidebar. We map Categories to Tags in the destination since most PM tools do not have a separate Categories concept, and we note this remapping in the scope document.

Files attached to Tasks are supported. We transfer attachment URLs and re-attach them where the destination supports file linking. Nozbe Classic export includes attachments; new Nozbe integrations with OneDrive and Dropbox mean some files may be stored externally — we preserve links but cannot guarantee the destination can open them without authentication.

Tasks support recurring patterns (daily, weekly, monthly, custom). Recurrence rules are stored per task. We translate Nozbe recurrence patterns to the destination's native recurrence format where supported, or convert to a series of individual dated tasks where the destination lacks recurrence.

Nozbe's Inbox is a GTD capture zone for unsorted tasks and does not exist as a distinct persistent object in most destination PM tools. We do not migrate Inbox items as Inbox items — we migrate them as Tasks in the destination's default task list and flag this in the scope document.

Team Members are users in a Nozbe workspace. They have roles (admin, member) and can be assigned as task owners. We map Members to Users in the destination, but email addresses and profile information must be confirmed during the scoping call since Nozbe's user export is limited.

Business Spaces are an enterprise organisational unit in new Nozbe, separate from Projects. They allow grouping of multiple teams. We map Business Spaces to the destination's Workspace or Organisation concept, but since many PM tools do not have a two-level organisational structure, Spaces may need to be represented as Projects or Tags.

Nozbe does not expose a Custom Fields feature in its public data model. Tasks carry only standard attributes (due date, priority, recurrence, assignee). We flag that any destination custom field definitions cannot be pre-populated from Nozbe and must be created manually in the destination.

Nozbe has no built-in time tracking or time entry logging. While some users track time informally in task comments, there is no structured time entry object to migrate. We do not migrate time tracking data from Nozbe.