Migrating From Roam Research to VaultBook: A Private, Offline Home for a Six-Year Research Graph

The graph would not load in any useful way on a Tuesday morning, and that, more than any announcement or price change or feature debate, is what ended six years of loyalty.

She was not trying to do anything exotic. She was an independent research consultant now, a former doctoral researcher who had carried the same thinking system out of the university and into client work, and all she wanted before a nine o’clock call was three things she knew were in there: a literature note from her second year of doctoral work on how a particular interview method had been adapted in field studies, the project page for a client whose work she could not discuss with anyone else, and the daily note from the previous Thursday, where she had pasted her own half-formed questions in the ten minutes after a call ended. Three retrievals. The kind of retrieval a personal knowledge system exists to make trivial. Instead she watched the graph wake up slowly, watched the sidebar populate, watched a page render in pieces, and found herself doing the small, humiliating arithmetic every long-time user of a hosted tool eventually learns to do: is it faster to wait, to reload, to search again, or to give up and reconstruct the thought from memory and from the paper notebook on the desk that was supposed to be the backup, not the primary system?

She reconstructed it from memory. The call went fine. Clients rarely know when you are improvising around your own archive. But she sat afterwards with a feeling that was not really about one slow morning. A slow morning can happen to any software. What stayed with her was the realisation of how many separate permissions she needed from the world in order to think her own thoughts in order: a working connection, a working service, a working account session, a browser behaving itself, and a graph large enough, after six years, that the hosted application now treated its size as a problem she had created. She had built exactly what the tool had invited her to build — a dense, interlinked, daily record of reading, interviewing, drafting and deciding — and the reward for building it faithfully was that opening it had become a negotiation.

The second scene came a few weeks later, and it was quieter. She was visiting an archive, the kind of reading room where connectivity is not a promise but a favour: thick walls, a polite sign about the reading room network, laptops allowed, phones away, and a connection that dropped whenever too many researchers arrived after lunch. She had planned the visit properly. She had a list of documents to request, a set of questions drawn from her literature notes, and a page in her graph where she intended to write the day’s findings alongside the references they would eventually support. The documents arrived in their grey boxes. Her graph, for long stretches, did not. She could get fragments when the network steadied. She could not trust it. So she did what researchers did before any of these tools existed, and what she had privately told herself she would never have to do again: she wrote the day in a plain document on the laptop, with a private promise to copy it into the graph that evening, link it properly, tag the people and projects, and attach the photographs of the catalogue cards.

That evening she did copy it in. It took forty minutes she did not begrudge the material, only the duplication. The deeper irritation was conceptual. The notes from the archive were hers. The photographs were on her own machine. The questions had been written by her, in a room with no useful internet, about paper documents that predated the internet by a century. Nothing in that chain required a server on another continent to mediate it — except the design of the tool she had chosen. An offline gap is a minor inconvenience for a shopping list. For a researcher whose best work happens in archives, on trains, in interview rooms in unfamiliar towns, in the basement stacks of libraries and in client offices with guest networks that block half the web, an offline gap is a structural mismatch between the tool and the life.

The third scene is the one she did not tell other people about at first, because it felt disloyal to a tool she had recommended for years. A client interview — sensitive, not secret in any legal sense, but confidential in the ordinary professional sense that matters: a senior manager describing, candidly, why a programme had failed, what had been hidden from a board, and what she would not say in a written report. The consultant’s job in that hour is to listen well and to write down, later, the things that must not be lost and must not be shared. She opened a new page in her graph, as she had done hundreds of times, and then she hesitated with her fingers over the keyboard. Not because she believed anyone in particular was reading. Hesitation does not need a villain. She hesitated because she understood, suddenly and completely, the custody arrangement she had accepted by default: these words, typed here, would live on someone else’s computers, under someone else’s terms, retrievable through an account protected by a password and a recovery email, for as long as the service chose to keep operating in its present form. For her doctoral notes, that arrangement had felt like convenience. For her reading notes, it had felt like nothing at all. For another person’s candour, entrusted to her in a closed room, it felt like a decision she should have made deliberately and never had.

She wrote the interview up that night in a local document, encrypted the file with a tool she barely understood, and told herself she would decide later where it belonged. Later kept not arriving. Over the following months her knowledge quietly split in two: the graph, rich and linked and searchable and increasingly slow, holding the public and the academic and the merely private; and a scattering of local documents holding the things that mattered most, unlinked, unsearchable as a body, and safe in the narrow sense that they had never left her machine. A split archive is worse than either of its halves. The linked half did not know what the local half contained. The local half could not benefit from six years of context. She would search the graph for a project, find the anodyne meeting notes, and have to remember — by memory, again, that unreliable retrieval system — that the real record was in a folder with a date for a name.

That is the honest starting point for this migration. Not anger. Not a hunt for a shinier application. She still believed, and believes now, that the tool she was leaving had taught her how to think in public with her past self: daily notes as the intake valve, pages that grow by accretion, links made at the speed of typing. The migration described in the rest of this article is not a repudiation of that method. It is an attempt to keep the method and change the custody. To move a six-year research graph — daily notes, literature notes, confidential client interview notes, project pages, and a small library of PDFs and images that the old graph mostly pointed at rather than held — into VaultBook: a single-file HTML application that runs locally, makes zero network requests, and stores her work in entries she can organise with labels and a wiki, protect entry by entry with AES-256-GCM encryption, revise with version history behind her, and search in full, including text recovered from scanned pages. The move is not frictionless, and this article will not pretend otherwise. Block-level transclusion, the old graph’s party trick, has no exact equivalent anywhere else, and she had to learn substitutes rather than equivalents. But the morning the graph would not load, the afternoon in the archive, and the evening she hesitated over a client’s words all pointed the same way. She did not need a bigger hosted room for her thinking. She needed her thinking back in her own house.

Why Roam Users Start Looking for an Exit

Spend any length of time reading what long-term Roam Research users say to each other in public forums — not launch announcements, not influencer threads, but the tired, practical conversations of people comparing notes after years of daily use — and a pattern emerges that is more interesting than any single complaint. Very few of them describe a tool they hate. Most describe a tool they built their working lives inside, which slowly developed a set of frictions that all point in the same direction: the graph got bigger, the work got more serious, and the assumptions of a hosted, block-based, always-online system stopped matching either. The themes below recur, in different words, across those discussions. They are paraphrased here as themes, because it is the recurrence that matters, not any one person’s phrasing.

The first theme is size, and the peculiar guilt that comes with it. Users describe graphs that began as nimble notebooks and became, over four, five, six years, dense accumulations of daily notes, meeting records, reading notes and project histories — and describe, alongside that growth, a creeping slowness: cold loads that take long enough to break a train of thought, pages with many references that render reluctantly, searches that return results a beat or two after the question has moved on. What stings in these accounts is rarely raw speed. It is the inversion of the promise. A knowledge system is supposed to reward accumulation; every note you add is supposed to make the next note more valuable. When users start apologising for the size of their own graph, pruning pages they would rather keep, or splitting work across a second graph to keep the first one responsive, the reward structure has quietly reversed. The archive has started taxing the archivist. Consultants and researchers feel this first, because their graphs do not stay in one domain: a doctoral graph that becomes a professional graph carries methods literature, teaching notes, client projects, grant drafts and personal planning in one linked mass, and there is no natural point at which to declare it finished and start again.

The second theme is export, and specifically the gap between what an export contains and what the living graph feels like. Roam’s structure is built from blocks, and much of its power lives in relationships between blocks: a block written once, on the page where it belongs, can be referenced or embedded on other pages, so that a definition, a quotation or a decision appears in every context that needs it while existing in only one place. Users contemplating an exit describe discovering, sometimes late, that a Markdown export does not carry that relational richness with it. What arrives in the exported files is a flattened rendering: pages as documents, indentation as structure, and the references and embeds resolved into text, markers or approximations rather than preserved as live relationships. For a casual notebook that loss is cosmetic. For a research graph it is the difference between an archive and a photograph of an archive. The words survive. The wiring — which claim rests on which quotation, which project page drew on which literature note, which decision was revised where — survives only partially, and anyone planning a migration has to budget real time for understanding exactly which parts of their graph are prose, which are structure, and which are relationships that will need to be rebuilt by hand in the new home.

Closely related is the third theme: attachments that were never really in the graph at all. Over six years, a researcher pastes hundreds of images into pages — photographs of whiteboards and archive documents, screenshots of tables, figures from papers — and links or uploads PDFs of articles, reports and transcripts. In a hosted graph those files typically live remotely, and the page holds a reference to them. Forum discussions return again and again to the anxiety this creates at exit time, and to the smaller, earlier version of the same anxiety: a link that worked for two years and then did not, an image that fails to render in an old note, a PDF whose location changed when an account, a bucket or a service policy changed. Dead links are a familiar nuisance on the public web. Inside a private research archive they are something worse, because the surrounding note often assumes the attachment: “see the table below,” “the annotated copy is the one that matters,” “her exact wording in the margin.” When the remote object disappears, the note does not announce the loss. It just becomes quietly less true. Users who have found a few dead attachments in old pages describe the same response: an urge to go and fetch everything, hold it locally, and never again let the substance of the archive depend on the continued goodwill of a URL.

The fourth theme is offline access, or rather its absence as a lived experience rather than a feature-list line. Researchers, journalists, consultants and fieldworkers describe the same geography of failure: archive reading rooms, trains through cuttings and tunnels, flights, rural fieldwork, hospital and client sites with restrictive networks, conferences where the Wi-Fi collapses under load — and, more banally, home internet outages on the morning of a deadline. The complaint is seldom that offline access is imperfect. It is that a hosted graph treats connectivity as a precondition for memory itself. A tool you can only consult when the network cooperates is a tool you learn, subtly, not to rely on at the moments of highest value: the question that arises mid-interview, the reference needed mid-draft in a cottage with no signal, the daily note you want to open on a plane to reconstruct what you promised whom. People adapt — they export read-only copies, they keep parallel local notes, they screenshot key pages before travelling — and each adaptation is another small split in the archive, another place where the real record and the official record diverge.

Fifth, there is the sprawl that daily notes generate when they are both a capture habit and a linking habit. The daily-notes page is a generous idea: open today’s page, write, link out to the pages your thoughts touch. But every mistyped link, every hastily invented page name, every slight variation — a project with and without its acronym, a person’s name spelled two ways, a topic in singular one month and plural the next — creates a new, empty or near-empty page, and over six years those accidents accumulate into a long tail of stubs. Users describe opening the all-pages list and feeling a low-level shame at the debris: pages that contain one line, pages that contain nothing, pages that were meant to be one page and became three. The sprawl is not merely untidy. It degrades search, because the real page competes with its accidental twins. It degrades linking, because the autocomplete offers the wrong twin first. And it makes migration harder, because an honest export includes the debris, and someone — or some careful process — has to decide, page by page, what was a thought and what was a typo. New users are often told the graph will organise itself. Six-year users know the graph organises itself the way a desk does: faithfully recording every habit, including the bad ones.

The sixth theme is the learning curve that never quite stops charging rent. Block-based outlining, queries, the syntax for pulling together every block that mentions a project and a status and a date — these are genuinely powerful, and the users discussing them are often the ones who mastered them. Their observation is subtler than “it is hard to learn.” It is that the power demands continued fluency. A query written eighteen months ago must still be understood to be trusted. A template built for literature notes embeds decisions its author no longer remembers making. Family members, collaborators and future selves who did not climb the curve cannot easily read the graph at full depth, and even its owner, returning after a month of fieldwork or illness, can find her own system briefly foreign. When the novelty of a powerful system fades — and after six years, novelty has faded — what remains is the daily cost of operating it, weighed against the daily value. For many of the users in these discussions, that weighing, not any single outage or export scare, is what finally opens the question: if I were choosing today, for the work I actually do now, would I choose this shape again?

None of these themes, alone, is a reason to move. Together they describe a recognisable moment: the tool has not failed, but the fit has. The work has become more confidential, more mobile, more dependent on attachments and less dependent on clever queries; the graph has become larger, slower and harder to carry away intact. That is the moment at which a migration article becomes useful — not as a celebration of the destination, but as a careful account of what can be carried, what must be rebuilt, and what will honestly be lost.

What a Migration Must Preserve — and What It Honestly Cannot

A migration plan should begin with an inventory of promises. Not the promises the destination tool makes in its marketing, but the promises your old graph implicitly made to you every day, which you only notice when you imagine them broken. For a six-year research graph, there are six things that must survive the move in recognisable form, and one famous thing that will not survive intact — and an honest article should name the loss early, while you can still decide how to compensate for it, rather than discovering it afterwards.

First, the pages themselves: the prose. Literature notes with their careful summaries and page references, project pages with their decision logs, person pages, concept pages, the long reflective notes that were never meant for anyone else. This is the bulk of the graph by word count and by value, and it is also the most portable part, because prose is prose in any system. In VaultBook terms, pages become entries — discrete, titled, searchable pieces of writing that you can open, revise and keep, with version history preserving earlier states so that a heavy edit during migration is never a one-way door. The discipline this stage demands is not technical but editorial: one old page should become one entry with the same title wherever that is remotely possible, because every title you preserve is a link target, a search habit and a memory cue preserved with it. Renaming during migration feels like tidying. It is actually amnesia, self-inflicted, at scale.

