@Nik, my intuition is that if you say letsencrypt -a webroot -d example.org -d www.example.org with exactly the same list of domains as are in your existing cert, the client should be able to renew using your existing cert and the different authenticator. You would also, I expect, need to specify your webroot map on the command line, so it might be something like letsencrypt -a webroot -w /var/www/example -d example.org -w /var/www/example -d www.example.org. The key criterion is that the set of requested domain names (via -d) should be exactly equal to the domain names that are present in the original certificate, including any www names that might be present in the certificate.
If this doesn’t work, there is a way to do it by editing the renewal configuration file in /etc/letsencrypt/renewal; we tend to discourage this because we have not yet written any significant amount of documentation about the contents of these files and it’s possible to get the client into a non-working state by making a renewal configuration file internally inconsistent. With that warning, I would say that changing authenticator in that file and adding a webroot_map at the bottom can be used to change the renewal settings. The format of the webroot_map in the configuration file may be a bit counterintuitive and it might be helpful to make the changes based on another certificate lineage that was originally created using webroot, if you have access to one. As I said, we have tended to discourage this kind of editing for the time being because it is possible to get the client into an inconsistent state. If you end up needing to do this, we can try to help you make it work; it would be a good idea to back up your original renewal configuration file so that you can restore it if your edits confuse the client.
I hope that in the future we’ll have better tools and documentation around this topic.