Before moving an existing manuscript into different publishing software, import a representative copy and compare it with the original. Test structure, special content, editability, and export rather than judging only the first screen. Record losses and repair effort, then decide whether the new workflow solves enough of the original problem to justify migration. Keep the authoritative source recoverable throughout the trial.
Define the problem the change should solve
Write down why the current workflow is inadequate. The manuscript may be difficult to reorganize, an export may require repeated manual repairs, or collaborators may struggle to identify accepted changes. Each problem suggests a different test. A new interface that feels cleaner does not necessarily resolve the issue that made revision difficult in the first place.
State the result that would make migration worthwhile. For a reference guide with many tables, success might mean preserving editable data and reducing repair after chapter moves. For a novel, it might mean retaining section structure while improving navigation during revision. Keep these expectations separate from optional conveniences. The trial should answer whether the software supports the actual project, not whether its feature list is longer than the current tool's.
Choose a sample that reveals likely losses
Copy a chapter containing the manuscript's demanding elements. Include headings, notes, images, captions, tables, or intentional special paragraphs where they are part of the book. Also include a normal section for comparison. A plain page of prose is useful for an initial sanity check, but it cannot reveal how the workflow handles the elements most likely to create migration work.
Preserve the original sample and record its source version. Note what should remain editable and what relationships matter, such as a caption belonging to a particular figure. Use stable labels for those items so they can be located after import even if pagination changes. The comparison needs evidence from both sides; relying on memory makes subtle losses easier to overlook.

Compare meaning and structure after import
Inspect the imported sample from beginning to end. Check that paragraphs remain in order, headings retain their roles, and intentional breaks are distinguishable. Open tables and notes to confirm that their contents and relationships survived. A file that looks similar can still have lost useful structure, leaving the author with a document that is harder to revise or export reliably.
Separate cosmetic differences from substantive losses. A changed default font may be easy to address, while missing note links or flattened tables can require significant reconstruction. Record each issue with its location and a realistic repair method. Avoid dismissing all differences as formatting until you know whether information, relationships, or editing capabilities were lost. The migration decision should include the work needed to restore what the book requires.
Make a realistic revision and export the result
Perform the kind of change that motivated the migration: move a section, revise a table, replace an image, or reconcile a collaborator's correction. Then export through the workflow intended for publication and inspect the actual file. This tests the full path from imported source to usable output. A successful import alone says little about whether the next revision cycle will be easier.
Compare the export with the original acceptance requirements for the book and consult current KDP preparation guidance for the intended edition. Record any new manual steps the workflow introduces. A tool may save time in one area while moving the work into export cleanup. That tradeoff can be acceptable, but it should be visible before the entire manuscript depends on the new environment.

Decide with a migration and recovery plan
Summarize the benefits demonstrated by the trial, the repairs still required, and any unsupported elements. Estimate the remaining migration effort from the actual sample while acknowledging chapters that may be more difficult. If the main problem is not resolved, consider a narrower workflow change rather than moving the entire project solely because time has already been spent on the trial.
If proceeding, preserve the original manuscript and define when the migrated copy becomes authoritative. Keep a clear record of changes made during the transition so two independent versions do not drift silently. Verify the full manuscript after migration, including unusual chapters not covered by the sample. The trial reduces uncertainty, but final acceptance still depends on the complete book and its actual export.
Frequently asked questions
Clear answers for this publishing decision.
Is a successful import enough to approve new software?
No. Make a realistic revision and inspect the resulting export. The full workflow may introduce problems that are invisible in the imported document.
Which sample should I use for the trial?
Choose content with the book’s demanding elements as well as normal prose. Tables, notes, captions, and special paragraphs reveal losses that a simple page may not expose.
When should the imported copy become authoritative?
Define that transition explicitly after review and preserve the original source. Track changes during migration so competing versions do not diverge without a clear accepted baseline.
How do I get from an idea and a brief to an editable manuscript I can finish?
Write the brief first, generate a structure you can edit, then draft and revise the manuscript in reviewable sections so one change never overwrites work you already approved.
Start a book project from a brief