Second, the links. A research graph is not a folder of documents; it is the connections — this claim to that source, this project to that person, this daily note to the meeting it prepared for. The double-bracket links scattered through six years of pages are the graph’s argument about how the work fits together. VaultBook’s wiki gives those connections a home: entries can link to other entries by name, so a literature note can still point to the concept it critiques and a project entry can still gather the people and sources it draws on. Preserving links is painstaking rather than difficult. It means deciding, before you move anything, how link targets will be named in the new system, hunting down the accidental twins created by years of mistyped links, and merging them in the old graph or at the moment of import, so that the new wiki does not inherit three entries for one project. It also means accepting a small, healthy change of habit: where the old system let a link spring into existence mid-sentence whether or not the target deserved to exist, the migration asks you to link deliberately, to entries you intend to keep.

Third, the tags — or, in VaultBook’s vocabulary, the labels. Tags in a mature graph do quiet organisational work that their owner barely notices: they mark status (to read, in progress, sent to client), type (literature, interview, meeting, draft), sensitivity (personal, client-confidential) and domain. Labels carry that work across directly, and in one respect they carry it better, because a migration is the one moment when you can review the whole label set at once. Six years of tagging produces synonyms, near-duplicates and tags that made sense for one project in one spring and were never used again. Consolidating them before the move — deciding the definitive label list, mapping the strays onto it, and writing the list down — turns a chore into the single most valuable piece of housekeeping in the entire migration. After the move, every entry can be filtered and gathered by its labels, and the consultant’s most-used views — everything for this client, everything unread, everything sensitive — become label combinations rather than fragile queries.

Fourth, the daily notes. Chronology is a retrieval system in its own right: very often you do not remember what a thought was called, only roughly when you had it. Six years of daily notes are the graph’s diary and its audit trail — what was promised on which call, what a draft looked like before feedback, when an idea first appeared. They must come across complete and in order, one entry per day, dated and titled consistently, even the thin days, even the embarrassing days that are three lines and a link. Especially those: thin daily notes are often the only bridge between two substantial pages. In VaultBook they become dated entries under a shared label, searchable like everything else, and the habit can continue unchanged — open today’s entry, write, link out. What changes is only the custody of the diary, not its rhythm.

Fifth, the attachments, which this migration treats as first-class cargo rather than as luggage to be collected later. Every PDF the graph pointed at — articles, reports, transcripts, the annotated copies that carry her marginal thinking — needs to be downloaded, named intelligibly, and brought under local control, where VaultBook’s built-in PDF tools let her merge, split and compress files as the work requires, and where the files themselves sit alongside the vault rather than at the far end of a URL. Images get the same treatment: the photographs of archive documents, whiteboards and catalogue cards belong in her own folders, browsable through the Photo and Video Explorer, not embedded from a remote host whose continued service is an assumption. And the audio from interviews, where it exists and consent allows it to be kept, can be transcribed locally with the built-in Whisper transcription rather than sent to a cloud service — for a consultant holding other people’s candour, the difference between transcribing on her own machine and uploading to a stranger’s server is not a feature distinction. It is the whole ethical point.

Sixth, search — the promise underneath all the others. A migrated archive that cannot be searched as a body is a warehouse, not a tool. The requirement is full search across every entry, and, for a researcher, across the scanned and photographed material too: VaultBook’s search includes OCR, so the text inside a photographed catalogue card or a scanned chapter can be found by the words it contains, not only by the filename someone remembered to give it. Test this early, on real material, before the bulk of the move. An archive you trust is an archive whose search you have watched succeed on a hard case.

And now the honest loss. Block-level transclusion — writing a block once and having it appear, live, inside other pages, so that editing the original updates every appearance — has no exact equivalent in VaultBook, and no amount of enthusiasm should be allowed to blur that sentence. If your graph leans heavily on transcluded blocks, some of what you built was not content but machinery, and machinery does not migrate. What VaultBook offers instead are substitutes, and they are worth describing precisely because substitutes, chosen consciously, can cover most of the real need. Long entries can be organised into clearly headed sections, so the material a transclusion would have gathered can live in one well-structured entry and be read in place. Related notes can be surfaced deliberately — entries connected by wiki links and shared labels, gathered when you need the constellation rather than embedded automatically. The wiki itself carries the navigational half of transclusion’s value: the reader — usually your future self — can move from a project entry to the source quotation in one click, even though the quotation is not physically reproduced on the project page. What is lost is the live updating and the single-source elegance. What is kept, if you do the editorial work, is the substance and the path to it. For this consultant, whose transclusions were mostly definitions, standard method descriptions and a handful of favourite quotations, the substitutes were enough, and the exercise of replacing machinery with structure left several entries clearer than the graph had ever made them. Your mileage will depend on your graph — which is exactly why this accounting belongs at the start of a migration, not in a rueful footnote at the end.

Before You Export Anything: The Pre-Migration Audit

The worst migrations begin with an export. The best begin with an audit — a slow, unglamorous inventory of what you actually have, conducted while the old system is still your working system and mistakes are still cheap. Export buttons create a feeling of progress. The audit creates the knowledge that makes progress possible, and for a six-year graph it deserves several sessions of its own, ideally spread over a week of ordinary work, when you can notice things in passing as well as hunt for them deliberately.

Start with the gross inventory, the numbers you probably do not know. How many pages does the graph contain, in total? How many of them are daily notes — six years of near-daily capture suggests well over a thousand — and how many are substantive pages: literature notes, project pages, person and concept pages, templates, administrative pages? How many attachments does the graph reference, broken down into PDFs, images and other files, and how many of those are actually retrievable today? Write these numbers down outside the graph, in the plain document that will become your migration log. They are your baseline. Every later stage — export, conversion, import, verification — will be checked against them, and a migration without a baseline is a migration whose losses are discovered by accident, months later, mid-project.

Next, hunt the orphans and the empties, because six years of daily-notes linking guarantees both. Orphan pages are pages nothing links to: sometimes they are genuinely standalone — a reference list, a private reflection — and sometimes they are accidents, a page created by a mistyped link and then written on under the wrong name while the intended page sat elsewhere. Empty and near-empty pages are their cousins: the stubs created by clicking a link before the page existed, the duplicates with a trailing character’s difference, the project page that was started twice in two months under two titles. The audit’s job is not to delete aggressively. It is to classify. For each orphan or stub, decide: merge into the real page and redirect your own habits, keep as a deliberate standalone, or delete as pure debris. Do this in the old graph, where the backlinks and the context are visible, and keep a written list of every merge, because after the move, when a link fails, that list is how you will know whether it failed by accident or by your own recorded decision. Expect this stage to be oddly emotional. The debris of a knowledge system is a record of hurried days and abandoned intentions, and tidying it is a small act of biography as well as of data hygiene.

Then — and for this consultant, this was the audit’s most important product — make the sensitivity list. Go through the graph with one question only: which pages would I not want on a stranger’s server? Client interview notes head the list, but they are not its whole extent. There will be pages naming individuals in evaluative ways, pages recording negotiations and fees, pages where a client’s internal problems are described in their own words, personal pages interleaved with the professional ones because a single graph invites a single life. Mark every such page, in the migration log, with its title and the reason for its sensitivity. This list drives two later decisions: which entries in VaultBook will be individually encrypted — VaultBook’s per-entry AES-256-GCM encryption exists precisely for this granularity, letting the sensitive minority be locked without locking the whole archive behind one all-or-nothing decision — and which pages should be exported and moved with extra care, perhaps handled in a separate pass from the bulk literature notes. It also forces a question worth asking before any export: is there anything in this graph that should not migrate at all, anything whose retention period has honestly expired? A migration is a rare chance to practise deliberate forgetting under your own control, rather than eventual forgetting under a service’s.

Only now, with the inventory counted, the debris classified and the sensitive pages listed, should backups enter the picture — and they should enter it twice, in two different forms, stored separately. Export the graph’s JSON, which is the most structurally complete record the old system offers: the blocks, the relationships, the closest thing to the graph’s own memory of itself. Export the Markdown as well, which is less complete relationally but more legible — readable by a human, in any editor, decades from now, without any specialised tooling. These two exports protect against different failures, which is why both matter: JSON against the failure of your conversion process, Markdown against the failure of everything else. Store copies in two physically separate places, at least one of them not on the machine you are migrating on, and verify the exports before trusting them: open the Markdown files and read a few, check the JSON is complete and parseable, confirm the page count in the exports bears a sane relationship to the baseline numbers in your migration log. An unverified backup is a hope, not a backup. Note, too, the attachments inventory from the first stage: neither export should be assumed to contain your PDFs and images in usable form, so the download of attachments is its own line item in the log, with its own count to be reconciled.

One more audit task earns its time here, precisely because it is tedious: sample the graph at random. Pick a dozen pages by chance — an old daily note, a literature note from the doctorate, a project page from a finished engagement — and, for each, check that its links resolve to the pages you expect, its attachments still open, and its content is what its title promises. Random sampling catches the decay that targeted checking misses, because you naturally check the pages you already suspect. If the sample is clean, the bulk of the graph is probably sound and the migration can proceed at pace. If two or three sampled pages show dead attachments or wrong-twin links, that is not bad luck; it is a rate, and you should widen the audit before exporting anything.

Finally, record the state of play and stop. The audit ends with a migration log containing the baseline counts, the merge and deletion list, the sensitivity list, the verified locations of both backups, and the attachment count — and with the old graph still intact and still in daily use. Nothing has been moved. Nothing needs to be rolled back. You have spent a week learning the true shape of six years of your own thinking, and every subsequent step in this migration — the export in earnest, the conversion, the rebuilding of links and labels, the encryption of the sensitive entries, the search tests — will be measured against what the audit found. People skip this stage because it produces no new home to admire. It produces something better: the knowledge of what home has to hold.

The Microsoft 365 Outage of November 12–13, and Why Hosted Notes Are a Borrowed Room

If the argument so far sounds theoretical — custody, connectivity, borrowed infrastructure — the week of this migration supplied a concrete, dated illustration, and it is worth setting down carefully, with its facts kept separate from its lesson.

On Thursday, November 12, 2026, Microsoft 365 began to fail for large numbers of its users. Microsoft first announced issues at 10:40 a.m. ET that day, and what might have been a brief disruption stretched past twenty-four hours. Reporting the following day, on November 13, USA TODAY described web access to OneNote as among the services still impacted, alongside the wider suite that offices depend on for mail, documents and meetings — the full account is at USA TODAY’s coverage of the outage. Microsoft said the outage was not a cyberattack; the cause, on its account, was a network capacity upgrade issue — an ordinary, internal, operational failure, which in a way makes the episode more instructive, not less. No adversary was required. A change made by the provider, inside the provider’s own network, was enough to take the tools away from the people who had built their working days inside them.

Consider what “still impacted” means at the level of one person’s morning. OneNote is, for millions of workers, exactly what a research graph was for the consultant in this article: the place where the meeting notes live, where the project history accumulates, where the half-finished draft of the important document is kept. When web access to it falters for a day and more, the loss is not dramatic — no data bonfire, no ransom note — and that is precisely the point. The loss is a day of reaching for your own notes and finding a loading spinner, an error, a colleague in another region saying it works for them, a status page saying recovery is in progress. Your notes exist. They are safe, probably, in a data centre you will never see. They are simply not available to you, at the time you need them, for reasons entirely outside your control and largely outside your ability even to understand. A borrowed room is still a room. The difficulty is that the landlord can lock it for renovations without asking, and your furniture is inside.

It is important to be fair about scale and intention. Microsoft operates its services for an enormous population, restores them as fast as it can, and communicates through the incident; nothing in this section suggests bad faith, and a local tool is not magically immune to failure — laptops break, disks die, files are corrupted, which is why this migration insists on backups in two forms in two places. The contrast is not between a fallible giant and an infallible alternative. It is between two different distributions of risk. In the hosted model, your access depends on a chain you do not control: the provider’s network, the provider’s change management, your connection, your account’s standing. A failure anywhere in that chain, including a capacity upgrade undertaken for your own eventual benefit, closes the door. In the local model, the chain is short and mostly yours: a file, on your machine, opened by an application that lives in that same local world.

That is the specific sense in which a VaultBook file would have stayed open throughout November 12 and 13. VaultBook is a single-file HTML application that runs locally and makes zero network requests; there is no VaultBook server to be upgraded, no account session to expire mid-incident, no web access to withdraw. Had this consultant’s graph already been migrated, the morning of the outage would have looked like any other morning: open the file, search the literature notes, read the client entry — the encrypted ones unlocking locally, under her own passphrase — and get on with the call. The outage would have been something she read about afterwards, as news about other people’s tools, rather than something she experienced as an interruption of her own memory. Her PDFs would have been on her machine. Her archive-day notes would not have depended on a reading room’s network or on a provider’s recovery timeline. Her interview records would not have been sitting, during those same hours, inside a suite whose availability was being discussed on national news sites.

There is a temptation, after an episode like this, to overclaim — to treat one outage as proof that hosted tools are finished, or that every worker should retreat to local files for everything. Resist it, as this article has tried to resist overclaiming throughout. Hosted suites do things local files cannot: live collaboration on a document with colleagues on three continents, shared calendars, the administrative machinery of large organisations. If your work is that work, the borrowed room is worth borrowing. But notice what the outage clarified about the price. The price of a hosted home for your notes is not only the subscription line in a budget — it is the standing possibility of a morning, or a day, or longer, in which your own accumulated thinking is unreachable for reasons that have nothing to do with you. For notes that are merely convenient, that price is acceptable. For a six-year research graph — the methods, the sources, the client confidences, the diary of a professional life — the consultant at the centre of this article decided it no longer was. She did not reach that decision because Microsoft had a bad two days in November 2026. She reached it on a slow Tuesday, in a quiet archive, and over a keyboard she hesitated to type on. The outage simply showed everyone else, briefly and in public, the shape of the arrangement she had already decided to leave.

