Moving a novel out of Scrivener: safely.

You have decided to leave. The reason varies: a new machine, a collaborator who lives in Word, a slow accumulation of friction, or simply that after four years the binder has become a place you brace yourself before opening. The reason matters much less than the thought that turns up about ninety seconds later, usually at eleven at night: is the book actually stuck in there?

It isn't. But that reassurance is only half true, because the manuscript and the project are not the same object. The manuscript will come out fine. The project (the labels, the corkboard you spent an afternoon arranging, the eighty synopses, the note in chapter nineteen about why the timeline no longer works) is a different proposition. Some of it travels. Some of it can be photocopied. Some of it is a behaviour rather than a thing, and behaviours do not move between applications.

So this is a procedure. It runs in the same order whether you are going to Word, to Ulysses, to Obsidian, or to a dated folder on an external drive you never intend to open again. The destination changes almost nothing about the method, which is the first useful thing to know.

Nothing happens until you have a copy you have actually opened

The first rule of any migration is that the original survives it untouched. The second is that you do not get to believe in a backup you have not restored. They are two rules because writers reliably obey the first and skip the second, and the second is the one that saves you.

Scrivener is unusually good about this, and it is worth knowing what it has already been doing on your behalf. Automatic backups are on by default and run when you close a project, writing a compressed ZIP into a dedicated folder: on macOS inside `/Library/Application Support/Scrivener/Backups` in your home folder, on Windows inside `\AppData\Local\LiteratureAndLatte\Scrivener\Backups`. The Backup pane in Settings (macOS) or Options (Windows) has a button that opens it for you. The catch is that these rotate: you choose how many are kept (three, five, ten or twenty-five) and once the ring is full, the oldest is overwritten. A rotating backup protects you from a bad afternoon. It does not protect you from a mistake you notice six weeks later.

So take a backup that sits outside the rotation and cannot be quietly consumed by it. Literature & Latte provide the tool directly: File ▸ Back Up ▸ Back Up To…, which lets you choose the destination, stamps the date and time into the name, and will zip the result. Put it somewhere the app has no idea about: an external disk, an archive folder with a boring name. Then do the part everyone skips.

1. Unzip the backup somewhere temporary, well away from the live project.
2. Open the unzipped copy in Scrivener and confirm it is your book: the right chapters, the right word count, your most recent day's writing present at the end of it.
3. Close it, delete the temporary unzipped copy, and keep the ZIP.

Four minutes, and it converts a hypothesis into a fact. Every horror story about a lost novel has the same shape: there was a backup, and it turned out to be empty, or four months stale, or a folder the application politely declined to recognise. A backup is not a file. It is a file you have opened.

A .scriv is a folder of RTF files with an index on top

The thing that makes migration feel dangerous is not knowing what you are holding. So open the box. On Windows a `.scriv` project is exactly what it looks like: an ordinary folder you can browse. On macOS it is a package: it presents itself as a single file, and Control-clicking it and choosing Show Package Contents reveals the same folder underneath. Literature & Latte's own guidance is blunt about the consequence: the whole folder is the project, and it must be moved and copied together.

Inside, the structure is reassuringly ordinary. There is a `.scrivx` file, which is XML: the binder tree, every item's title, and the project-wide settings. There is a `Files` folder holding a version marker, your named styles, a regenerable search index and your writing history. And there is `Files/Data`, which is where the book lives: one folder per binder document, each named with a long unique identifier, each containing a `content.rtf` with the actual prose in it. Alongside that sit a `synopsis.txt`, a `notes.rtf` for the inspector notes, a small XML file holding comments and footnotes, a `snapshots` folder if that document has any, and for imported pictures and PDFs, the original file itself.

Your novel is not locked in a database. It is several hundred RTF files in folders with unhelpful names.

That is genuinely good news, and it is why the honest answer to "can I get my book out" is yes even in the worst case. RTF is a documented format every word processor of the last thirty years can read. If Scrivener vanished tomorrow and you had nothing but the folder, your prose would still be there in files that open by double-clicking. Writers on Literature & Latte's own forums recover lost documents exactly this way: go into `Files/Data`, open the RTFs, find the one you want.

