Move Flashcards to Another App Without Starting Over

Yes, you can move flashcards to another app without starting over. The result depends on what your export contains and what the destination can read. Save the source, choose the smallest valid format, test a copy, compare real cards, and keep the original export until the new collection earns your trust.

Short answer

• Use an .apkg for a focused deck and a .colpkg for a full collection when the destination supports it.
• Review progress moves only when the export includes scheduling and the importer reads it.
• Media, cloze cards, templates, and formulas need a representative test.
• Deck settings, add-ons, and custom scheduling often need rebuilding.
• Keep an open export so you can leave the new app later.

Can you move flashcards to another app without starting over?

Yes, if you treat migration as a verification job rather than a file-opening job. Cards often travel well. Progress can travel too. The fragile parts are usually the settings around the cards: extensions, custom scheduling, templates, and media paths.

A useful migration answers four separate questions:

1. Did the export contain the thing you care about?
2. Can the destination read that part of the file?
3. Did the import reproduce it on the right cards?
4. Can you export your collection again if you change tools later?

The first mistake is calling all of this “the deck.” Your notes are one layer. Your review state is another. Your deck settings are a third. An extension that changes card behavior is a fourth. A migration can preserve one layer while dropping another without showing an obvious error.

That is why the right question is not “Did the import finish?” Ask instead: “Can I open the cards I know, see the media I use, recognize tomorrow’s queue, and create a file I could use somewhere else?”

The format matters, but the destination matters just as much. Two applications can open the same package and interpret its scheduling or templates differently. An import dialog that accepts a file proves very little by itself.

Start with a three-card copy in the browser: open StudyDaily and test the destination without installing anything. Reviewing does not require an account, so you can check the migration before committing your collection.

Which export should you use: .apkg, .colpkg, or CSV?

Use an .apkg when you want to move one deck or a defined group of decks. Use a .colpkg when you need a full collection and the destination explicitly supports that format. Use CSV when the portable part of your collection is mainly text and simple fields.

The choice is about scope, not prestige.

Use an .apkg for a focused move

An .apkg is the practical choice when you are moving a language deck, a course deck, or a small part of a larger collection. It can carry cards, notes, media, and scheduling when those options are included in the export.

The official Anki manual on exporting describes packaged deck exports and the option to include scheduling information. The same manual also distinguishes a deck export from a complete collection export. That distinction matters before you choose a destination.

Export the smallest complete unit you can test. A small package makes it easier to find a missing image, a broken template, or a scheduling mismatch before the problem spreads across thousands of cards.

Use a .colpkg for a full collection

A collection package is for a wider move. It is the better starting point when you need multiple decks and collection-level data, but only if the receiving application supports the format and explains what it imports.

Do not choose a collection package because it sounds more complete. Choose it because the destination has a documented path for it. A large file can carry more structure while giving you fewer ways to isolate a problem.

For the practical boundary between a deck package and a collection package, see choose the right export scope.

Use CSV as a text-first fallback

CSV is useful when you need the text of your cards in a widely readable form. It is not a safe promise for review history, media, note templates, or custom card behavior. A CSV file can preserve the words while leaving the study system behind.

That can still be the right decision. If your priority is to rescue a glossary or a set of prompts, a clean text export may be more valuable than a complex package you cannot verify. Make the trade-off explicit before you start.

StudyDaily accepts .apkg and collection packages for import. It also exports .apkg and CSV at any time. The point is not to make one file format sacred. The point is to keep a format that gives your collection another exit.

What should you back up before moving your flashcards?

Keep three things before you import anywhere: the untouched source collection, the original export, and a separate copy for testing. Your first import should never be the only copy of your work.

Start with a backup you can restore. Then export a small real deck and keep that file unchanged. If you later edit the export, rename the copy so you know which file was tested and which file is the original.

Use this short checklist:

• Export a small deck with the media and scheduling options you need.
• Record the file name, size, and export date.
• Open the file in a test destination before changing the source collection.
• Keep the original collection untouched until the test passes.
• Store the export somewhere outside the application that created it.
• Make a second copy before you begin a full-collection export.

A backup is not a backup you have never opened. Restore or import a copy far enough to confirm that the file is readable, then keep the source intact.

If you want the full pre-migration procedure, make a verified backup before switching. The guide belongs to the same migration cluster and goes deeper on restore checks.

This step feels slow because the old app still works. It is faster than trying to reconstruct a collection after deleting the only copy that carried its media or review state.

Does your review progress move with your flashcards?

