1. Save in your playerprefs the version you are using.
2. Have some migration function in case your current version is higher than the saved version.
3. Always migrate only one version, in case saved version is 1.0 and current game uses 4.0, you should migrate from 1.0 to 2.0 to 3.0 to 4.0 without skipping a version.
4. You can either adjust the score on migrating or just wipe it.

If you change the name of the key, you might run into troubles with backwards availability. Your user might not always use the most current game version and you would have to search/ guess all past naming schema. By keeping the same name and a separate version key, you can handle the loading of keys according to the version.

1. Save in your playerprefs the version you are using.
2. Have some migration function in case your current version is higher than the saved version.
3. Always migrate only one version, in case saved version is 1.0 and current game uses 4.0, you should migrate from 1.0 to 2.0 to 3.0 to 4.0 without skipping a version.
4. You can either adjust the score on migrating or just wipe it.

If you change the name of the key, you might run into troubles with backwards availability. Your user might not always use the most current game version and you would have to search/ guess all past naming schema. By keeping the same name and a separate version key, you can handle the loading of keys according to the version.

• You have to keep the loading function of each version you have ever created of your playerprefs for true backwards compatibility.
• You should not override the old data before you successfully migrated to a newer version in case something goes wrong in the middle of converting.
• You should migrate all data at once to not get inconsistent fields between versions. You can migrate the data the first time you need to access it but usually at startup of your application it is a good idea to check if it is up to date.