Now the honest counterweight, because the same fact is a trap if you overread it. Those folders are named with identifiers, not with chapter titles. A novel with a hundred and forty binder items is a hundred and forty near-identical folders in no meaningful order, and "the text is in an open format" is small comfort when finding chapter thirty-one means opening RTFs one at a time. The prose is portable; the arrangement of the prose lives in the `.scrivx` index, which is at least plain XML listing each item's title beside the identifier of the folder its text sits in. A patient human can rebuild the map from that. But it is a fire escape, not a doorway.

Compile decides what shape the book arrives in

This is the part to think hardest about, and the part most people rush, because it looks like a save dialogue and is nothing of the kind. Scrivener offers two quite different ways out, and choosing the wrong one causes most migration misery.

Most people need both, in that order. Compile produces the thing you will work in next; export produces the thing you put on the shelf. Doing only the first leaves your notes and synopses behind; doing only the second leaves you with a folder of fragments and no manuscript.

Your chapter headings may not exist yet

Here is the single fact that explains more failed migrations than any other. In Scrivener 3, the chapter headings you see in a compiled manuscript are frequently generated during compile. A Section Layout can carry a title prefix, and that prefix can contain placeholder tags that Scrivener replaces as it builds the file: the well-known one being a tag that turns a document's position into "Chapter One", "Chapter Two" and so on. There is a full list of these in the application's own Help menu. Which means the words "Chapter Seventeen" may appear nowhere in your project. They are computed on the way out.

Follow that through and the implication is immediate. Compile with a layout that emits nothing but body text (perfectly reasonable if you have been submitting to agents who want no headings) and the receiving application gets a fifteen-hour block of prose with no boundaries in it, and does something arbitrary with that. Compile with headings, but as plain bold centred text rather than a real heading style, and an importer looking for structure still finds none, because visually-bold-and-centred is not a signal, it is a font choice.

So the aim is to compile so that the structure is legible to whatever reads the file next. Scrivener does not map to Word's built-in heading styles by default when compiling to DOCX, but the machinery is right there: define the styles you want in the compile format's Styles pane, then assign them to the titles in Section Layouts. Twenty minutes of fiddling the first time, and the difference between arriving with a navigable document and arriving with a wall, which is also, incidentally, the groundwork for formatting the finished edition later.

1. Decide what the destination actually reads. Most tools detect chapters from heading styles; some detect page breaks; a few want one file per chapter. Find out before you compile rather than after.
2. Check that every document you want is included. Scrivener has a per-document "Include in Compile" setting, and a chapter with it switched off simply is not in the output: silently, which is why it is the most common reason a compiled manuscript is mysteriously short. The Outliner shows the whole set at once as a column.
3. Make the chapter headings real: proper heading styles, or (if the destination does not understand styles) a consistent line of text you could find with a single search.
4. Compile once to RTF as well as to your target format. For a word processor, RTF is consistently the most reliable carrier for footnotes, and it costs a minute.
5. Open the result in something other than Scrivener before you go any further. A file you have not opened is the same untested hypothesis as a backup you have not restored.

Separators deserve the same suspicion. A scene break in Scrivener is often not a typed character at all but the boundary between two binder documents, rendered at compile time as a blank line or a hash. Compile with the separator set to nothing and several hundred scene breaks quietly vanish, and you will not notice for a month.

Three tiers: what travels, what photocopies, what stays

The anxiety of migration mostly comes from treating a project as one undifferentiated blob that might or might not survive. It is not one blob. It is three distinct categories with three distinct answers, and sorting them before you start removes most of the dread.

Travels: the manuscript, more or less intact

Prose, paragraph structure, italics and bold, scene breaks, chapter order and images placed inside the text all move cleanly through a compile to RTF, DOCX or ODT: the overwhelming majority of the work by volume, and the part nobody actually loses. Named styles travel too, if you have used them and configured the compile format to carry them.