It can, but only when the export includes scheduling and the destination knows how to apply it. A scheduling-aware package can contain card state, due date, interval, reps, lapses, suspended or buried state, FSRS memory, and review history. A text-only export cannot recreate that queue.

The export decides what is available. The importer decides what it can use. Those are separate gates.

The Anki manual on packaged deck importing explains how packaged decks are handled at import. It also documents that options can remove learning progress during the import. Leaving a box selected does not help if the export never contained the history in the first place.

A shared deck is a different case from your own export. A deck made for other people may intentionally omit the creator's scheduling. If every card arrives as new, that does not prove that the format always loses progress. It may mean the file was published without somebody else's review history.

For the exact fields that an .apkg can carry, read see what the package keeps from your schedule. That article focuses on the scheduling question. This guide uses the same principle to plan the whole migration.

StudyDaily reads the scheduling data for cards created by an import. Importing over cards that already exist does not rewrite their local progress. The import option is enabled by default and can be turned off when you want clean cards. That is useful when you are bringing in somebody else's deck, not when you are moving your own review history.

The importer test behind this workflow used a small collection with known values, not a visual guess. A sample card retained stability 12.5, difficulty 4.2, 9 reps, 2 lapses, and three review events after import. The same card data was still present after export. That is the kind of measurement you want from your destination: named fields, a known card, and a return path.

Do not judge progress by one due date alone. Compare a known mature card, a learning card, and a card with a history of lapses. The three cases expose different failures.

The most useful test is a round trip. Import a small export, inspect the cards, then export that test collection again. An open exit makes the destination easier to trust because the move is reversible.

What happens to media, templates, cloze, and image occlusion?

Cards are more than their visible words. A migration can preserve the front and back while changing a media path, a template rule, a formula, or the way a cloze card renders. Test the card types you actually use.

Check these layers separately:

• Images and audio: open the card and confirm that the file loads, not just that an attachment count looks correct.
• MathJax or formulas: test a formula with an operator, a fraction, or a symbol that matters to your course.
• Cloze cards: reveal each deletion and confirm that the surrounding text still makes sense.
• Templates and styling: inspect a normal card and a card with unusual formatting.
• Tags and fields: search for a tag and check that custom fields did not move into the wrong place.
• Image occlusion: test an imported occlusion if your destination supports it. Display and editing are different capabilities.

StudyDaily displays and reviews imported image occlusions, but it does not offer an editor to create new ones. Say that once, decide whether it matters to your collection, and continue checking the formats you use.

Media deserves a direct test because it can fail quietly. A card that shows a blank image may still look fine in a list. Audio can fail only when you review. A broken template may affect one note type out of twenty.

Use a six-card coverage set:

1. a plain text card;
2. a card with an image;
3. a card with audio;
4. a cloze card;
5. a card with a formula;
6. a card with the most customized template in your collection.

If you use image occlusion, add one more. If you use unusual fonts or CSS, include a card that depends on them. The goal is not to test an abstract feature list. The goal is to test the edges of your own collection.

What usually needs rebuilding after a migration?

Settings around your cards often need rebuilding even when the cards themselves arrive correctly. Expect to review daily limits, learning steps, new-card order, deck presets, extensions, scripts, custom CSS, and scheduler-specific choices.

That list is not a verdict on the destination. It is a reminder that settings belong to a study environment. A card's answer is portable in one way. The rules that decide when you see it again are portable only when the source and destination share enough structure.

Separate three kinds of work:

Recreate the destination settings

Write down the limits and learning steps that matter before the move. Re-enter them after the import, then review a few cards. Do not assume that matching labels means matching behavior.

Replace external dependencies

An add-on, script, or custom scheduler is not inside every export as a portable feature. Make a list of the behavior it provided. Then decide whether the destination has an equivalent, whether you can work without it, or whether you need to preserve the source for that part of your workflow.

Confirm what is actually missing

Do not call a setting a lost card. Compare your card content first. If the notes, media, and review state are present, you may only need to rebuild the way the destination presents them.

StudyDaily has no multi-device synchronization. Each installation keeps its own collection, and transfer between installations uses .apkg or CSV exports. That is a product limit, not a reason to hide the collection in a proprietary format.

The same principle protects you from future lock-in. Keep a copy of your open export after the migration. The destination earns trust by giving you a usable way out, not by making the first import look effortless.

How do you test an imported collection before switching?

Test a small, representative copy before moving the full collection. Five minutes can reveal a missing media folder, a reset due date, or a template that only fails on one note type.

Use this order:

