There's really no need to remove the paid version (or convert it to free) in order to obtain a free version with IAB, and there are some good reasons to retain the paid version as a separate app from your free one.
One reason is that, depending upon which versions of Android your app supports, as much as ten percent of all devices may not support in-app payments (e.g., because they have an older version of Android Market that does not auto-update and does not support IAB3). That provides an argument for keeping the paid version around.
Also, if a user installs your free app to a device that does not support IAB3, then you can have your app detect that and provide a link to the paid version for them to install as an alternate (to IAB3) upgrade path when they signal to the app that they are ready to upgrade.
And, of course, if you do keep the paid version around, you'll have no problem distinguishing users who have already paid from those who have not.
If you decide to retain your paid version, then you can just add in-app billing to your free version to enable the upgrade to your paid feature set. That will satisfy those users who are looking for an upgrade path that is less disruptive than uninstalling the free app and installing the paid one.
If you have not already done so, you'll probably want to create a project library to hold most of your apps' capabilities, to be shared between your free and your paid versions. You might end up converting your paid project to that very library, and then creating two projects, paid and free, which use that library. If one of your motives for combining both versions into a single free one is concern about maintaining two apps, using a project library could reduce that overhead significantly, although it will not be zero.
In that regard, I have found it useful to create an activity in each of the apps that uses such a project library, which inherits from the main activity in the project library. That main project library activity can be an abstract class, with certain methods to be provided by the activity classes that inherit from it in the APK-generating projects that use it; or, certain methods can just be defaulted in an innocuous manner (rather than defined as abstract) and then overridden in the derived classes within the respective projects. These overrides can be used to tailor the behavior of the project library to the requirements of the specific app (e.g., free vs. paid) that is using it. You can also override pre-defined methods like onCreate(), onResume() and so on to accomplish these same ends of differentiating behavior between the respective (e.g., free vs. paid) apps.
Finally, I would not worry too much about splitting your installs between two APKs, because the free version will probably get the lion's share of those simply due to the ease with which it can be installed and tried, so long as the IAB upgrade process is seamless.