Step One: Exporting the Roam Graph Twice — Markdown for Reading, JSON for Safety

A six-year Roam Research graph is not a folder of documents. It is a web of daily notes, literature pages, project pages, meeting fragments, half-finished outlines, and confidential client material that only makes sense because the links hold it together. That is exactly why a migration should never begin with a single export and a hopeful drag-and-drop. If you export once, in one format, and something is missing, you discover the loss weeks later, after you have already changed your habits, cancelled your routine, or stopped opening the old graph. By then the missing page is not just an inconvenience. For an independent research consultant, a missing interview summary or a broken literature note can mean re-reading a source, re-contacting a client, or admitting that a deliverable rests on a note you can no longer find. The safe approach is slower at the start and much faster overall: export twice, for two different purposes, and verify both exports before you move anything.

The first export is Markdown, and its purpose is reading. In Roam, use Export All and choose the Markdown option. What you receive is a zip containing one Markdown file per page. Open that zip immediately, on your own machine, and look inside. You should see filenames that match the page titles you recognise: your project pages, your author pages, your topic pages, and a long run of daily notes pages with their familiar date titles. This export is the human-readable copy. A consultant can open any file in a plain text editor, years from now, with no Roam account and no special software, and still read the words. Bullets become lines, indentation survives in a recognisable form, and the text of your thinking — the literature summaries, the interview write-ups, the evolving arguments — is present as text rather than locked inside a proprietary database view. That readability is the point. Markdown is not a perfect replica of the graph, but it is an honest, portable transcript of what the graph said.

The second export is JSON, and its purpose is safety. Run Export All again and choose JSON. This file is not meant to be read cover to cover. It is a blueprint of the graph itself: pages, blocks, block order, parent and child relationships, references, and the identifiers that let software reconstruct how one block pointed at another. Where Markdown flattens, JSON preserves structure. Where Markdown tells you what a page said, JSON tells you how the graph was assembled. Keep it even if you never import it directly, even if your move into VaultBook is largely manual and curated. Keep it because it is the only export that can answer forensic questions later. If, three months into the new vault, you wonder whether a block reference pointed at a definition or at an example, or whether a page you half-remember ever existed, the JSON can settle the question. If a future tool — including VaultBook’s own import helpers or a script you write yourself — needs the original structure, the JSON is the source it will need. Deleting it to save a few megabytes is a false economy for someone whose livelihood is research.

Treat the two exports as a pair and store them as a pair. Create a migration folder outside both Roam and VaultBook, name it with the export date, and place the Markdown zip, the unpacked Markdown folder, and the JSON file inside it together, along with a short text file recording the date of export, the name of the graph, and the counts you verified. Do not rename the individual Markdown files at this stage, however untidy their titles look. Roam page titles often contain characters, dates, and namespace slashes that filenames approximate imperfectly, and premature renaming breaks the already fragile correspondence between a filename and the page it came from. Tidying belongs later, inside VaultBook, where each entry can be given a deliberate title without losing the link back to its source file. For now, fidelity beats neatness.

Verification is not optional, and it takes less time than consultants fear. Start with counts. Note how many pages Roam reports in your graph, then count how many Markdown files arrived in the zip. The numbers should be close enough to explain: a small difference can come from system pages or export behaviour, but a large shortfall means the export was interrupted or the zip is incomplete, and you should export again rather than proceed. Next, spot-check by type, not at random. Open one recent daily notes page and confirm yesterday’s thinking is there. Open one old literature page from the first year of the graph and confirm the early material survived. Open one confidential client page — locally, privately — and confirm its text exported in full, including nested blocks. Open one project page that relied heavily on block references and embeds, and read it with lowered expectations: the words should be present, but the live behaviour will not be, because a referenced block in Markdown is text and pointers, not a functioning transclusion. That limitation is expected. You are verifying content, not behaviour. Finally, open the JSON file in a text editor just long enough to confirm it is complete and well-formed — that it opens, that it is large in proportion to your graph, and that it does not end abruptly mid-structure because a download was cut short. You do not need to parse it. You need to know it is whole.

The step most migrations miss entirely is attachments, and it is the step where delay does real damage. A Roam page that appears complete in Markdown may contain images, PDFs, and audio that were never inside the page at all. They were uploaded to hosted storage and referenced by URL, so the export gives you a link, not the file. While your Roam access continues and those links remain live, the page looks intact. Once the hosting arrangement changes, an account lapses, or a link is revoked, the same page becomes a shell with dead references where evidence used to be. For a research consultant this is not a cosmetic risk. Field photographs, scanned documents, client-supplied PDFs, and recorded material often are the primary record; the surrounding note is commentary on them. So, before you consider the export finished, work through the graph’s attachments deliberately. Search the Markdown files for hosted file links. Open embedded images and PDFs from inside Roam while you still can, and download the underlying files into a clearly named attachments folder inside your migration folder, keeping a simple record of which page each file belonged to. Prioritise ruthlessly if time is short: client-supplied documents first, then unique field material that exists nowhere else, then published sources you could in principle obtain again. Screenshots of public web pages can wait. An interview PDF a client sent once cannot.

Resist two temptations at this stage. The first is to start cleaning as you export — merging duplicate pages, rewriting titles, deleting embarrassments from 2021. Cleaning during export contaminates your safety copy. You want one untouched record of the graph as it actually was, warts included, so that every later decision is reversible. The second temptation is to treat the cloud copy as the archive and skip local verification because the files are, for the moment, visible online. Visibility is not possession. The whole reason for moving to a local-first vault is that your research should sit on your machine, under your control, in files you have personally confirmed. That discipline starts here, with two exports, checked by hand, and a folder of attachments you downloaded yourself. Only when the Markdown reads correctly, the JSON is stored whole, the counts reconcile, and the attachments are home does the translation work in the next step rest on solid ground.

Step Two: Translating Roam Structures Into VaultBook Structures

No migration is a conversion in the mechanical sense, because Roam and VaultBook organise thought differently. Roam thinks in blocks on pages, connected by links and references, unfolding day by day. VaultBook thinks in entries inside a single self-contained file, organised by labels, connected by wiki links and related notes, searchable as a whole, with tools built around the entries rather than around an infinite canvas. If you try to force a one-to-one copy, you will preserve the shape of the old system and lose the benefits of the new one. If you translate thoughtfully — structure by structure, asking what each Roam habit was actually for — the graph becomes a vault that is smaller in friction and stronger in retrieval. This step is that translation, and for a six-year research graph it deserves unhurried attention, because every mapping decision you make here will be repeated hundreds of times.

Begin with the foundational mapping: pages become entries. Each Roam page that carries real content — a literature synthesis, a client project home, a concept page, a person page, a methods note — becomes one VaultBook entry with a clear title, its substance preserved as the entry body. This sounds obvious, but it changes how you write. A Roam page could sprawl indefinitely, accumulating blocks over years until finding anything meant scrolling and filtering. A VaultBook entry rewards a deliberate shape: a short opening that states what the entry is and why it matters, followed by headed sections for the material within it. When you migrate a large project page, do not paste six years of accumulation into one undifferentiated block of text. Divide it as you go: background in one section, key decisions in another, open questions in another, sources in another. The content is the same. The usability is transformed, because full search, including the built-in semantic question-and-answer search, works far better over well-sectioned entries than over an endless stream, and because you, returning after three months away from a client, can re-enter the project in minutes.

Links translate almost directly, and that continuity matters. A Roam double-bracket link to another page becomes a VaultBook wiki link to the corresponding entry. Preserve the link wherever the connection was intellectual rather than incidental: concept to evidence, claim to source, project to person, daily observation to the literature it eventually informed. Do not preserve every link mechanically. Six years of graph use produces courtesy links, tentative links made in a moment of enthusiasm and never used again, and links to pages that turned out to be dead ends. Migrating a link is a small editorial judgment that the relationship still earns its place. That judgment, repeated across the graph, is how a migration quietly improves a knowledge base instead of merely relocating it. Where a linked page is not being migrated at all — see the deliberate omissions below — remove the link or convert it to plain text with a brief note, rather than leaving a pointer to nothing.

Tags and namespaces become labels, and here restraint pays compound interest. In Roam, a hashtag could be created in a keystroke, and namespaces could grow organically until the same idea lived under three slightly different names. VaultBook labels are most powerful when the set is curated: a label should be a door you actually walk through when retrieving work. As you migrate, consolidate. Map the variants of a client name to the single label you will actually filter by. Map method tags — the interview, survey, desk-research, and analysis markers scattered through the graph — to a short, stable methods label set. Map status sparingly, because status changes and stale status labels mislead. Keep namespace information that carries real meaning, such as a literature area or a sector, as either a label or the opening line of the entry, and drop namespace scaffolding that existed only to keep the graph tidy in 2022. A good test for every label is prospective: will I, under deadline pressure next year, filter by this word? If not, the information belongs in the entry text, not in the label set.

Daily notes need a decision, because they are usually the largest single class in the graph and the least uniform in value. Roam’s daily notes pages, with their ordinal date titles — the month spelled out, the day with its suffix, the year — were the consultant’s scratchpad, log, and inbox combined. In VaultBook they become dated entries: one entry per day that earns it, titled consistently with an unambiguous date, labelled so the run of daily entries can be retrieved together. But earning it is the operative phrase. Some daily pages contain the seed of a published argument, a client insight, or a decision whose reasoning matters. Those migrate in full. Many contain only a copied link, a single TODO, and a fragment that was resolved the following week. Those migrate as a line or two inside a monthly digest entry, or not at all, with the JSON and Markdown exports preserving the original if it is ever needed. This is not data loss; it is editing, backed by a complete archive. The consultant who migrates all two thousand daily pages uncritically will recreate the very haystack they hoped to escape. The consultant who migrates the substantive days and digests the thin ones gains a daily record that can actually be browsed.

Action structures translate into the Kanban board. Roam TODO blocks scattered across daily and project pages were always a compromise: visible where you wrote them, invisible as a whole. In VaultBook, an open task with a deliverable, a deadline, or a client waiting on it becomes a Kanban card, placed in the appropriate column, linked in spirit to the entry that holds its context. Finished TODOs from past years do not become cards; their record belongs in the migrated project entry, as part of the history of what was done. Recurring obligations — report cycles, renewal dates, check-ins — belong not only on the board but in view of the built-in calendar and the Recent, Due, and Expiring sidebar, which is where VaultBook surfaces what needs attention without requiring you to remember to go looking. The principle is separation of concerns: entries hold knowledge, the board holds commitments, and the sidebar watches dates. Roam forced all three into the block stream. Letting each live in its proper place is one of the largest practical gains of the move.

Queries and block references require the most honest translation, because neither has a literal equivalent and both were load-bearing in Roam. A Roam query — a live list of blocks matching a tag, a link, or a date condition — becomes, in VaultBook, one of two things depending on its job. If the query was a standing view you consulted repeatedly, recreate its intent as a saved search habit: the label or phrase combination you run when you need that view, supplemented by semantic Q&A search when the question is conceptual rather than lexical — asking, in effect, what the vault knows about a topic and receiving answers drawn from across entries, including material you worded differently at the time. If the query was a one-off assembly for a single report, it does not need recreating at all; its output mattered, not its mechanism, and the output is in the report. Block references — a block written once and pointed at from many pages — become either related notes or sections within an entry. Where the referenced block was a definition, a standard method description, or a reusable framing, give it a home as its own short entry or as a clearly headed section, and connect the entries that used it through related notes, so the association is visible and navigable in both directions. Where an embed pulled a passage into a page so it could be read in context, reproduce that passage as a quoted section inside the receiving entry, with its source entry named. Quoting feels less elegant than live transclusion, and it has one decisive advantage: the receiving entry remains fully readable, searchable, and exportable on its own, forever, with no dependency on a block identifier resolving correctly. For client work that may be audited or handed over, that self-sufficiency is worth more than elegance.

Finally, decide what to deliberately not migrate, and write the decision down. Empty pages created by accidental links, pages consisting of a title and nothing else, and placeholder pages for books never read should not become entries; the archive exports remember they existed. Stale queries encoding abandoned project structures should not be recreated. Duplicate pages for the same person or concept, a common six-year accretion, should be merged into one entry during migration, with the stronger material kept and the weaker folded in or left to the archive. Personal ephemera with no research value and no sentimental claim can stay in the exports alone. Make these choices at the level of categories, not page-by-page agonising, and keep a migration log — itself a VaultBook entry — listing what was merged, what was digested, and what was left behind. That log is what turns omission from a risk into a method. When translation is done this way, what arrives in VaultBook is not a photograph of the old graph. It is the same knowledge, re-housed in structures that match how a consultant actually retrieves, protects, and delivers work.

Step Three: Bringing Attachments Home — PDFs, Images and Audio

Text is only half of a research consultant’s graph. The other half is evidence: the PDFs clients sent and authors published, the photographs taken in the field, the screenshots that captured a system before it changed, and the audio of interviews that no summary fully replaces. In Roam, much of that evidence lived at arm’s length, uploaded to hosted storage and summoned by link. The note was on the page; the file was elsewhere. Migration is the moment to end that separation — to bring every attachment home, onto your own machine, inside or alongside the vault — because a local-first system can only protect, search, and preserve what it actually holds. This step is the most labour-intensive part of the move, and also the part with the highest payoff, because once attachments are local, VaultBook’s built-in tools can do work on them that a hosted graph never attempted.

