How to try Octarine without changing your Obsidian vault

Obsidian and Octarine both work with local Markdown files, so migration does not start with a vendor export. The safer question is whether the conventions around those files match: attachment paths, wikilinks, templates, daily notes, and any syntax produced by plugins.

Do not use the only copy of an important vault for the first test. Opening a folder in Octarine can add Octarine-specific workspace directories, and a later compatibility cleanup may edit links or move assets. A duplicate lets you learn what needs changing without turning the test into a commitment.

1. Make a complete copy

Close or pause tools that are actively changing the vault. Copy the entire folder, including .obsidian and other hidden files, to a new location. Give the copy an unmistakable name such as Vault-Octarine-Test.

If the vault uses cloud sync, place the test copy outside the live synced folder at first. That prevents a trial edit or attachment move from propagating to every device. Keep the original backup until you have used the migrated workspace for long enough to trust it.

Obsidian’s own documentation confirms that vault data is stored as files in a local folder. That common file model is what makes a copy-based evaluation possible.

2. Open the copied folder in Octarine

In Octarine, open the Workspace Switcher, choose Create Workspace, name it, turn on Use an existing folder?, and select the copied vault. Octarine uses that folder as the workspace rather than importing notes into a separate database.

Wait for the workspace to load and index. Browse before reorganizing anything. Check a long note, a nested folder, a note with frontmatter, a canvas-adjacent project, and several files with images or PDFs.

The official Obsidian migration guide documents the current conventions. Review it against your vault rather than assuming every Markdown-based feature maps one-to-one.

3. Check wikilinks, especially nested notes

Octarine supports [[wikilink]] syntax, but nested targets should include their path from the workspace root. If Hello.md is inside New Folder, use:

[[New Folder/Hello]]

A short [[Hello]] link is resolved from the root rather than searched across all folders. Obsidian lets users choose different link conventions, so a vault that relies on shortest-path links needs special attention. Wikilink aliases are not currently supported in Octarine.

Build a small link audit from real material. Open notes that point to same-named files in different folders, aliased links, heading links, and embeds. Do not run a bulk replacement until you understand which patterns actually fail.

4. Check attachments and templates

Octarine expects workspace attachments in a root .attachments folder and attachment references in a compatible form such as [[filename.png]]. If the Obsidian vault stores images next to notes or in a different folder, test the paths in the copy. Moving assets can require corresponding link updates.

Templates belong in a root .templates folder for Octarine. Copy or move the templates inside the test workspace and inspect whether their frontmatter and placeholders behave as expected. Obsidian plugin commands inside a template do not automatically become Octarine commands.

5. Check Daily Notes and plugin-dependent content

Octarine recognizes Daily Desk notes in a Daily folder with YYYY-MM-DD.md filenames. If the Obsidian vault uses a different folder, date format, or nested calendar hierarchy, decide whether to preserve that archive as ordinary notes or copy it into Octarine’s convention.

Community plugins are the largest compatibility variable. Their data may be plain Markdown, frontmatter, fenced code blocks, JSON files, or syntax meaningful only when the plugin is installed. Octarine does not reproduce Obsidian’s community plugin runtime. Obsidian’s community-plugin documentation is useful for identifying which behavior comes from the base app and which comes from installed extensions.

Create a list of plugins that affect stored content. For each one, answer:

• Is its important data visible in the Markdown file?
• Can Octarine render or at least preserve that syntax?
• Is the behavior needed every day, or only for an old archive?
• Is there a simpler Octarine feature or external tool that covers the actual job?

6. Choose coexistence or a clean switch

After testing, you can keep the original Obsidian vault and the Octarine copy as separate systems, or designate the tested copy as the new primary workspace. Avoid editing both copies indefinitely unless you have a deliberate merge plan; two diverging sets of notes are harder to reconcile than one migration.

Some people may point both apps at one folder. The shared Markdown foundation makes that possible in principle, but each app can maintain hidden configuration and interpret links or attachments differently. Test with non-critical data and avoid simultaneous bulk operations. A copied workspace remains the safer first step.

Before switching, verify search, nested links, attachments, templates, Daily Desk, frontmatter, tags, and backup recovery. Keep Obsidian installed and the original vault read-only for a cooling-off period. A successful Markdown migration is not one where files merely open; it is one where the relationships and daily workflow still make sense.