Alexandria logo Alexandria

Switching from Tana

What maps well

Tana is built around nodes, supertags, and fields. In Alexandria, the closest mapping is:

Alexandria tag properties support boolean, select, multi-select, date, number, money, and string. Tana fields that behave like status, dates, numbers, checkboxes, or text usually map cleanly. Reference-heavy or relation-like fields do not have a direct Alexandria property type today; preserve those as note text or Markdown links during conversion.

Current path

Not yet supported. There is no automated Tana importer yet - this is a manual process today.

Alexandria's automated import path is currently focused on Notion; see Imports. Tana can export data as JSON or Markdown, but Alexandria does not yet read those exports directly.

A realistic workflow today:

  1. Export from Tana as Markdown for readable note bodies, or JSON if you need more structure for a custom conversion.
  2. Decide which Tana nodes should become standalone Alexandria notes.
  3. Decide which supertags should become Alexandria tags with properties.
  4. Convert each selected node into Markdown content.
  5. Recreate tags and supported properties in Alexandria.
  6. Review links, references, nested nodes, and field values by hand.

For a small Tana workspace, manual cleanup may be faster than scripting. For a large workspace, test a conversion on a small export first and keep unsupported Tana structures visible in the note body rather than silently dropping them.

What to expect

Tana's graph-like structure is richer than Alexandria's current importer support. The cleanest migration usually keeps important writing as Markdown notes, keeps supertags as tags, and preserves complex references as readable text until Alexandria has a dedicated Tana importer.