Start with the download pass, working from the inventory you built during export. Go through the hosted links in your Markdown files and in the live graph, and download each underlying file into your migration attachments folder, preserving the connection between file and page. Keep original filenames where they are meaningful and add the page or client name where they are not, because a folder containing forty files named as camera exports and download timestamps is an archive nobody can use. Work in priority order. Client-supplied documents come first: briefs, contracts-adjacent correspondence saved as PDF, data extracts, and draft reports sent for comment. These are irreplaceable and often confidential, and every day they exist only behind a hosted link is a day they are one account change away from inaccessibility. Published literature comes next — the journal articles and reports your literature pages discuss — because rebuilding a reading library from scratch is slow even when the sources are technically public. Field material follows: photographs, scans, and recordings that exist nowhere else. Work through the list steadily rather than perfectly; a downloaded, sensibly named eighty percent, with the remainder logged as outstanding, beats a flawless plan that stalls at ten percent.

PDFs deserve special handling, because consultants accumulate them in messy forms: a three-hundred-page report when only one chapter matters, three separate scanned instalments of a single document, a slide deck exported sideways, a file so large it is awkward to send or open. The habitual fix — uploading the file to a free cloud PDF service — should end with this migration, and for client material it should never have begun. Uploading a confidential client PDF to an advertising-supported conversion site, however convenient, hands a copy of that document to a third party whose retention practices you do not control. VaultBook’s built-in PDF tools change the default: merging, splitting, and compressing happen locally, inside the vault’s own toolset, with the file never leaving the machine. Use the merge to reunite documents that arrived in parts, so the vault holds one coherent source instead of three fragments. Use split to extract the chapter or annex a project actually cites, keeping the full original in your attachments archive while the entry works with the relevant portion. Use compression on the oversized scans that would otherwise bloat every backup of the vault. The pattern to establish is simple and strict: if a PDF needs surgery, the surgery happens at home. That single habit removes an entire category of quiet confidentiality leaks that hosted workflows normalise.

Images migrate into a different kind of usefulness once they are local. A field photograph in Roam was an illustration embedded in a page. In VaultBook, photographs can be explored as a collection through the Photo and Video Explorer, which surfaces the metadata cameras embed in every shot — the EXIF record of when and, where the device recorded it, where a photograph was taken, and with what settings. For a consultant, that metadata is evidence in its own right. A site-visit sequence can be re-ordered and verified by its timestamps. A photograph whose note says one date and whose EXIF says another prompts exactly the right question before the discrepancy reaches a client report. Photographs of whiteboards, noticeboards, shelves, and physical documents — the visual field notes every fieldworker accumulates — become browsable alongside the entries they support, rather than stranded as isolated embeds inside daily pages nobody reopens. As you migrate, take the small extra step of noting, in the relevant entry, which photographs document which claim or visit. The Explorer makes the images findable; your notes make them meaningful. Together they turn a camera roll that used to decay inside a graph into a field archive that strengthens with use.

Audio is where the local advantage becomes most vivid. Client and expert interviews are the consultant’s crown jewels and their largest files, and in a hosted workflow they typically lived as links, transcribed — if at all — by uploading them to a cloud transcription service. Consider what that upload means for a recorded conversation held in confidence: a complete, identifiable account of a client’s operations, spoken candidly, copied to servers you do not control, for the convenience of a transcript. VaultBook’s toolset offers the opposite route. The MP3 cutter and joiner let you trim silence, isolate the passage that matters, or assemble excerpts for analysis without an external editor, and the built-in local transcription, powered by Whisper running on your own machine, turns speech into searchable text with zero network requests — the recording never leaves the device that holds the vault. Transcribe the interviews that anchor current projects first, check the transcript against the audio for names and figures, and store the transcript within or alongside the interview entry so that the spoken record becomes part of the searchable vault. A remark made forty minutes into a conversation two years ago, unfindable in a hosted graph without replaying the file, becomes retrievable in seconds. That is not a marginal improvement. For interview-based research, it changes what the archive is for.

The final transformation is searchability, and it is the reason the download pass matters beyond mere possession. A PDF sitting in a folder is preserved but mute; its contents answer no questions. VaultBook indexes attachments and applies OCR — tesseract-based text recognition — so that scanned documents, photographed pages, and image-based PDFs yield their text to the vault’s search. The scanned annex a client sent as pictures of pages, the photographed sign-up sheet, the older report that was never born-digital: once processed, their words join the same full search, and the same semantic question-and-answer reach, as your typed entries. Test this deliberately during migration. Take one scanned document you know well, process it, and search for a phrase you know appears only in that scan. When the vault finds it, the migration has crossed its most important threshold: evidence and interpretation now live in one searchable place, on one machine, in one file’s ecosystem. Keep originals untouched alongside processed copies wherever fidelity matters, log which attachments have been indexed, and let the remaining backlog sit honestly in the log rather than pretending completeness. Attachments brought home in this way stop being links that might die. They become part of the work itself.

Step Four: Encrypting What Was Never Safe in a Hosted Graph

Every long-lived Roam graph contains material its owner would never have chosen to store on someone else’s servers, had the choice been presented clearly at the moment of writing. It accumulates gradually: the client interview written up candidly on the evening it happened, the notes from a call where a source spoke on condition of anonymity, the draft findings that would embarrass a client if circulated before they were final, the credential-adjacent notes — not passwords themselves, one hopes, but the surrounding detail of accounts, systems, contacts, and access arrangements that makes a researcher’s working life possible. None of it felt reckless at the time, because the graph was simply where thinking happened. But a hosted graph means copies on infrastructure you do not control, accessed through an account whose compromise would expose everything at once, under terms that can change. Migration to VaultBook is the first realistic opportunity to correct that exposure — not by encrypting everything indiscriminately, but by encrypting, entry by entry, the material that was never safe in the first place.

VaultBook’s protection is per-entry encryption using AES-256-GCM, with keys derived through PBKDF2 via the Web Crypto API, applied to individual entries inside the single vault file. The architecture matters as much as the algorithm names. Because the vault makes zero network requests and lives as one local file, an encrypted entry is not a promise by a provider that your data is handled carefully; it is a mathematical condition on the file sitting on your disk. Without the passphrase, that entry’s contents are ciphertext — in the vault file itself, in its backups, and in any copy of the file that travels. A client interview entry can therefore sit in the same vault as your public literature notes, backed up on the same schedule, carried on the same laptop, while remaining sealed in a way the literature notes do not need to be. For the consultant, the practical consequence is that confidentiality stops depending on account hygiene alone and starts depending on cryptography you control.

Per-entry encryption beats the whole-vault-or-nothing approach for reasons that only become obvious in daily use. A system that can only lock everything forces a bad bargain: either the vault is sealed and every trivial lookup — a citation, a date, a method detail — requires unlocking the whole archive, which trains the user to leave it unlocked, or the vault stays open and the sensitive material shares the exposure of the mundane. Per-entry protection dissolves that bargain. Your literature entries, project structures, reading notes, and daily logs remain instantly available, searchable, and frictionless. The interview write-up, the source-protection note, the unpublished findings entry, and the credential-adjacent record are encrypted individually, opened deliberately when needed, and sealed the rest of the time. Security that respects workflow gets used; security that obstructs workflow gets bypassed. A consultant migrating six years of mixed material should exploit this granularity from day one: as each sensitive entry is created during migration, encrypt it then, while its sensitivity is in front of you, rather than scheduling a hardening pass that experience says will slip.

Deciding what qualifies deserves a clear rule, because migration is the wrong moment for case-by-case hesitation. Encrypt, as a default, three classes. First, client interview and meeting entries where individuals spoke candidly, critically, or in confidence — including entries that merely summarise such conversations, since a summary of a confidential conversation is confidential. Second, unpublished research: draft findings, unreleased analysis, and material under embargo or negotiation, whose premature circulation could damage a client relationship or a publication. Third, credential-adjacent and access-related notes: anything recording how systems are accessed, who administers what, which contact can unlock which door — the connective tissue that is harmless in fragments and sensitive in aggregate. Do not encrypt what gains nothing from it: published-source summaries, public bibliographic records, and general methods notes should stay open, because encrypting the harmless alongside the sensitive dilutes attention and adds friction where no risk justifies it. Note the class of each encrypted entry in your migration log without recording its contents, so future you knows the vault’s protection map exists and where its boundaries lie.

Passphrase discipline is where this protection is won or lost, and VaultBook’s built-in password generator exists precisely for this moment. A consultant’s instinct — a memorable phrase reused, with variations, across services — is exactly what per-entry encryption must not inherit. Generate strong, unique passphrases for the encryption you rely on, using the generator rather than invention, and store them outside the vault, in whatever separate, protected arrangement you trust for master secrets; a passphrase recorded inside the vault it protects is decoration, not security. Choose a small number of strong passphrases rather than a different one for every entry — grouping by sensitivity class, for example, one for client-confidential material and one for unpublished research — because a scheme you cannot sustain under deadline pressure will collapse into reuse or into written-down shortcuts. Test your own recovery before you need it: encrypt a migrated interview entry, close the vault, reopen it, unlock the entry, and confirm the contents are intact and legible. That five-minute rehearsal, done during migration, is the difference between encryption as a control and encryption as a gamble. Be honest with yourself about the corollary: if you lose the passphrase, the entry is gone, and no support desk can restore it. That finality is not a defect. It is the same property that keeps the entry sealed from everyone else, and the archive exports from Step One remain your record that the material existed in the old graph.

Two supporting features make encrypted migration safer rather than merely stricter. Version history means that the act of migrating and encrypting an entry does not overwrite its past: earlier states of entries are retained, so a migration edit made in haste — a section trimmed too aggressively, a passage pasted into the wrong entry — can be recognised and reversed instead of becoming a permanent loss discovered months later. Treat version history as the migration’s safety net, and glance at it early, while the migration is young, so you know how to use it before you need it. And because the entire vault is one portable file, your backup discipline becomes simple enough to actually keep: copy the file, on your schedule, to your chosen backup locations, knowing the encrypted entries travel as ciphertext in every copy. What was never safe in a hosted graph becomes, in the vault, safe by construction — visible in structure, sealed in substance, and recoverable only by you.

Step Five: The First Week Living in the New Vault

A migration is not finished when the last entry is imported. It is finished when the new system carries a normal working week without the old one being opened in a panic — and the first week deserves to be treated as a deliberate apprenticeship rather than a test of willpower. The consultant who expects the vault to feel identical to a six-year-old graph on day one will conclude, wrongly, that the move failed. The consultant who rebuilds the daily workflow piece by piece, using each VaultBook structure for the job it suits, discovers within days that several old frustrations have quietly disappeared. Plan the week around the rhythms Roam used to hold: the morning capture, the active projects, the deliverables, the deadlines, and the serendipitous rediscovery that the graph view promised. Each has a home in the vault. The week is where you learn to walk to those homes without thinking.

Begin each morning with a dated entry, as the daily notes once began each Roam session, but write it in the vault’s idiom. Open a fresh entry titled with today’s date, labelled with your daily label so the run of days stays retrievable, and use it as the day’s working surface: the plan in the opening lines, capture through the day beneath it, and a closing note of what actually happened. The difference from Roam is what happens to the fragments afterwards. In the graph, a valuable observation made on Tuesday stayed on Tuesday’s page, findable mainly by remembering when you had it. In the vault, the end-of-day habit is promotion: anything in the morning entry that turns out to matter — a client insight, a literature connection, a decision — is copied or developed into its proper entry that same evening, with the dated entry remaining as the day’s honest log. This takes minutes and compounds enormously. Full search and semantic question-and-answer search then work over curated entries rather than over a sediment of daily pages, and your future self retrieves the insight by topic, not by archaeology. Keep the dated entries even when they are thin; they are the vault’s diary. Just refuse to let them remain the only place knowledge lives.

Let dynamic tabs carry your active projects. A consultant typically runs three to five live engagements alongside business development and writing, and Roam handled that simultaneity with pinned pages and browser tabs held together by memory. VaultBook’s dynamic tabs serve the same need inside the vault itself: keep each active project’s central entry open in its own tab — the project home with its background, decisions, and open questions — alongside the one or two literature or methods entries the current phase draws on. Arrange the tabs at the start of the week to match the week’s real priorities, and let closing a tab be the small ceremony that marks a project paused or delivered. The practical gain is re-entry speed. Returning to a client after two days on another engagement, you do not reconstruct context from search results and half-remembered page names; the project’s entry is where you left it, in the shape you gave it during migration, with its related notes a click away. Fewer, deliberate tabs beat the graph’s sprawl: if everything is open, nothing is active, so keep the tab set honest and small.

Move deliverables onto the Kanban board and keep them there. During the week, every commitment with an output — the interim findings note, the slide summary, the literature review, the invoice-adjacent report a client is waiting on — should exist as a card whose movement across the board mirrors reality: queued, in progress, with the client, done. The board earns its keep in the moments Roam handled worst, the whole-portfolio questions. What is due this week, what is blocked, what has been sitting in progress suspiciously long: the board answers at a glance, where the graph answered only after a query you had to remember to build. Link the board back to knowledge by discipline rather than by mechanism — name cards so the relevant entry is obvious, and record substantive progress inside the project entry, not only on the card, so the vault’s searchable record stays complete. By Friday, the board should tell the week’s story truthfully enough that your weekly review is a read, not a reconstruction.

Give deadlines to the calendar and the sidebar, and then trust them. Client milestones, submission dates, licence and document expiries, follow-up dates promised in meetings: enter them into the built-in calendar as they arise, and let the Recent, Due, and Expiring sidebar do the watching. This sidebar is the vault’s quiet answer to one of the graph’s most expensive failure modes — the obligation recorded faithfully in a daily page and never seen again. In Roam, a deadline was text; finding it again depended on you. In VaultBook, what is due and what is expiring surfaces on its own, alongside what you edited recently, so the morning dated entry can begin from an accurate picture of the day rather than from memory. During the first week, check the sidebar each morning and each evening, not because it needs supervision, but because you are calibrating trust: every deadline it surfaces correctly is evidence that the system, not your anxiety, now holds the dates.