What goes wrong here is small and cosmetic: smart quotes occasionally changing font where a document has a mixed formatting history, non-breaking spaces not always surviving, the odd stretch of italics dropping out where the underlying formatting was inconsistent to begin with. Search-and-fix problems, not data loss.

Photocopies: the metadata, as data rather than as behaviour

This is the tier people write off too early. A surprising amount of the project's supporting apparatus can be got out: just not as the living thing it was. Labels, statuses, custom metadata, synopses, word counts and target information can all leave in one go: switch to the Outliner and use File ▸ Export ▸ Outliner Contents as CSV, which writes out every column of metadata (or only the ones currently visible) separated by commas, tabs or semicolons. That single file is the closest thing to a machine-readable dump of your project's organisational layer, and it opens in any spreadsheet. Comments and annotations have their own export, which can include clickable links back to the sections they came from. Snapshots can be exported as files, individually or in bulk. And the outline itself can go out as OPML: titles only, titles with synopses, titles with notes.

What none of that preserves is the connection. A label was a colour you could filter by; in a spreadsheet it is a word in a column. A comment was anchored to a clause; exported, it is a note that mentions a section. A snapshot was a version you could diff against the current text; exported, it is an RTF with a date in the name. The information survives, the behaviour does not, and the honest way to plan a migration is to decide item by item which of these you actually consult and which you have merely accumulated.

Stays: the things that were never files

Freeform corkboard positions (the arrangement, as opposed to the cards) are a property of the project. So are collections and saved searches, keyword colours, your compile formats, targets and writing history. Nobody is withholding these from you; they are descriptions of how one application displays your work, and there is nowhere in a different application for them to land.

Which is worth a moment of reflection rather than resentment. If an afternoon of corkboard arrangement is genuinely load-bearing, screenshot it, or write down in three sentences what it was telling you. Nine times out of ten that reveals a thinking aid you have already finished thinking with. Occasionally it reveals that the corkboard was your actual outline: in which case write it down properly, as an outline, in words, which you will be glad of whichever application you end up in.

Research is a second migration, and it is easier than the first

Do not move the research at the same time as the manuscript; combining them turns one clear job into two muddled ones. The manuscript needs to be usable in the destination tomorrow morning. The research mostly needs to be findable at some unspecified point in the next three years. The second bar is much lower, and a folder of PDFs and images with sensible names on a disk you control clears it completely.

The tool here is the export path rather than compile: exporting files reproduces the binder's folder structure on disk, so a research folder that was organised in Scrivener arrives organised. Imported PDFs and pictures were never converted in the first place (they have been sitting in the project as their original files all along) so they come out as exactly what went in. Saved web pages are the awkward case, since what got stored depends on how you imported them. If one matters, print it to PDF now while it is in front of you; link rot will eat the original long before your next draft.

Whether the research goes into your new application at all is a real question. Plenty of writers want their reading beside the prose, and a tool with somewhere to put research alongside the chapters makes that worth doing. Plenty of others keep it in the filesystem forever and are perfectly happy. The arrangement that fails is the half-migrated one, where a third of your sources are in the new app, a third are still in the old project, and you cannot remember which is which.

Verify like you do not trust yourself, because you shouldn't

The dangerous moment is not the export. It is the twenty minutes afterwards, when the new copy is open and looks fine, and "looks fine" gets promoted to "is fine" without anything in between. A hundred-thousand-word manuscript can lose an entire chapter and still look fine, because you are not going to read a hundred thousand words to check. So check the things that break, in an order that catches the worst problems first.

1. Word count, against the right number. Scrivener's Project Statistics gives a Draft count that reflects your compile settings (what is actually going to be included) while a selection count does not. Compare against the Draft figure, not the raw binder total, or you will spend an hour chasing a discrepancy that turns out to be your front matter.
2. Chapter count, in the destination and in the binder. This is where an unticked "Include in Compile" shows itself, and it takes thirty seconds.
3. The beginning and end of every chapter. Not the middles: truncation and mis-splitting happen at boundaries. On a forty-chapter novel this is fifteen minutes and it is the highest-yield check on the list, because a chapter that has swallowed the one after it is obvious from its last line.
4. The weird chapters. Every book has four or five: the one with the letters or the text messages, the one with an epigraph, the one with verse, the chapter with a table, anything with footnotes. Formatting damage clusters in exactly these places.
5. Three known strings: a phrase that appears exactly once, a phrase you know is italicised, and a name with a diacritic. If the italics are gone or the diacritic has become a question mark, you have an encoding problem: better found now than in a proof.
6. Scene breaks. Search for whatever marker you compiled them as and count the hits. Zero hits in a book that has scene breaks means your separator setting ate them.