1. Pick a small deck that contains the card types you actually study.
2. Duplicate it or export it without changing the source.
3. Include media and scheduling when those options exist.
4. Import the test file into an empty or clearly labeled destination.
5. Compare three known cards: one mature, one learning, and one with media.
6. Check a suspended or buried card if your collection uses them.
7. Review the next interval or due date where the destination exposes it.
8. Export the test collection again and open that return file if possible.
9. Write down what needs rebuilding before you migrate the rest.

A test is stronger when you choose cards with known history. Do not select three new cards because they are easy to inspect. New cards cannot tell you whether the scheduler received your review history.

What counts as a pass?

The import passes when the content is correct, the media opens, the tested progress is plausible, and the destination gives you a usable exit. “The file opened” is only the first check.

The import fails when a field is shifted, media is absent, due dates reset without explanation, or the return export cannot be read. Keep the source collection and investigate the smallest failing sample. Do not repeat a broken full import and hope the result changes.

If the test passes, migrate in batches. Keep each export named by source and date. A batch makes it easier to identify the deck that introduced a problem and gives you a clean rollback point.

For a measured follow-up, compare the losses that migration actually exposes.

Sources used for this guide

The linked Anki documentation was checked against the export and import workflow described here for the guide's 13 April 2026 publication date. The official Anki export manual covers packaged decks, media, and scheduling options. The official packaged-deck import manual covers how the receiving collection handles imported cards. The Anki FAQ on moving cards covers using an export when moving cards between profiles.

These sources describe Anki's file behavior. StudyDaily's import and export claims come from the product feature registry and the importer tests in this repository. The distinction matters: a source application's export can carry a field that a destination chooses not to use.

How does StudyDaily handle a flashcard migration?

StudyDaily is designed around the parts of a collection that should remain portable: imported card content, open exports, local review, and a visible schedule. It accepts .apkg and collection packages, keeps imported formatting, and can export .apkg and CSV at any time.

The importer also reads scheduling for cards it creates. That includes state, due date, interval, reps, lapses, suspended and buried status, FSRS memory, and review history. The option can be disabled when you want cards to arrive clean.

I built this importer around the fields that decide whether tomorrow's review queue still makes sense. That is why the migration path starts with a copy and a comparison, not with a promise that every setting from another tool will appear unchanged.

StudyDaily works offline for cards, reviews, and statistics on the device. Reviewing does not require an account. An account is reserved for generation and cloud backup, so you can test the core study flow before deciding whether those features matter to you.

The collection remains yours after the import. Export it as an .apkg or CSV when you need a second copy, a new destination, or a clean handoff. The product does not make the exit a paid privilege.

For the broader decision about an everyday flashcard tool, see compare the criteria that survive a migration. If that future guide is not published yet, the marker will remain plain text until its group exists.

What should you do next?

Start with the smallest deck that represents your real study life. Preserve the source, export the test copy, and compare cards before you move the collection that you depend on every day.

A safe sequence is:

• keep the original collection untouched;
• choose .apkg, .colpkg, or CSV for a stated reason;
• import a representative test copy;
• check content, media, scheduling, and one return export;
• rebuild only the settings that truly need rebuilding;
• keep the original open export after the move.

This approach answers the question behind “move flashcards to another app.” You are not only trying to get the cards inside. You are checking whether your future review remains understandable and whether you can leave again.

Questions people ask

Can I move flashcards without losing my review history?

Yes, when the export includes scheduling and the destination imports those fields. Check a mature card, a learning card, and a card with lapses before moving the full collection. If the source file was exported without history, the destination cannot invent it. Keep the original export until the test and the return export both pass.

Should I use .apkg or .colpkg to move flashcards?

Use .apkg for a focused deck and .colpkg for a complete collection when the destination supports it. A collection package is not automatically safer. It may carry more structure while making a problem harder to isolate. Choose the smallest package that contains the work you want to move, then test that copy.

Will my images and card templates move too?

They may, but verify them on real cards. Open an image, play an audio file, render a formula, reveal a cloze card, and inspect your most customized template. A file can import successfully while one media path or style rule fails. Your coverage set should mirror the formats that matter in your collection.

Can I leave the old app after importing?

Only after the new collection passes a representative test and you have kept the original export. Check content, media, review state, and a return export. If the new tool cannot give you a usable way out, keep the source collection available. Portability is part of the decision, not an optional cleanup step.

Anki is a registered trademark of its respective owner. StudyDaily is not affiliated with, endorsed by, or sponsored by Anki. The product name is used here only to describe compatibility and to compare features.