Finally, replace the graph-view habit with related notes and search, and notice what the replacement gives back. Many Roam users opened the graph view not to navigate but to think — to see a project’s neighbourhood and be reminded of connections. VaultBook answers that need differently: related notes attached to each entry keep its genuine neighbourhood visible at the point of use, and semantic search lets you ask the vault a question in your own words and receive answers assembled from entries you wrote in different years, in different vocabulary. Use both daily during the first week. When you open a project entry, follow one related note you had forgotten. When a client asks a question, ask the vault first, before you answer from memory, and judge the result. By the week’s end, most consultants find the trade favourable: the graph view showed connections beautifully and retrieved answers poorly, while the vault retrieves answers immediately and shows connections where they are actionable. Keep Roam’s exports untouched as the archive, open the old graph only to check a specific migration question, and log any gap you find rather than drifting back. A week lived this way — dated mornings, tabbed projects, a truthful board, watched deadlines, and retrieval by meaning — is the point at which the vault stops being a migration destination and becomes, simply, where the work lives.

Why VaultBook Beats the Market-Leading Note Apps for This Migration

A migration is not a shopping trip. When you move a six-year research graph out of Roam Research, you are not choosing a prettier editor or a faster capture button. You are choosing where confidential client thinking will live for the next six years, who will hold a copy of it while it lives there, and what happens on the days when the network, the account, or the vendor lets you down. That is the test this section applies to every market leader. Each of the apps below is good at what it was built to do, and several of them are better than VaultBook at specific jobs this article will name plainly. The question is narrower and, for an independent research consultant, more decisive: if the thing you are moving is a confidential graph — client names linked to unpublished findings, interview notes linked to source pages, hypotheses linked to evidence you have not yet shown anyone — which system gives you custody of that graph, encryption at the level of the individual entry, reliability when you are offline, portability as a single file, and independence from an account and a server? Judged on those five mechanisms, for this scenario, VaultBook wins against each leader in turn, and it wins for reasons that can be stated mechanically rather than as slogans.

Start with what those five mechanisms actually mean in the daily life of this migration, because they will recur under each app. Custody means the graph never has to be uploaded to someone else’s computer in order to work. VaultBook is a single-file HTML app that runs locally and makes zero network requests, so opening your vault on a train, in a client’s meeting room, or in a house with the router unplugged is the normal case, not a degraded mode. Per-entry AES-256-GCM encryption means you do not have to choose between encrypting everything, which makes casual browsing clumsy, and encrypting nothing, which leaves client material exposed; you can lock the entries that carry client confidences, source identities, and unpublished conclusions, and leave your reading lists and methods notes open for fast work. Offline reliability follows from the architecture rather than from a cached copy: there is no sync to fail, no server status to check, and no conflicted copy to reconcile when you return. One-file portability means the whole working system travels as one file you can copy, back up, and open again without an export ritual. No account or server dependence means nobody can lock you out of your own graph by suspending an account, ending a session, or suffering an outage on the other side of the world.

Notion: superb for teams, wrong custody model for a confidential solo graph

Notion is the leader most consultants will consider first, and the reasons are real. Its pages and databases are flexible, its sharing is effortless, and a workspace that a team lives in together is a genuinely powerful thing. If your research practice were collaborative — associates drafting in the same pages, clients commenting live, databases handed over as living deliverables — Notion’s live collaboration and relational databases would be stronger than anything VaultBook offers, and this article concedes that without qualification. VaultBook is a personal vault, not a team workspace, and pretending otherwise would be dishonest.

For this migration, however, Notion’s strengths are inseparable from the custody problem you are leaving Roam to escape. Notion is a hosted service: your pages live on Notion’s servers, you reach them through an account, and the system is designed around sync and sharing. Move a confidential graph there and you have changed vendors without changing the underlying arrangement — the client names, the linked hypotheses, the interview material are once again stored by a third party, under an account, reachable only through that company’s infrastructure. There is no per-entry encryption you control in the VaultBook sense, where a single sensitive entry sits locked inside an otherwise open vault; the unit of trust in Notion is the workspace and the account that guards it. There is no single file to carry away either. Exports exist, but an export is a snapshot you make occasionally, not the living form of the graph, and a database-heavy workspace does not round-trip into a portable file you can simply open elsewhere.

VaultBook’s advantage here is specific. Your Roam graph, rebuilt with entries, labels, and wiki-style links, lives in one local file. The entries that name a client, quote an interviewee, or state a conclusion you are not ready to publish can each be encrypted individually, while the surrounding methods pages stay instantly searchable. Full search, including semantic question-and-answer over your own material and OCR over scanned pages, runs against that local vault, so the exploratory querying you loved in Roam — asking what you know about a topic across six years — does not require sending the question or the corpus anywhere. When a client asks, as research clients increasingly do, where their material is stored and who can access it, the answer is short and verifiable: on your machine, in a file you hold, in an app that makes no network requests. That answer is not available to a Notion workspace, however well run.

Evernote: a mature archive that still asks you to trust the archive keeper

Evernote deserves respect in any migration discussion because it solved, earlier than most, the problem of capturing everything and finding it again. Its web clipper remains the most mature in this group — if your workflow depends on clipping large volumes of web pages in tidy form, Evernote’s clipper is genuinely stronger than VaultBook’s capture routes, and its legacy search over a deep, years-old archive is battle-tested in a way newer tools must earn. A consultant whose primary need was a vast clipped reference library, lightly linked and rarely confidential, could defend staying with Evernote on those grounds alone.

But notice what kind of system Evernote is: an account-based service holding your notes on its servers, organised for retrieval rather than for a linked graph. A Roam migration is not mainly a retrieval problem. Your six years are valuable because of the links — the way a claim on one page is supported, qualified, or contradicted by blocks on other pages — and because of the sensitivity of what is linked. In Evernote the graph flattens into notebooks, stacks, and tags, and the custody arrangement remains the one you are trying to leave: upload first, trust the provider, sign in to reach your own work. There is no per-entry encryption under your control comparable to locking individual VaultBook entries, and no single-file form in which the entire living archive travels with you and opens without the service. Offline access in a hosted system is a cache of a remote original; in VaultBook the local file is the original, which is a different and stronger guarantee when you are working from a site with poor connectivity or from a machine you keep deliberately disconnected while handling sensitive material.

The concrete scenario makes the difference plain. Suppose your graph contains a page for a source who spoke on condition of anonymity, linked to three interview entries and to the client project that commissioned them. In VaultBook those interview entries can be individually encrypted while the project page remains open, the links remain part of your private working structure, and nothing about the arrangement leaves your machine. Version history means that if you edit an interview entry and later need to show what it said before the edit — a real need when a finding is challenged — the earlier state is recoverable from within the vault. That combination, per-entry locking plus history plus local custody, is the mechanism of the advantage, not a claim that Evernote is a poor product.

Microsoft OneNote: deep Office integration, and a reminder of what server dependence costs

OneNote is the leader most likely already to be installed on a consultant’s Windows machine, and its strengths are the strengths of the Microsoft ecosystem. Freeform pages suit people who think spatially, handwriting and pen input are excellent — genuinely better than anything VaultBook attempts, and this article concedes it directly: if you annotate by hand, sketch relationships on the page, or record and mark up meetings inside your notes, OneNote serves that work in ways VaultBook does not. Its integration with the rest of Microsoft 365 is equally real; for a consultant embedded in a client’s Office-based workflow, that fit has daily value.

The custody and dependence questions remain, and recent events have made them concrete rather than theoretical. During the Microsoft 365 outage of November 12–13, 2026, reported by USA TODAY on November 13, web users were caught by a failure in a service they did not control, on a timetable they did not choose. That is not an argument that Microsoft is careless; large services fail occasionally whoever runs them. It is an argument about architecture. When your notebook depends on an account and a remote service, an outage there becomes an outage here, in your working day, in front of your deadline. A Roam refugee should recognise the shape of that risk, because dependence on a hosted graph is precisely the exposure this migration is meant to end.

VaultBook removes that class of failure from your research graph entirely. There is no sign-in between you and your entries, no service status page to consult before a client call, and no sync engine deciding which copy of a page is authoritative. The file opens locally, the search runs locally, and the tools you need around the graph — merging, splitting, and compressing the PDFs your evidence arrives in, cutting and joining MP3 recordings, transcribing them locally — are built into the same single file rather than scattered across a suite that assumes connectivity. OneNote’s handwriting and Office integration are real concessions, and a consultant who lives by the pen should weigh them seriously. But for a text-based, confidential, link-driven graph whose owner works alone and answers personally for its security, dependence on a distant service is a cost with no compensating benefit, and VaultBook’s independence is the advantage.

Google Keep: frictionless capture that was never built to hold a graph

Google Keep is the most modest app in this list and, within its intended scope, one of the most successful. On Android especially, its quick capture is close to frictionless: open, type or dictate, close, and the note is there. For shopping lists, fleeting reminders, and the thought you would otherwise lose in a car park, Keep is genuinely stronger than VaultBook, and no honest comparison should pretend that a full vault competes with that speed for throwaway capture. Keep was built for exactly that lightness.

Precisely because of that design, Keep cannot receive this migration, and comparing the two clarifies what a graph actually requires. Keep has no linking structure capable of carrying six years of cross-referenced research, no per-entry encryption, no version history worthy of the name for professional purposes, and no way to hold the long, structured, evidence-bearing entries that make up a consultant’s working memory. It is also, despite its lightness, an account-based Google service: the notes live under your Google account on Google’s infrastructure, so even its simplicity comes with the same third-party custody, in exchange for far less capability. A note app that is quick but shallow and hosted but limited gives this migration the worst combination on the table.

VaultBook’s advantage over Keep is therefore not a matter of degree but of category, stated concretely. Where Keep offers a label, VaultBook offers labels plus wiki-style linking plus related notes that surface connections you did not explicitly make — the closest available continuation of the serendipity a Roam graph provides. Where Keep offers a search box over short notes, VaultBook offers full search across long entries, semantic question-and-answer, and OCR, so a half-remembered phrase from a 2022 interview remains findable. Where Keep offers no answer at all to confidentiality beyond the account password, VaultBook offers individual entries locked with AES-256-GCM. Keep your phone’s quick-capture habit if it serves you for ephemera — but ephemera was never the problem this migration solves.

Apple Notes: seamless inside one orchard, silent about custody and structure

Apple Notes has improved steadily into a respectable note app, and its defining strength is integration: it is simply there on every Apple device, quick notes are a gesture away, and for a consultant whose entire working life runs on a Mac, an iPhone, and an iPad, that seamlessness is real and should be conceded as such. If your capture happens constantly across Apple hardware and the notes are mostly short and personal, Apple Notes may already be doing that job well, and VaultBook will not beat it on sheer ambient convenience within that ecosystem.

The limits appear exactly where this migration presses. Apple Notes lives inside Apple’s account and sync world; the graph’s home is a service you access rather than a file you hold, and there is no single portable file that constitutes the living archive and opens independently of that ecosystem. Its organising model — folders and tags around individual notes — does not reproduce a linked research graph, and its locking, where it exists, is a note-level convenience rather than per-entry encryption designed as the vault’s security model for confidential professional material. A consultant who later needs to move again, demonstrate custody to a client, work on a non-Apple machine, or keep research tooling and research content together will find the orchard walls are also the archive’s walls.

Against Apple Notes, VaultBook’s mechanisms answer point by point. One file, held by you, opens in the local app regardless of which operating system ecosystem currently has your favour, so the graph outlives any particular hardware allegiance. Entries, labels, and wiki links rebuild the graph’s structure rather than flattening it into folders. Per-entry encryption separates the client-confidential core from the open working material inside the same vault. And the built-in tools — the Photo and Video Explorer that reads EXIF data from site-visit media, the Reader for long documents, the Kanban view for tracking projects whose research pages sit in the same vault, data visualisation for the figures your findings rest on, the calendar and the Due and Expiring sidebar for the deadlines and renewals a practice runs on — mean the vault is not merely a safer store for the graph but a working environment around it. Apple Notes wins on ambient integration for Apple-only capture. For the custody, structure, and independence this migration is actually about, VaultBook wins, and it wins on mechanisms you can point to rather than on taste.

Taken together, the pattern across all five leaders is the same, and it is the reason this section can be confident without being unfair. Each leader is stronger than VaultBook at something specific — collaboration, clipping, handwriting, capture speed, ecosystem integration — and a reader whose work centres on one of those strengths should choose accordingly. But each leader, in a different way, asks you to rebuild a confidential graph inside someone else’s custody, behind an account, in a structure flatter than the graph you have, with no per-entry encryption under your control and no single file that is simply yours. VaultBook was the only candidate in this comparison for which custody, per-entry encryption, offline reliability, one-file portability, and account independence are not features added to a hosted service but consequences of what the thing is: one local file, running locally, asking nothing of any network. For a six-year confidential research graph leaving a hosted outliner, that is not a marginal edge. It is the whole point of moving.

What About Obsidian, Logseq and Staying on Roam?

The five leaders above are the obvious comparisons, but they are not the comparisons a Roam user actually loses sleep over. If you have lived in Roam for six years, your shortlist almost certainly contains Obsidian, contains Logseq, and — on tired evenings, when the migration spreadsheets are open and the graph still works perfectly well where it is — contains the option of simply staying put. Each of those three deserves a straighter answer than a sales page would give, because each is right for somebody, and one of them might be right for you.

