There is a potentially major overlooked disadvantge with the second approach, and that is if the class changes from the time in which it was inserted to the time in which it was retrieved, deserialization will fail.
You could throw a proper exception to make the error clear, but you also wouldn't be able to do anything about it. The caller would know the error clearly, but the caller himself wouldn't be able to do anything about it, having only the most recent version of the class. In order to use that interface, after any change to the class, there must be a converter class that retrieves all old instances of that class, destroys that instance on the cloud, then recreates it using the new version of the class.
This is no small feat. If you want to take this approach, you may want to consider having an upgrade possibility which does this on behalf of the caller.
Your first solution, despite being somewhat inconvenient, is more robust. It isn't likely going to fail, which may be important. You can have both options if you wish, nothing is stopping you from doing so, leaving it up to the caller which to use. At least in the case where an older version is saved, there exists the option of retrieving the string value of the failed deserialization to deal with at a later moment.