The Questions to Ask Before You Move a Novel Into a New App
Moving a hundred thousand words rewards a short list of questions asked before the move, not after: a kind of care a photo library never needs. What arrives on the other side can be quietly different from what left — a chapter flattened into one long wall of text. That never shows up on a features page, so it has to be asked directly.
Does it come in as it is, or does it come in flattened?
Import is the first real test. A serious attempt reads your existing structure, whatever the tool you use now, and rebuilds it: chapters stay chapters, folders stay folders, any labels or statuses you'd set travel with the files they belonged to. A weak attempt reads only the words and drops everything else, so a carefully organized binder becomes one long scroll you have to re-divide by hand. The way to check is small: export just a chapter or two, import that sample on its own, and look at what survived. Don't test with your whole manuscript first. Test with the part you'd mind losing least, so a bad surprise costs you an afternoon instead of a year.
Look closely at what "structure" means to the app you're testing. Some only preserve a flat list of chapter titles and lose anything nested more than one level deep, so a folder inside a folder inside a part collapses into a single tier. Others keep a synopsis or a status tag attached to each scene, which is easy to lose if the new app has nowhere to put that information and simply discards it during the move. A short synopsis line under a chapter title, in the sample you tested, is a fast way to tell which kind of app you're looking at.
Is the file something else could open, or only this one app?
Ask what format your project is actually stored in day to day, beyond what it can export to on request. Some apps keep your manuscript in a private database file that nothing else can read, so the only way out is that app's own export function, working correctly, every time. Others keep your project as ordinary files on disk, in a format a plain text editor could open directly, with no export step required at all. The second kind leaves you fewer ways to get stuck, because there's no single feature standing between you and your own words.
Which formats can leave, and how many clicks does it take?
Getting in matters less than being able to get back out, because getting out is what proves nothing is actually stuck. Ask what a full export produces: a single file, several files, a format you recognize. Ask whether that export includes everything, or leaves footnotes, comments, and formatting behind. And ask how long the export takes to run, because a process that only works for short documents will surprise you on a manuscript-length file, usually at the worst possible time.
Can you get back to yesterday's chapter?
Most apps save constantly now, which sounds reassuring until you realize constant saving also means a bad edit gets saved just as fast as a good one. What you actually want is a real version history: a way to look at the chapter as it stood yesterday, or last Tuesday, and pull an earlier passage back without losing today's work in the process. Ask specifically how far back it goes, and whether restoring a version is something you do yourself in a few clicks, or something that requires writing to support and waiting.
Is there a plain copy of your own, sitting on your own disk?
This is the question people skip, and the one that matters most. Even a good export system is still something you have to remember to run, on a day you're busy writing rather than thinking about backups. A tool worth trusting with a novel should be writing a plain, readable copy to your machine on its own, automatically, without you asking for it each time, in a format you could open years from now with whatever happens to still exist. That copy is your insurance against every other answer on this page turning out to be wrong.
What actually breaks, and who says so
Every import and export process has edge cases, and manuscripts collect the strange ones: a curly apostrophe that turns into a stray symbol, a table of names and dates that loses its columns, a footnote that detaches from the word it was pinned to, a chapter that gets flattened onto a single line with every paragraph break gone. The tools worth trusting say so plainly, usually in their own documentation, rather than leaving you to find out mid-project. If a help page can't tell you what doesn't survive the trip, that silence is itself an answer, and the sample test from the first question above is what catches it before it matters.
How Scrin does it
Bring your project in as it is: chapters, folders, labels and notes intact. Version history keeps every state restorable, so even your own regrets are recoverable. A daily plain-text copy goes to your own disk automatically, so nothing we do is ever needed to read what you wrote.
Try Scrin early — leave your email and we'll open the web version to you.