Obsidian first, because it is the strongest alternative in this entire article. Obsidian stores your notes as local Markdown files on your own machine, and that single decision earns it most of what this migration is for: custody, offline reliability, and independence from a vendor’s servers. Its plugin ecosystem is extensive and genuinely impressive — a large community has built extensions for almost every workflow a knowledge worker has imagined — and the plain-files foundation means your notes remain readable in any text editor, decades from now, whatever happens to any company. Those are not minor concessions. If your overriding priority is plain-text longevity, if you enjoy assembling and maintaining your own toolchain, and if you are comfortable being your own systems integrator, Obsidian is a real answer and this article will not pretend otherwise.

Where VaultBook wins for this reader is in what you do not have to assemble. The consultant in this scenario does not only write linked notes. In an ordinary month she interviews people and needs those recordings transcribed; receives evidence as PDFs that need merging, splitting, and compressing before they can be filed; photographs sites, documents, and whiteboards and later needs to know when and where a photograph was taken; tracks projects, deadlines, and expiring documents; and holds a portion of the graph under encryption because clients require it. In VaultBook, local transcription of audio, PDF handling, a Photo and Video Explorer that surfaces EXIF data, a Kanban view, a calendar with a Due and Expiring sidebar, and per-entry encryption are not plugins to research, install, update, and troubleshoot — they are built into the single file, present on the first morning, working offline because everything works offline. The difference is not capability in the abstract; a sufficiently determined Obsidian user can approximate much of this. The difference is where the maintenance burden sits. An independent consultant sells her hours. Hours spent curating a plugin stack are hours not billed and not spent on research, and a stack assembled from many hands has many points of failure, each with its own update rhythm. VaultBook’s single-file design trades the plugin ecosystem’s breadth for a coherent, self-contained toolset that arrives whole — and for the reader whose need is the specific bundle of research work described here, that trade favours VaultBook.

There is also the encryption point, which is easy to blur and should not be. A folder of plain Markdown files is beautifully portable and completely readable — by anyone who obtains the folder. Protecting selected material inside such a system means stepping outside the plain-files model for exactly the entries that matter most. VaultBook builds the distinction into the vault itself: entries that carry client confidences are individually encrypted with AES-256-GCM, entries that do not stay open and searchable, and both kinds live in the same structure with the same links and labels. For a graph whose sensitivity varies entry by entry — which is to say, for almost every real research graph — that granularity is the deciding mechanism.

Logseq is the comparison that will feel closest to home, because Logseq is the most Roam-like of the alternatives: an outliner at heart, block-oriented, built around daily pages and linked references, and local in its storage. If what you love about Roam is specifically the feel of thinking in nested blocks, and if block-level fidelity in the move matters more to you than anything else in this article, Logseq concedes the least in translation and that should be said plainly. A Roam user can sit down in Logseq and feel the ground is familiar within the hour.

The case for VaultBook over Logseq, for this reader, rests on scope and on the security model rather than on the writing surface. Logseq reproduces the outliner; the consultant’s problem, as this migration has defined it, is larger than the outliner. It includes the recordings, the PDFs, the photographs and their EXIF records, the project tracking, the expiring documents, and the confidential core. VaultBook answers that whole bundle in one file with built-in tools, dynamic tabs for keeping several working contexts open, and related notes to recover the associative discovery that a graph exists to provide. And again, the per-entry encryption is native to the design rather than an accommodation. Choose Logseq if block fidelity is your first love. Choose VaultBook if the graph is one part of a wider research practice that also needs its media, its documents, its deadlines, and its secrets handled in the same private place.

Finally, staying on Roam — and here the honest concession is the largest of the three. If block transclusion is not a feature you admire but a load-bearing part of your daily method — if your client deliverables, your literature reviews, and your thinking itself are built from live transcluded blocks that must update everywhere at once — then no destination in this article fully replaces it, and leaving Roam means redesigning that method, not merely relocating it. A consultant in that position should stay, at least until the method changes, and should not be talked out of it by custody arguments however sound. Roam also remains, simply, the environment where six years of habit live; fluency has value and migration has a cost in weeks of friction.

But be clear about what staying means, because the rest of this scenario usually decides it. Staying means the confidential graph continues to live in a hosted system, under an account, on infrastructure you do not control, without per-entry encryption of your own, and with the whole archive’s availability riding on a service’s continuing health and your continuing relationship with it. For the consultant whose clients have begun asking custody questions, whose work takes her offline, and whose graph’s sensitivity has grown with her practice, those are not abstract discomforts; they are the reasons the migration was contemplated at all. VaultBook wins for this reader not because Roam is weak — Roam taught her how to think in a graph — but because VaultBook is the destination that keeps the graph’s essential habits, its links, labels, search, and serendipity, while changing the one thing that had become indefensible: who holds it.

Edge Cases: Broken Links, Orphan Pages, Huge Daily-Note Runs and Namespaces

Every long migration produces a morning when the bulk import is done, the counts look right, and the problems that remain are all small, strange, and personal to your graph. Six years of Roam habits leave characteristic debris. This section works through the four kinds you are most likely to meet — broken links, orphan pages, daily-note runs too large to review naively, and namespaces — with fixes that are practical rather than perfect, in the order you should tackle them: links first, because they define the graph; orphans second, because many of them are broken links in disguise; daily notes third, because they are a triage problem, not a reading problem; namespaces last, because they are a labelling decision you only want to make once.

Broken links in a migrated graph usually turn out to be empty pages wearing a link’s clothing. In Roam, linking to a page that does not exist creates the page, which is a wonderful feature for thinking and a quiet trap for archives: every mistyped title, every link to a book you meant to read and never did, every plural where the real page is singular, becomes an empty page that your export faithfully carries across. In VaultBook these arrive as entries with a title and no substance, still receiving links from real entries. The fix is a systematic pass, not a wandering one. Work through the empty entries in a single sitting with your Roam export open beside the vault. For each one, ask which of three things it is. If it is a mistype of a real page — and after six years you will recognise your own recurring mistypes instantly — merge it into the real entry: repoint the linking entries to the correct title, then remove the empty shell. If it is a placeholder for work that genuinely still matters, keep it, but mark it honestly with a label for unfinished pages so it stops masquerading as content. If it is neither — a dead intention from 2021 — delete it and let the links that pointed to it become plain text in context; a sentence that once linked to a page you never wrote loses nothing by standing unlinked. What you must not do is leave hundreds of empties in place out of tidiness anxiety: they pollute search results, they make related notes noisy, and they disguise the graph’s real shape.

Duplicate pages are the broken link’s sibling. Roam graphs accumulate them whenever a title was created twice in slightly different forms — with and without a middle initial, in full and abbreviated, once from a daily note in a hurry and once from a careful session. After migration, duplicates reveal themselves because full search returns two near-identical entries for the same person, project, or concept, each holding links and material the other lacks. Merge them deliberately: choose the fuller or better-titled entry as the survivor, move the other’s unique content into it, repoint every incoming link, and only then remove the duplicate. VaultBook’s version history is your safety net here — but it protects entries you edit, not carelessness, so do the repointing before the removal, every time, and spot-check the survivor’s incoming links afterwards.

Orphan pages are entries with content but no links in or out, and they need gentler handling than empties because most of them are not mistakes. In six years you will have created standalone pages for one-off enquiries, conference impressions, half-explored ideas, and clients who never returned. Migration is the first moment you have ever seen them listed together, and the temptation is either to link them frantically or to delete them wholesale. Resist both. Sort orphans into three piles. The first pile is misfiled graph material — pages that clearly belong to a project, person, or theme and simply never got linked in Roam’s flow; give these a home with labels and a link from the relevant hub entry. The second pile is legitimate standalone reference — the standalone is the correct form for it — and these should be labelled by type so search and the label structure can find them even without links. The third pile is genuinely dead: superseded, mistaken, or so context-free that even you cannot reconstruct why it exists. Archive that pile rather than deleting it outright during migration week; a consultant’s dead page occasionally turns out, two years later, to be the only note of a conversation a client suddenly remembers. Cold storage costs little. Regret costs more.

The daily notes are the volume problem. A consultant who used Roam properly may arrive with well over two thousand daily pages, and no human being should review them one by one. Triage them by era and by linkage instead. First, protect the client-linked days absolutely: any daily note that references a client, a project, an interview, or a decision is working record, and it migrates intact, whatever else you economise on — never delete a client-linked day, because daily notes are often the only contemporaneous evidence of when you knew something or advised it. Second, handle the fallow years in bulk: for periods when the practice was quiet, or when daily notes degenerated into copied task lists, merge each month into a single monthly entry, preserving the text while collapsing the clutter of thirty near-empty pages into one honest record. Third, let the truly empty days go; a daily page containing nothing but a date template was never a note. This triage typically reduces the daily-note mass dramatically while keeping every day that carries evidence, chronology, or thought. Use labels for the year and for merged months so the sequence remains navigable, and use the calendar view to sanity-check that no month has silently vanished in the merge.

Namespaces are the structural decision hiding in your titles. Roam encouraged titles with slashes — a project followed by a subtopic, a person followed by a context — and six years of that habit produces a thicket of pseudo-hierarchies that made sense as titles and make much less sense as entry names in VaultBook. The clean conversion is to split each namespace at the slash: the part before it usually names the durable thing — the project, the person, the domain — and becomes the entry’s home or its principal label; the part after it becomes the entry’s actual title or a secondary label. In practice, labels do the work namespaces were doing, and do it better, because an entry can carry several labels while a title could only sit in one namespace. Do not attempt this conversion by hand across hundreds of titles in one pass. Work namespace by namespace, largest first, deciding the label scheme for that family once and applying it consistently, and keep a short note of your decisions in the vault itself — future you, adding new entries, needs the scheme written down, not remembered.

One last edge case sits underneath all the others: dead attachment links. Roam entries may refer to files that were hosted with the graph, and some of those references will arrive in VaultBook pointing at nothing. Your recovery source is the original export — keep the full JSON export as well as the Markdown, because the JSON preserves structure and references that the flatter export can lose, and a reference that looks dead in the migrated entry can often be traced in the JSON to the file or page it meant. Where the underlying file still exists in your own downloads, project folders, or email, reattach its substance to the vault properly: PDFs into your document workflow, recordings to be transcribed locally, photographs into the Photo and Video Explorer where their EXIF data becomes useful again. Where the file is genuinely gone, annotate the entry to say so, with the date of the migration. A graph that honestly marks its losses is worth more than one that pretends completeness.

Keeping the Two Systems Straight During a Parallel Month

The safest migration is not the fastest one. For one month — four ordinary working weeks, not a heroic weekend — run Roam and VaultBook side by side, with a strict division of labour that you do not negotiate with yourself on busy days. Roam becomes read-only archive from the first morning of the parallel month: you may open it, search it, and copy from it, but you write nothing new in it, correct nothing in it, and capture nothing in it. VaultBook becomes the only place new work happens: every new note, every interview record, every client thought, every daily entry starts in the vault. This single rule — archive read-only, new capture in one place only — is what makes a parallel run clarifying instead of chaotic. The moment new material is allowed to appear in both systems, you no longer have a migration; you have a fork, and forks of a research graph do not reconcile themselves.

Make the division visible in your physical routine. Remove Roam from your startup tabs and your phone’s home screen; put the VaultBook file where your hand already goes. When a thought arrives while you are reading in the Roam archive — and it will, constantly, in the first week — do not jot it in the margin of the old system out of reach-habit. Copy the passage you were reading into the vault, write the thought there, and link it there. Each such moment feels slower than staying put, and each one moves a living connection across to the new graph, which is exactly the work of the month. By the third week the reach-habit itself will have moved, and that, more than any checklist, is the sign the migration is taking.

Reconcile weekly, on a fixed appointment with yourself, using the same short checklist each time so the four reconciliations are comparable. First, counts: compare the number of entries created in the vault that week against your sense of the week’s work — a week of heavy interviewing should show heavy capture, and if it does not, something is still being written down somewhere else, probably on paper or in a stray document, and it needs a home. Second, links: run a pass over the week’s new entries and confirm each one is linked or labelled into the graph; new material that lands as orphans in the new system recreates the old system’s debris in miniature. Third, the archive questions: note every time during the week you had to open Roam, and why. Early weeks will show lookups for material not yet migrated or not yet trusted in its new form; those lookups are your remaining migration list, in priority order, supplied by real need rather than by guilt. Fourth, encryption: confirm that the week’s confidential entries — new client material, new interview records — are actually encrypted, not merely intended to be; intentions are the most common security failure in any system, and the weekly check is what converts a good design into a kept habit. Fifth, backup: confirm the vault file’s backup copy exists, is current, and is stored somewhere other than the machine the original lives on.

Expect the emotional arc and do not mistake it for evidence. Week one feels like loss: the old graph is fluent and the new vault is effortful, and every lookup reminds you what six years of habit are worth. Week two is when the vault’s own advantages begin to be felt in the body rather than believed from articles — the morning the internet drops and nothing about your work changes; the client call where the answer to the custody question is one sentence long; the recording transcribed locally the same afternoon it was made. Week three is when Roam lookups thin out to genuinely archival questions. Week four is when you catch yourself unable to remember the last time you opened the old graph for working material at all. That arc, honestly observed, is the readiness test.

