Switch Saves: Your Progress Versus a Game Dump
Your progress lives in a small account-bound file that has nothing to do with the container a title ships in. Here is the difference, and why it matters.
What a save actually holds
People ask about switch saves for one of two reasons: they are about to change something on their console and want their progress to survive, or they have confused progress files with software files. The two are unrelated, and untangling them takes one paragraph. A save is a small record of what you have done in a title. Levels cleared, currency earned, options changed, characters unlocked. It is written during play, it belongs to a user profile, and it lives in system storage rather than sitting loose in a folder you can browse.
A game dump is the opposite in almost every dimension. It is a container holding the assets and program code a title shipped with, it is identical for everyone who owns that title, and it is measured in gigabytes rather than kilobytes. Nothing about your progress is inside it, and nothing about the software is inside your save.
That asymmetry explains most of the confusion in search results. A backup of a title and a backup of progress are two separate projects with two separate risks. Losing the first costs you bandwidth. Losing the second costs you a hundred hours nobody can hand back.
Why the two never travel together
Console software keeps progress in a protected area of internal storage rather than beside the installed title, and it keys that data to the profile that created it. This is a deliberate design, not an inconvenience. It means several profiles on one console can each hold their own progress in the same title, and it means removing software does not silently take your progress with it.
It also means a container downloaded from anywhere cannot carry progress. When someone claims otherwise, they are describing something else: a modified save circulating separately, which is a different object with different risks. If you are matching containers to catalog rows, the page on packaged entries covers what a row can and cannot promise, and none of those promises involve your progress.
The practical upshot is that reinstalling a title you already played usually finds your existing progress waiting, because the progress was never removed. That is the intended behavior, not luck.
Thinking about progress backups the same way you think about files
Treat progress like any other small irreplaceable data set, because that is exactly what it is. Three questions decide how much effort it deserves:
- How much time is in it? Fifty hours of a long role-playing campaign is worth a routine. Twenty minutes of a puzzle title is not.
- Is the title covered by the console's cloud backup? Coverage is per title, decided by the publisher, and a handful of competitive releases opt out. Check the ones you care about instead of assuming.
- What are you about to change? Storage swaps, system transfers and repairs are the moments when progress goes missing, and they are all moments you can see coming.
The same discipline applies to the card those containers sit on. If you are reorganizing storage, the storage page covers formatting and capacity choices, and doing that reading before you move anything is cheaper than doing it afterward.
Tools exist, and this page is not the manual
There is a family of homebrew save managers in the wider hardware-modification community, written to copy progress out of a console and back into it. They are real, they are widely discussed, and naming that category is where this page stops. Using any of them means putting a console into a state it does not ship in, which carries risk to the hardware, to your account standing and to the data you were trying to protect.
So no procedure here. No entry points, no sequences, no configuration. If you decide that path is right for hardware you own, do the reading in the communities that maintain those tools and accept that the responsibility is yours. What this bench will tell you is the boring part everyone skips: whatever route you take, verify the copy before you rely on it. An untested backup is a rumor about a backup.
The generic advice that survives every toolchain is unglamorous. Keep more than one copy. Keep them in more than one place. Label them with the date and the title so future you does not have to guess. Restore one on purpose while nothing is wrong, so you find out the copy is readable at a moment when it does not matter.
Where the catalog fits, and where it does not
This side of the fence deals with software containers for hardware you own. Progress files are not part of that inventory and never will be, which is a boundary worth stating plainly rather than leaving implied. If you came here hoping to find a completed save for a title, that is not something published here, and any source offering one is offering a file of unknown origin that writes into a protected area of your console.
What you can do here is keep the software side tidy. Confirm which container matches which entry before you install, keep your version fields straight, and note what you already hold. When something in a listing does not line up with the file behind it, Report an issue so the row gets fixed for the next person, or Open a ticket if you want a hand working out what you are looking at.
Two lists, kept separately. One of software you have archived, one of progress you would be upset to lose. They rarely overlap, and treating them as one job is how people end up with a perfect shelf of containers and no memory of where their hundred-hour campaign went.