Yeah, I’d very often say it would be better to finish off a project in the tool you have been using for it, rather than trying to migrate in the middle. It’s a personal choice of course, but starting with Scrivener fresh on the next book may be all around the simplest approach. Most people migrating mid-project are coming from monolithic text editors like word processors, that have next to no architecture around their slew of .docx files (or even one gigantic one) to have to worry about.
That said, both programs use an open folder-file based format with deliberately easy to work with data files. It would not be difficult to automate if you know a good scripting language, and in a way that could be done as piecemeal as you like. For example, with very light scripting you could go from a list of labels in a .txt file with hexcode colours to Scrivener’s XML format in the .scrivx file. Scrivener uses floating point RGB, so it would be a very simple matter to get from base16 to 0-1. If you match the output XML structure, you can just paste that in with the project closed…and now your labels are imported. And once you start looking at the .scrivx file a bit more, you’ll see it wouldn’t be terribly hard to reconstruct the binder from the folder and file structure, even pulling extra data from the .md file content, such as its intended title, metadata ID translations, word count goals and so on. Again, one could go as little or hard as they wanted to in that direction—probably all the way to a near full conversion.
The main and trickiest part would be getting the content into RTF form. The most straight-forward approach would be to automate however much you want to rebuild a skeleton project without the data. Then bulk import the .md files with simple drag and drop into the project binder from File Explorer. It’ll be a bit tedious, but you can efficiently “zipper” the two separate outlines by selecting the skeleton outline item, then Ctrl+click on the imported .md data, followed up by the
Documents ▸ Merge shortcut. Over and over. Merging works by using the top file in the selection as the master, meaning your hard work in setting up labels and such would be retained, and since merging destroys the lower copy it keeps the process tidier than copy and paste and delete would.
Is it worth it? Well… I’d say so, but I use piles of Scrivener features and the whole program is second nature to me, so that only goes without saying. By the way, do check out Chapter 21 in Scrivener’s user manual PDF, for the details on how it can be used as a Markdown authoring platform.
For export, I understand Manuskript uses Pandoc for most of its conversions, so you may appreciate knowing that Scrivener integrates with Pandoc as well, both with some prefab outputs (DOCX and ePub notably), and you can create your own freeform outputs with its Processing pane, where you give Scrivener the command-line you want to use. The Markdown & LaTeX category around here is full of tips.
The methods will be different (though, ha, not too different, as noted above), but the result you’ll get will be much the same as what you’re used to, given the common conversion engine beneath it all. In fact if anything you may have to do less work with Scrivener once you learn it—it seems for example Manuskript has no way of supplying custom CSS to an ePub on output. You can embed your styling into your compile settings with Scrivener, meaning the book can come out close to, if not already done. And like I said above, since you can supply the actual command-line being used, you can also bake in use of template files for DOCX/ODT, bibliography details, and other settings that may not be directly supported in the UI. Overall I think you’ll find export to be an improvement, once you learn the basics (which again, are kind of the same, though in a more Scrivener v1 way).