October 22, 2026
Migrating Logseq journals: keep, archive, or fold into projects
Most people leaving Logseq should not migrate their journals as journals. Keep the journal folder as a read-only archive, pull the few entries that belong to a live project into that project, and carry forward only the open tasks. A five-year stack of daily pages pasted into a new tool loses the things that made it useful in Logseq, and it buries the work you actually came to do.
This guide covers the part our Logseq migration guide deliberately left out. If you haven’t decided whether to leave yet, start with Leaving Logseq? A calm guide to your options.
Why journals are the hard part
A Logseq page is about one thing, so it moves as a unit. A journal page is about one day, and a day touches everything: a meeting note for one client, a book quote, a half-formed idea, three tasks for three different projects.
In Logseq that works because of linked references. You write [[Project X]] in Tuesday’s journal, and Tuesday’s block shows up at the bottom of the Project X page. The journal is the inbox and the backlinks are the filing system. Export the files and you keep the inbox but lose the filing: every [[link]] becomes plain text, and nothing gathers the blocks back onto their pages.
So the question isn’t how to move your journals. It’s which of the three jobs each journal block was doing.
The three piles
Every block in a journal falls into one of these:
- Record. What happened, what you thought, what you read. Valuable as history, rarely reopened. Most journal content is this.
- Project material. Notes, decisions, and links that belong to something you’re still working on. In Logseq these reached their project through a
[[link]]. - Open loops. Tasks still marked
TODO,LATER,NOW, orDOING, and anything you meant to come back to.
Each pile gets a different treatment.
Pile 1: keep the record where it is
A file-based Logseq graph keeps journals as one Markdown file per day in the journals folder. The default filename is the date in yyyy_MM_dd form, so 2024_05_01.md is May 1, 2024. Those files are plain text. They will open in any editor in twenty years.
That makes the archive decision cheap:
- Copy the whole graph folder somewhere you back up, and leave it alone.
- Keep Logseq installed if you like reading the journals with their links rendered. Opening an old graph doesn’t commit you to working in it.
- If you also need full-text search across the archive without Logseq, any editor that searches a folder will do it.
Leaving the record behind is the step people resist most, and it’s usually the right call. You don’t lose it. You stop paying to carry it around in your daily tool.
Pile 2: fold project material into its project
For each project you’re bringing over, find its journal blocks. In Logseq, open the project’s page and read its Linked References section. That list is exactly the material scattered across your journals. On the file system, searching the journals folder for [[Project X]] finds the same blocks.
Then copy them into the project’s own page before you export it, under a heading like “Notes from the journal”, oldest first. Keep the date at the start of each block (2024-05-01: decided to drop the second vendor) so the history still reads in order.
This is the step that rebuilds what backlinks gave you. In an outliner like listlis, the project becomes one branch that holds its plan, its tasks, and its history together, and you no longer need a link to find the context. Do it one project at a time, starting with the one you’ll work on this week.
If a project has hundreds of journal references, that’s a signal it deserves a proper history section rather than a pasted log. Summarize each month in a line or two and leave the raw blocks in the archive.
Pile 3: carry forward the open loops
Search the journals folder for TODO, LATER, NOW, and DOING. Each hit is a task you never closed. Go through them once:
- Still real: move it to the project it belongs to, or to an inbox if it has no home.
- Dead: leave it in the archive. A two-year-old
LATERis a decision you already made.
Expect most of them to be dead. That’s normal, and clearing them is one of the quieter benefits of moving.
In listlis, imported TODO markers stay as plain text in the title. Mark the ones you keep as todos (!) and give the time-sensitive ones a due date, so they show up in the built-in This week list and any saved views you rebuild. If you used NOW or DOING as a working set, a #doing tag and a smart list on that tag replaces it.
If you want the journals inside the new tool anyway
Some people really do reread their journals: writers, researchers, anyone who uses a daily log as source material. If that’s you, import them, but give them their own branch so they don’t crowd your projects.
In listlis, the import panel takes several Markdown files at once, and by default puts them all under one new top-level section. Each file becomes one node under it, with the day’s bullets nested beneath. A few things to know before you do it:
- Confirm your email first. One import takes up to 2,000 nodes, so a large journal set goes in a year or a quarter at a time.
[[links]],((block refs)), and{{queries}}arrive as plain text. They’re readable, but nothing resolves them.- Images and attachments are not part of the Markdown files, so they don’t come across.
- Because each import lands under its own section, deleting that section undoes it, and Trash keeps it for 30 days.
A Journal branch with one child per year, and the imported days under each, keeps the archive browsable without touching the rest of your tree. Search (/) then finds a phrase across years of entries. The import page lists exactly what transfers.
What about a database graph?
On Logseq’s database version, journals live in SQLite rather than in a journals folder. Use Markdown Mirror or the app’s Markdown export to get files out first, then apply the same three piles. Our Logseq OG vs database guide explains the difference between the two versions.
Do you still need a daily journal?
Worth asking before you rebuild the habit. A Logseq journal does two jobs: a place to write something down fast without choosing where it goes, and a log of what happened.
In an outliner, the first job goes to an inbox. Capture there, then file items into projects once a day. The second job is optional. If you want a log, a dated node under a Journal branch works. If you never reread it, skip it, and let completed items in each project serve as the record.
A one-afternoon plan
- Copy the graph folder to your backup and leave the original untouched.
- Pick the one project you’ll work on this week. Copy its linked references from the journals into its page.
- Search the journals for open task markers that belong to that project, and keep the live ones.
- Export and import that one page. Use it for a week.
- Repeat for the next project. Leave everything else in the archive until you have a reason to open it.
If the first project feels at home after a week, the rest follow the same way. Open listlis and start with that one project.