There are three databases for AX2012 R2/R3; business data, application (modelstore) and "old modelstore" baseline. You only need the baseline database for comparing with "old" (pre-AX2012 terminology), but it is not required for testing or production, only development. For the most part, you don't need baseline, only te two other databases. You cannot "convert" here. There is no "conversion" option available.
For this type of upgrade, you have two possible approaches.
1) Source-to-target
2) Migrate data
The source-to-target approach means that you will install code into AX2009 to prepare for the upgrade. You will run a checklist in AX2009 to prepare some data before you start the upgrade, typically prepare new data constructs and concepts which are AX2012 specific. Furthermore, in AX2012 you will import and create customizations in order to keep custom tables and fields. What you keep and what you discard is based on how integrated the customizations are with standard. If you consider how standard has changed between AX2009 or how standard has added new functionality in AX2012 R3, you may end up with discarding forms, reports, logic, but still plan on keeping custom tables and fields, for historical reasons or future plans. When you are ready with the new R3 application, you will use checklists in AX2012 R3 to connect to the AX2009 instance, and pull data over to AX2012 R3. You can do this multiple times, where consecutive pulls will only pull deltas/changes. You may need to rerun steps in the checklist in the source (AX2009) before you pull from AX2012. When you are read for GoLive, you will do a final section of the checklist in the source, and close down the source, and then do a final pull in AX2012 R3. This is a very high level explanation.
The migration approach is about setting up a new AX2012 R3 where you setup the parameters from scratch, and then you use Data Import Export Framework (or Excel Addin, or other tools) to migrate data into the AX2012 R3.
There are pro's and con's for each approach. If AX2009 is poorly configured, or has a lot of bad data (lack of integrity), then the source-to-target might be painful and data migration can be easier. Source-to-target is a more "copy all", which in some cases means "getting a lot of garbage" which is hard to get rid of in AX2012 after it has been created (ie immutable data). The data migration approach requires good knowledge about AX, and the composition of the modules and their data. You will need to control the order of how data is created, so it makes logical sense for AX (ie CustGroups before Customers, before Projects, before Project funders based on customers, etc).
There is no easy answer to your question, and there is absolutely no wizard that simply upgrades from AX2009 to AX2012 (any version). It is fairly big project and is fairly demanding on the partner side in terms of knowledge of AX2009 and AX2012.
I hope that answers a bit.