Close the hosted graph when three conditions coincide, not before, and not long after. The lookup log from your weekly reconciliations shows archive-only use — history, not work. A full search of the vault for your most important clients, projects, and concepts returns the material you expect, in the form you expect, so the new graph has passed the only retrieval test that matters, which is yours. And you hold, outside both systems, the cold backup: the complete JSON export and the complete Markdown export of the Roam graph, stored as files you control, unopened but verified present. The JSON preserves the graph’s full structure; the Markdown preserves a human-readable form; together they mean that closing the hosted account destroys nothing you cannot reconstruct. Keep those exports permanently, as you would keep the records of any closed chapter of the practice.

Then close it — actually close it, on a chosen day, rather than letting the hosted graph linger as a paid monument to indecision. A lingering archive you still half-trust is worse than either system alone, because it splits your certainty about where the record lives. Export once more on the final day, file that export with the others, record the closure in the vault itself — a single entry noting the migration’s dates, the parallel month, and where the cold backups sit — and let the vault become simply the place your research lives: one file, on your machines, under your hand, with six years of linked thinking inside it and room for the next six.

Three Workflows That Prove the Migration Worked

A migration is not proved by an import log. It is proved on the first ordinary Tuesday when you reach for something without thinking about where it lives, and it is there, in the form you need, fast enough that the work continues. For an independent research consultant coming from six years in Roam Research, that test is stricter than it sounds. The graph was not a hobby notebook. It held daily notes that functioned as a lab book, literature notes built paper by paper over years, transcripts and summaries of confidential client interviews that could never sit casually on someone else’s server, and project pages that tied all of those together into briefings people paid for. If any one of those strands breaks in the move, the migration has failed in practice even if every file technically transferred.

What follows are three workflows, worked through in the order a consultant would actually run them after the move. They are deliberately different from one another. One is about assembling published knowledge. One is about handling material that must stay private. One is about working where there is no connection at all. Together they test the things Roam users worry about most: whether the connections survive in a useful form, whether search still finds things buried in attachments, whether sensitive material can be both usable and protected, and whether the tool still works when the network does not.

A client literature review, assembled from the vault

Imagine the brief arrives on a Monday morning. A client in a regulated industry wants a short literature review by Friday: what the credible research actually says about a contested practice in their sector, where the evidence is strong, where it is thin, and what a careful decision-maker should not claim. This is familiar work. In Roam, it would have started with a page for the question, a trawl through backlinks, and a slow manual gathering of papers read over several years. In VaultBook, it starts in the same place conceptually — with the question written down — but the mechanics are different, and in some respects better suited to producing a finished briefing rather than an elegant graph.

The consultant creates a new entry for the commission itself: the client’s exact wording, the deadline, the agreed scope, and the exclusions. That entry gets labels for the client, for the project type, and for the topic. Labels in VaultBook do the quiet organisational work that a Roam user might previously have split between page tags and block tags. They are not decoration. Because the later stages of this workflow depend on pulling a precise set of sources and nothing else, the labelling has to be disciplined from the first entry onward: literature entries carry a literature label, a topic label, and a status label distinguishing read-and-summarised from read-and-cited from superseded. That discipline, imported and cleaned during the migration, is what makes the assembly step fast.

Next comes retrieval, and here the Reader and optical character recognition change the texture of the work. Much of a consultant’s literature does not live as tidy typed notes. It lives as PDFs: journal articles downloaded years ago, scanned chapters, reports with awkward two-column layouts. In Roam those PDFs lived outside the graph, in a folder, linked at best and remembered at worst. In VaultBook the PDF tools and the search that reaches inside documents mean the paper itself is part of the searchable record. The consultant searches for the key terms of the brief and gets back not only the literature entries she wrote, but passages inside attached PDFs she may not have summarised at the time. A methods appendix she skimmed in 2022 turns out to contain exactly the caveat the briefing needs. She opens it in the Reader, reads the relevant section in context rather than as a search snippet, and adds a short entry capturing the point in her own words, labelled and linked to the commission entry.

That last move matters. A literature review built only from other people’s sentences is a collage. The value the client pays for is judgement: which studies to trust, which to discount, and why. So the workflow alternates deliberately between retrieval and writing. Search and related notes surface candidate sources. The Reader is where she checks them. Her own entries are where the judgement is recorded. Related notes play a specific role here: when she opens a core paper’s entry, the related entries point her toward two other entries she had forgotten were connected — a critique she noted eighteen months later, and a project entry from a different client where the same method was used in practice. In Roam, that connection might have depended on whether past-her had remembered to add a backlink. Here the connection is suggested by the material itself, and she can accept it, follow it, and, where it is genuinely useful, make it explicit in the wiki structure so it persists.

By Wednesday the shape of the review exists as a small, labelled cluster: the commission entry at the centre, perhaps twenty source entries around it, each with a status, and a drafting entry where the argument is being built section by section. The wiki function is what holds the synthesis. A wiki page for the central concept gathers the definition disputes — because in contested fields, half the literature is really an argument about what the key term means — and links outward to the sources on each side. Another wiki page holds the chronology, because a finding from 2019 that was qualified in 2022 and partly reversed in 2024 cannot be cited as if time had stood still. Writing the briefing then becomes an act of reading her own structured cluster rather than an act of excavation. She is not hunting through six years of daily notes hoping the relevant block turns up. She is working from a set that search, labels, and related notes assembled, and that she then pruned by hand.

The final check before delivery is also a VaultBook habit worth naming: she searches the draft’s key claims back against the vault. Every strong sentence in the briefing should trace to a source entry she can open. If a claim traces only to her memory of a paper, it gets softened or cut. That is not a feature in a menu; it is a workflow the tool makes practical because the sources, the PDFs, and the notes are in one local place, searchable together. When the briefing goes to the client, none of the vault goes with it — just the document. The underlying cluster stays, labelled and dated, ready for the follow-up question that regulated-industry clients reliably ask three weeks later.

A confidential interview series, from recording to encrypted transcript

The second workflow tests the opposite end of the practice: material that must never become casually searchable, shareable, or exposed. A client commissions a series of interviews — say eight conversations with staff about a sensitive internal change. People speak candidly because they were promised care: recordings used only for the research, transcripts held securely, reporting anonymised. In Roam, a consultant handling this material faced an uncomfortable compromise. The thinking wanted to live in the graph, near everything else. The duty of confidentiality pulled in the other direction, toward keeping transcripts out of a cloud-synced notebook altogether. Many consultants solved this by fragmenting their own record: summaries in the notebook, real material in a separate folder, and a permanent low-level anxiety about which was where.

In VaultBook the workflow can be whole, because the protections are per-entry and the processing is local. It begins with audio. Each interview is recorded as a separate file, named by code rather than by the interviewee’s name — a habit that predates any software and should survive every migration. Back at her desk, the consultant opens the recording with the MP3 cutter. Most interview recordings contain material that should not be transcribed at all: the settling-in chat before consent is confirmed, a phone ringing mid-session, a digression where someone names a colleague in an unguarded aside. Cutting first is an ethical step as much as a technical one. She trims the recording to the consented interview, keeps the original file untouched in her own archive, and works from the cut version.

Transcription is where local-first stops being a preference and becomes the substance of the promise she made. The audio is transcribed locally with Whisper, on her machine. The recording of a person describing a workplace problem in confidence does not travel to a transcription service, does not sit in a vendor’s processing queue, and does not become training-adjacent data in someone else’s system. For a consultant whose clients are buying discretion as much as analysis, that is not a marginal detail. It is the difference between being able to say, truthfully and simply, where the material went — nowhere — and having to explain a chain of processors.

The transcript then becomes an entry, and this is the moment to use per-entry encryption rather than treating the whole vault as uniformly sensitive. VaultBook encrypts individual entries with AES-256-GCM. The consultant encrypts each full transcript entry. The distinction between encrypting everything and encrypting the entries that warrant it is practical, not just principled. Her literature notes, her daily notes, her project planning — those need to be frictionless, searchable, open in a second. The transcripts need to be sealed when not in active use. Per-entry encryption lets both be true in the same vault. She opens a transcript when she is coding it, works in it, and it returns to its encrypted state as an entry she has deliberately protected. If the laptop were lost, or the file copied without her knowledge, the transcripts would not be readable text in a stranger’s hands, while the promise she made to interviewees would still have a technical fact underneath it rather than only good intentions.

Analysis proceeds in a separate layer, and keeping the layers distinct is the professional core of this workflow. She does not write her analytic notes inside the transcript entries. Instead, each interview gets a working entry — coded by the same interview code — where she records themes, tensions, and the passages that matter, paraphrased or briefly quoted under the terms the client agreed. Those working entries are linked in the wiki: a wiki page per emerging theme gathers the codes from across the eight interviews, so that by the fifth interview she can see that what one person called a communication problem, another called a trust problem, and a third described without naming at all. The wiki holds the pattern. The encrypted entries hold the evidence. The working entries hold her reasoning between the two. If the client later asks how a conclusion was reached, she can move from theme to working entry to transcript in a straight line. If the client asks for the underlying material to be destroyed at the end of the engagement, she knows exactly which entries are the transcripts, because they were never dissolved into the general notebook.

At reporting stage, nothing confidential leaves by accident through the tool itself. VaultBook makes zero network requests; there is no sync stream quietly carrying a copy of a newly created entry to a server while she works. The report she sends is a document she exports and checks, as with the literature review. What VaultBook changes is everything before that moment: recording, cutting, transcription, storage, and analysis all happening in one local place, with the most sensitive layer encrypted entry by entry. For interview-based work, that coherence is the migration’s real proof. The graph thinking survived — themes linked, patterns visible, reasoning traceable — without asking confidential material to live the exposed life of an ordinary note.

A field and archive day, fully offline

The third workflow leaves the desk. A consultant’s research occasionally involves a place: a site visit, a day in an archive reading room, a records office, a location where the reality behind the paperwork can be seen. These days share practical features. Connectivity is poor or forbidden. Material arrives in mixed forms — photographs, photocopied or scanned documents, handwritten observations, a conversation in a corridor that reframes the morning’s reading. And the cost of losing the day’s capture is high, because you cannot simply go back next week and see the same thing in the same state.

The day starts before departure, with a small act of preparation that offline work rewards. The consultant creates the day’s entry in advance: date, place, purpose, the questions she is going to answer, the permissions she has been given for photography and copying. She opens the vault once at home to confirm everything she needs is present — previous entries on this project, the relevant literature summaries, the document list she intends to request. Because VaultBook is a single-file HTML application working locally, there is no question of whether a notebook has synced, or whether a particular page will be available in a basement archive with no signal. The vault she checked at the kitchen table is the vault she will open on site. That certainty changes behaviour: she stops taking defensive screenshots of her own notes, a habit Roam’s dependence on connectivity quietly taught her.

On site, photographs do a large share of the capture. In the Photo and Video Explorer, the day’s photographs are not just pictures dumped into a folder; their EXIF data — the recorded time and, where the camera supplies it, location information — travels with them, so the sequence of the day can be reconstructed honestly later. She photographs the exterior, the relevant interior details, the documents she is permitted to photograph rather than copy, and the reference labels and shelf marks that future-her will need to cite them properly. Between photographs she writes in the dated entry: what she is seeing, in order, with the small observations that photographs cannot hold — the condition of a file, the archivist’s remark that a series is incomplete for a particular year, the discrepancy between what the catalogue says and what the box contains. Because the entry is dated and the photographs carry their own timestamps, the two records corroborate each other when she writes up.

Documents arrive as PDFs, often awkwardly: several separate scans from the archive’s own scanner, one report split into three files, a long document photographed in sections. The PDF tools earn their place here. She merges the split scans into the single document they actually are, on site, while she can still check the merged result against the original on the desk in front of her and notice that page fourteen is missing before the box goes back to the strongroom. That timing is everything. The same merge done a week later at home would have produced an incomplete document and an apologetic email. Done on the day, it produces a complete record and a note in the day’s entry recording that the merge was checked against the original.

Nothing about the day requires a network, and it is worth pausing on the sentence in the original plan for this workflow: everything syncs with nothing, because there is no server. That is not a limitation being spun as a virtue. It is an accurate description of the custody model, and on a field day its value is concrete. There is no failed sync to resolve on the train home, no conflicted copy of the day’s entry created because a laptop and a phone both touched it while offline, no partial upload of archive photographs to a cloud account over a station’s public Wi-Fi. The vault at the end of the day is one file, on her machine, containing the dated entry, the photographs with their metadata, and the merged documents. Her backup routine — copies of that file, kept in separate places — is the whole of the safety story, and it is a story she controls and can describe to a client without footnotes.

The write-up the following day closes the loop. The day’s entry becomes the spine of a project entry: photographs selected and captioned, the merged documents summarised and labelled, the open questions either answered or carried forward explicitly. Material from the archive enters the same searchable record as the literature and the interviews. A place, which in Roam might have been represented by a page of typed notes and a separate camera roll slowly separating from its context, is here one dated, illustrated, document-backed part of the project. Three workflows, three different pressures — assembly, confidentiality, disconnection — and in each case the migrated system did not merely store the work. It shaped the work in ways the consultant would now be reluctant to give up.

A Realistic Migration Checklist You Can Finish in a Weekend

Most migrations fail socially before they fail technically. They are planned as open-ended improvement projects, they expand, they stall on a wet Wednesday two weeks in, and the old system keeps being used by default until the half-moved new system is trusted even less than the old one. A six-year Roam graph deserves better than that, and it does not need it. What follows is a weekend-shaped plan: Friday evening for exports and decisions, Saturday for structure and attachments, Sunday for protection, testing, and backups. It assumes the earlier stages of this guide — inventorying the graph, deciding what not to move, preparing the export — are understood. This checklist is the doing, sequenced so that each stage leaves you with something verifiable before the next begins.

Friday evening: export, freeze, and set up.

