I would recommend aiming for smooth, robust code with the new infrastructure system, trying to take advantage of it fully and go with it from a now-forwards stand.
Like most server owners, I am prepared to accept that I will need to reset everything on my server for sponge, due to the impossibility of all of my core, infrastructural plugins being migrated, and missing something valuable that i need to switch to a replacement program anyways - which even on a bukkit server, if a big enough infrastructure to my server, would warrent resetting.
But being prepared and hoping not to have to at the same time…
Since a migration to sponge is a big undertaing for any server owner - and though some folks around here would like to say that in time "ah, you just swap this and that file for that file, and you’re up in 5 minutes; it is at least a big enough change compared to replacing a craftbukkit.1.sumnumber.number file with craftbukkit.1.sumbiggernumber.othernumber file and has to make even the server owners who insist on running servers with 15 red-colored plugins in their list, and errors spammed to log each time they interact with a block take pause for a moment and realise … something is kinda big and different here.
But as big as it is to make a trnaasition … its also done once, then, its over.
The owners who cant be bothered with researching, reading, trying to figure out how to make tough things work are going to just wipe anyways, the ones who have serious amount of investment and desire to keep the same maps and such are going to look into whatever it takes to preserve them, and will be willing to invest in one-time special utilities to convert data from one form to another in order to bridge it.
But it should be the responsibility of the server owner to perform a one-time bridging step to transition existing map data into a new state that a plugin can use, if that plugin has a much better way of handing data now as you will. Once that transition is done, there is no need to look back.
So I would have to imagine that a plugin will be smoother, more reliable, easier to program and debug for you if you can focus on now-foward for the regular use, rather than incoroprating backwards compatibility work into it (almost writing two plugins in one). But at the same time, making a separate, smaller, cleaner, faster, streamlined single-run converter utility for server owners to run first as a separate one-use plugin that is not a part of a released day-to-day use plugin in order to capture that information from the map and transmogrify the map / plugin data to make it forward-usable … if doable … would be fantastic.
But it shoudl be a stand-alone utitlity, for the significance of the one-timeness of a GRAND system overhaul - its not just you upgrading your plugin and trying to backsupport your plugin – upgrading to that version of your plugin already has the server owner at a point where the acknowledgement is that a true, data-preserving upgrade across the entire spectrum of his plugins is no small feat, a job that is going to require a LOT of work across a spectrum of things.
So “backwards compatbilty” for the plugin …no, trim that fat in order to take advantage of every thing you can in the new system. One time migration of the system for your plugin, yes please.
Even if it takes a utility hours to convert the map for your system, this is an instance where that is the cost to pay for the decisoin and investment of the owner. No one in such a situation is going to scream about how their server is offline for 2 hours to the equivalent of a heart, brain, lungs, kidneys, liver and intestine transplant. Be frustrated with multiple systems that are taking an hour to one-time run each but knowing that in the future, all their plugins are optimized and streamlined for the server operation, yes, that may happen. But the more important map is to keep (years old for some) what is an hour? As long as I knew the utilility was not crashed, i’d wait a day for a util to convert all my maps as being part of the process, to keep 2 year old maps.