This is a simple example that shows how we can maintain backwards compatibility in a plugin for data that used to be stored in post meta but is now stored in a taxonomy term. When this change was made, a new `edd_get_commission_status()` function was introduced, but before this function existed, the status was retrieved by calling `get_post_meta…

gistfile1.php

<?php

/**
 * Filters get_post_meta() to ensure old commission status checks don't fail
 *
 * The status for commission records used to be stored in postmeta, now it's stored in a taxonomy
 *
 * @access      private
 * @since       2.8
 * @return      mixed
 */
function eddc_filter_post_meta_for_status( $check, $object_id, $meta_key, $single ) {

	if( defined( 'EDDC_DOING_UPGRADES' ) ) {
		return $check;
	}

	if( '_commission_status' !== $meta_key ) {

		return $check;

	}

	if( has_term( 'paid', 'edd_commission_status', $object_id ) ) {

		return 'paid';

	} else {

		return 'unpaid';

	}

}
add_filter( 'get_post_metadata', 'eddc_filter_post_meta_for_status', 10, 4 );

@engelen I haven't though you could definitely take a similar approach.

I wouldn't advise this method unless you know there will be plugins that break when changes are made.

This is a good example of why we should always consider writing an "API" for our plugins that offers the "official" way to retrieve and set data for the plugin. By doing that, we give ourselves the freedom to change how / where the data is stored without breaking the code that other developers have written on top of our platforms.