• Export the complete Roam graph in every format Roam offers you, not only the one you expect to import from. Keep the exports in a folder dated today, and treat that folder as an archive, not a working directory. You are not tidying it. You are preserving the ability to check, months later, what the graph actually contained on the day you left.
• Make a second copy of that export folder somewhere separate from your main machine before you do anything else. The migration has not started and you have already done the most important backup of the weekend.
• Write a short freeze note to yourself: from this moment, new substantive notes go into a single holding entry or a single plain document, not into Roam. A graph that keeps changing while you move it will never reconcile. Small captures are fine; structural work in the old system stops tonight.
• Decide the handful of structural questions now, while they are cheap: the label scheme for the main areas of your practice, how client material will be coded, which categories of entry will be encrypted as a matter of routine, and what you are deliberately not migrating — old daily notes with no lasting value, dead project pages, duplicated literature stubs. Write those decisions at the top of your migration notes. Saturday-you will be tempted to relitigate them; the note is the answer.
• Set up VaultBook itself, create the vault, and spend twenty minutes learning where things are with no real material at stake: create a test entry, label it, edit it, find it again with search, delete it. Learning the interface on a test entry on Friday is far cheaper than learning it on a confidential transcript on Saturday.
• Gather the attachments while you are fresh enough to be systematic: the PDF library, the audio files, the image folders that your Roam pages referenced from outside the graph. Make an inventory count — how many PDFs, how much audio, how many images — because Saturday’s completion check is simply whether those numbers made the crossing.

Saturday: structure first, attachments second, polish last.

• Import and build the skeleton before importing everything. Establish the top-level structure — the wiki pages for your main topics and ongoing areas, the label scheme as actually implemented, the project entries for live work — and check that the skeleton reads like your practice, not like a software default.
• Bring in the core written material next: daily notes you decided to keep, literature entries, project pages. Work area by area rather than alphabetically. Finishing one area completely, and checking it, teaches you the transformation patterns — how links arrive, how references have been handled, what needs manual repair — while the remaining areas can still benefit from what you learned.
• Repair connections as you go, but to a standard, not to perfection. A link that matters for live work gets fixed properly. A link inside a three-year-old daily note that pointed at a fleeting thought can be left as plain text without guilt. The test is always whether future-you, mid-commission, would be misled or slowed by the imperfection.
• Attach the PDFs after the entries they belong to exist, so each document lands with its context rather than in an undifferentiated pile. Use the File and Folder Analyzer where a folder’s contents need checking against your inventory, so a missing subfolder is caught today rather than during a client crisis in November.
• Bring in audio and images in the same spirit: interview recordings with their coded names, photographs with their context. Do not transcribe or re-caption everything on Saturday. The goal is presence and correct placement, not finished processing.
• At intervals through the day, use the dynamic tabs to keep the areas you are working on open side by side — the migration notes in one, the area in progress in another — and at the end of each area, run the count check: entries present, attachments present, one known item opened by hand and read.
• Stop on Saturday evening with a written gap list, not a feeling. Every known imperfection goes on the list with a note of whether it blocks live work. Most will not. The list is what makes Sunday’s testing honest.

Sunday: encryption, search tests, backups, and the working start.

• Encrypt first, while your attention is freshest. Work through the categories you decided on Friday: full interview transcripts, sensitive client material, anything containing personal data about identifiable people. Encrypt entry by entry, and keep a simple record — by code and category, never by unnecessary detail — of what you encrypted, so the protection is auditable by you later.
• Run the verification tests below, all of them, and write down the results. Do not skip a test because the previous one passed; each tests a different way the migration could be silently incomplete.
• Set the organisational aids that make the first working week easier: check the calendar entries for live commissions, review what the Due and Expiring sidebar is showing for anything time-sensitive — a client deadline, an expiring document, a follow-up owed — and build one Kanban view for the migration gap list itself, so unfinished repairs become tracked tasks rather than a source of ambient unease.
• Make the backup copies that end the weekend: at minimum, a copy of the vault file on a separate device or medium, and a copy kept apart from the machine entirely. Then prove one of them opens.
• Finally, write the first real entry of the new working life — Monday’s daily note, or the opening entry of the next commission — in VaultBook, and close Roam.

The verification tests, in full. First, search for a known phrase that exists only inside an attached PDF — a distinctive sentence you did not summarise — and confirm the search finds it in the document, not only in your notes about it. Second, disconnect from the network entirely, close and reopen the vault offline, and open three entries of different kinds: an ordinary note, a literature entry with its PDF, and a project entry. Third, open an encrypted entry with your credentials, read it, and confirm that without them it presents as protected. Fourth, deliberately restore something from version history: edit a test entry, then recover its earlier state, so that you have performed the recovery once in calm conditions rather than first attempting it in a panic. Fifth, pick one Roam page you care about, chosen at random rather than by importance, and account for everything on it — text, links, attachments — in its new home. A migration that passes these five tests on Sunday will still have a gap list. It will not have hidden holes, and that is the standard a working consultant actually needs.

Questions Roam Users Ask Before They Move

Every long-term Roam user asks some version of the same questions before a move, and they deserve answers at the same level of honesty they would apply to their own clients’ questions. Some of what follows is reassuring. Some of it is a plain statement of a trade-off. A migration chosen on honest answers tends to stay chosen; a migration sold on evasions tends to be reversed at the first difficulty, at double the cost.

Will my links survive?

Largely, yes — in the form that matters most. The connections between your notes are the graph’s real value, and they are carried into VaultBook’s entries, labels, and wiki structure, where linked ideas remain linked and navigable, and related notes continue to surface connections between entries. What you should expect is translation, not photocopying. Roam’s linking grew organically over six years, through several of your own conventions, some of them abandoned halfway. The migrated structure will be cleaner in some places and will need hand repair in others, particularly where a link pointed at a page whose name changed, or where your meaning was carried by a nesting habit rather than by an explicit link. The realistic promise is this: the web of your thinking survives, the live and important connections can be verified and repaired over a weekend, and minor imperfections in old, cold material can be fixed lazily, when and if you next touch it. What does not survive is any excuse to keep paying rent on a graph you are afraid to move because the links feel magical. They are not magic. They are your own connections, and they travel.

What happens to block references?

Here the answer has to be exact: block references are transformed, not preserved one-to-one. A Roam block reference points at a single block — one bullet, one paragraph — inside another page, and lets that fragment live in two places at once. VaultBook’s model is entry-based rather than block-based, so the migration resolves those references into the new structure: the referenced content arrives as text, as a link to the entry it came from, or as part of the wiki connection between the two, depending on how the reference was used. In practice, most block references in a mature graph fall into two groups. The majority were really citations — pointing at a passage in a literature note or a line in a transcript — and those survive well as explicit references to the source entry, arguably more readably than before. A minority were genuinely structural, where one block did duty in several arguments at once; those need a decision during migration, usually to give the fragment its own small entry, which the wiki then links from each place that uses it. That is a small amount of real work, concentrated in your most-used material. Anyone who tells you block references cross over perfectly is not being straight with you, and you should plan the hour or two of repair work instead of being surprised by it.

Can I search inside PDFs?

Yes, and for a research practice this is one of the changes people feel most in daily use. VaultBook’s search reaches into attached documents, including text recovered by OCR from scanned material, alongside its search across entries and its semantic question-and-answer search, which lets you ask a question in ordinary language and be led to the material that bears on it. The practical consequence is the one illustrated in the literature review workflow: the boundary between your notes and your sources stops being a boundary search respects. A caveat in a PDF you never summarised, a table in a scanned chapter, a phrase in a report — these are findable from the same search as your own entries. The honest limits are the limits of the underlying material. A clean born-digital PDF searches beautifully. A poor scan of a faint photocopy will OCR imperfectly, and a handwritten document is a photograph, not searchable text. But the direction of travel is clear: material that in Roam lived outside the graph, reachable only if you remembered it existed, is inside the searchable record now.

What if I collaborate?

Then you should hear the limit plainly: VaultBook is personal-custody first, and live multi-user editing is not its strength. There is no shared live graph where a collaborator’s cursor moves through your page as you watch, no comment thread unfolding in real time inside an entry, no simultaneous editing of the kind that cloud notebooks are built around. If your practice depends on a team thinking together in one document at the same moment, VaultBook will not replace the tool that does that, and this guide will not pretend otherwise. What most independent consultants actually do, however, is collaborate at the boundaries rather than at the centre: they share a briefing, exchange a document, receive a client’s comments, send a draft. All of that continues unchanged, because it was always done in documents, not in the notebook. The vault is the workshop; collaboration happens with what leaves the workshop. Many consultants find, once the distinction is stated that clearly, that the live-collaboration they thought they needed was actually a habit formed by a tool that put everything in a shared cloud by default. For the genuinely shared parts of a project, use a shared tool for those parts, deliberately and narrowly, and keep the research record — especially anything confidential — under your own custody. That is a defensible professional architecture, not a compromise to apologise for.

What if I lose the file?

This is the question that follows naturally from a one-file design, and it has a real answer with two layers. The first layer is version history inside the vault, which protects you against the commonest losses: the entry edited badly, the passage deleted in a tired moment, the change you want to walk back. Earlier states can be recovered, and Sunday’s checklist asks you to perform one recovery as a test so the mechanism is familiar before it is needed. The second layer is backup, and here honesty requires saying that a single local file concentrates responsibility as well as control. There is no provider’s infrastructure quietly keeping copies for you. Your protection is the copies you keep: the vault file backed up to a separate device, a copy kept apart from your machine, copies refreshed on a rhythm that matches how much a week’s work is worth to you. That is more responsibility than a cloud account asks of you, and it is also more actual control — your backups are files you can hold, count, open, and test, not a recovery process you would have to request from a company at the worst moment of your year. Consultants already live this way with client deliverables and financial records. The vault asks to be treated with the same adult seriousness, and rewards it with the same certainty.

Can I go back to Roam if it does not work out?

Yes, because the exit was preserved before the entrance was used. Friday evening’s exports — the complete graph in the formats Roam offered, archived and copied — remain untouched by everything that follows. Your original material also remains readable in its exported forms independently of any tool. If the migration failed your tests, you could resume work in Roam from the position you froze, having lost a weekend rather than six years. Two qualifications keep the answer honest. Work done in VaultBook after the move would need to be carried back deliberately, entry by entry, if you reversed after months of use; the clean reversal is the early one, which is exactly why the weekend plan front-loads verification. And most people who ask this question find its real function is permission to begin: knowing the door back is open, and labelled, and that the archive exists, is what makes it possible to test the new system seriously rather than anxiously. Keep the exports. Test honestly. Then decide on evidence.

Your Graph, Finally in Your Own Hands

Six years is a long time to think inside one tool. A graph built day by day across that span is not really a database, whatever the software calls it. It is the external shape of a working mind: the questions you kept returning to, the sources you trusted and the ones you learned to discount, the clients whose problems taught you things you carried into every later commission, the interviews you handled carefully because people had trusted you with candour. When a consultant contemplates moving that record, the hesitation is not really about features. It is about whether something that personal can be carried across intact, and about whose hands it will be in on the other side.

That second question is the one this migration finally answers in your favour. For six years, the graph lived under terms set elsewhere: on servers you did not control, behind an account you depended on staying in good standing and in business, reachable when a network and a service both agreed to let you reach it. None of that implies bad faith by anyone. It is simply the ordinary architecture of cloud software, and its ordinary consequence is that custody of your most valuable professional asset — the accumulated record of your thinking — was shared, conditional, and revocable in ways you could not inspect. Moving to VaultBook changes the architecture, and therefore changes the answer. The vault is a single file. It opens in a local application that makes zero network requests. It works in an archive reading room and on a train and during an outage with the same indifference to circumstance. Its most sensitive entries are encrypted individually, under your control. Its history is kept in its version history, and its safety rests on copies you make, keep, and can test. Custody, here, is not a metaphor or a marketing word. It is a description of where the file is, who can read it, and what has to go right in the world before you can open your own notes — which is now: almost nothing.

It would be wrong to end on a note of pure triumph, because the honest parts of this guide were not decorations. Block references were transformed rather than preserved. Live collaboration is genuinely not what this tool is for. A single file asks you to take backups seriously, forever, as a professional habit rather than a setup step. Those are real costs, and you paid some of them over the migration weekend in hours of repair and decision-making. What the three workflows showed is what the costs bought: a literature review assembled from notes and sources in one searchable place; a confidential interview series recorded, cut, transcribed, and analysed without the material ever leaving your machine, its transcripts sealed entry by entry; a field day captured completely, offline, in a vault that needed nothing from anyone’s server to be whole by evening. Those are not slogans about a product. They are descriptions of work, done the way a careful consultant wants it done.

There is also a quieter change that only becomes visible a few weeks after a move like this. When the tool cannot be blamed on a connection, a sync, or a service, the habits of the practice become your own again. You back up because the record matters, not because a dialog box nags you. You encrypt the entries that deserve it because you made promises to the people in them. You keep the structure clean because future-you is the only search engine that has to live with the mess. And the graph itself — daily notes, literature, interviews, projects, the whole six years and everything since — sits in your hands in the most literal sense available to digital work: one file, yours, portable to any machine you choose, readable on your say-so alone.

Start on Friday. Export everything, copy it twice, freeze the old graph kindly and without drama. Do the structured work on Saturday, the protective work on Sunday, and run every test as if a client were watching — because in the only sense that matters, one is: the client is you, three years from now, mid-commission, reaching for something you noted today. Build the vault that person deserves to find. Your graph was always your thinking. Now it is your property in fact as well as in feeling, and that is where it should have been all along.