If something is wrong, resist the urge to patch it by hand. Go back, change the compile settings, compile again. Hand-repairing an import is how you end up with two divergent books and no authority about which one is correct. The export is cheap. Run it again.

Keep the Scrivener project forever, not until it looks fine

When the new copy checks out, the instinct is to tidy up. Resist it entirely. Not for a month, not until you are confident: forever.

The things you go back for are never the things you anticipated. The chapter you cut in the second draft and half-remember as better than what replaced it. The note explaining why the sister's name changed, written eighteen months ago in a document nobody would think to export. The URL for the source on eighteenth-century rope-making. The version of the opening from before you took the advice of a workshop that turned out to be wrong. None of that is in your manuscript. Some of it is in the project.

You will not miss the project until the day you need one specific thing out of it, and on that day nothing else will do.

The archive costs almost nothing. A novel-sized project with research in it is tens or low hundreds of megabytes; zipped, it is smaller than a film you have already forgotten downloading. Name it so it will still make sense in a decade: the book's title, the date, and the word Scrivener in the filename so future-you knows what made it. Put a second copy somewhere physically different, then leave it alone.

The one thing worth adding is a five-line text file beside the archive saying what the project was, what version made it, what you exported and what you knew you were leaving behind. That takes four minutes and it is the difference between an archive and a mystery. Archaeology on your own work is harder than it sounds, and you are not going to remember.

Any tool you cannot get out of is a risk: including this one

Everything above generalises, and it is worth saying so plainly, because the specific case of Scrivener is much less interesting than the general problem it is an instance of. Writers of long books commit years to a single application. The application has a business, a roadmap, an owner and a lifespan; you have exactly one novel.

Stu Maschwitz made the argument sharply in Held Prisoner by File Formats, and while his own resolution (everything to plain-text Markdown, forever) is more ascetic than most novelists want, the diagnosis is exact: he described working to support the system rather than the other way around. That is the state to watch for, and it announces itself long before you notice consciously.

But the useful version of the lesson is more specific than "beware proprietary formats", because plenty of open formats make perfectly good prisons and plenty of proprietary ones let you leave without a fuss. Scrivener comes out well on this test: the text is RTF, the index is XML, the folder is a folder, and the export options are extensive. Whatever else is true, Literature & Latte did not build a trap. The test that actually predicts your future has three parts.

1. Can you get the whole thing out, or only the manuscript? Every writing tool ever made will give you your prose. The question is what happens to the other forty per cent of the work.
2. Does the export round-trip? Open the file the app produces somewhere else and see whether the structure survived. An export that produces an unstructured wall of text is a compliance feature, not an exit.
3. Have you ever actually run it? Almost nobody passes this one. An export path you have never used is a promise, and you find out whether it was true on the worst possible day.

Which is the closest thing to a moral this article has: export your book today, from whatever you are using right now, and open the result. Not because you are leaving, because a working export is the only form of ownership software can actually offer you, and it is worth confirming annually, like a smoke alarm.

That applies to us as much as anyone. ChapterMuse keeps a book on your own machine and can put the whole of it into a single backup file, alongside the usual exports. We would rather you ran those on day one than on the day you leave. Any tool that would rather you didn't is telling you something, and choosing between writing applications is largely a matter of listening for it.

Meanwhile: back up the project, verify the backup, compile with intent, export the metadata, check the boundaries, archive the original, label it. The whole thing is an afternoon. The alternative (discovering in eighteen months that chapter thirty-one has been missing since the move) is not.