A great example of this for me was with payments where it may be paypal, amazon payments or cc via another vendor. In this way, I don't need a bunch of custom fields that I'll never query on, just a generic additional field. In this way, I'll often write an abstraction class against my ORM to handle this, and then have properties that get/set against the underlying JSON data/object field.
This is what you've done here... that said, any specific features of a single platform will mean pain in migration. If you must support multiple backends, then you should create an abstraction and a factory as appropriate. As much as I hated MS Enterprise Library's Data Application Blocks, supporting multiple backends was a problem it did help resolve.
As nibs mentions, you should probably use an ORM that takes care of most of the differences between backends.
TBH though, depending on the type of data you're using, I might start with a simple record store nosql server (rethinkdb, for example), and only migrate if/when needed.