Just want to bump this again to say it is really frustrating to have no ability to change any custom field types. For example, we had a number field and found it to be a little too limiting and would like to move to a text field. So I am going through and bulk editing, searching number by number, and updating a few issues at a time to manually put value of the old number field in the new text field.

I am wanting to change a custom field from multi-line which is not searchable to paragraph which is searchable. OR make multi-line searchable and sortable.

Why won't fix? Disappointing? this is curcial

Too bad this is won't fix.  It makes it so very hard to evolve the data in Jira.  We're stuck with our original workflows and structures designed many years ago.  We've grown and changed in ways that require some data changes. But we're stuck.  Here's just one example:  the "Resolved In" field is a number, but we've changed our release number schema to  a two decimal point as nnn.nnn.nnn, but we can only enter nnn.nnn.   So what do we do?  Looks like lots of lousy time-intensive workarounds.

Why won't fix?Disappointing

Under the section: "Changing Custom Field type via the database" you can read; how you are able to safely change the some custom fields.

I really would like to have this supported for obvious scenario's. For instance when the usage of a single radiobutton field grows with more and more values, changing it to a list would be nice.

Think the development time is not that big on this feature and it would make a lot of people happy because it saved a lot of time!! How difficult could it be to switch for example from radio buttons to checkboxes? Can imagine that the other way around is functional not desired but still.. missing some data is better than making a completely new custom field and move things. 

As Ben says, the KB's workarounds are all awful. After trying them all I wrote my own KB article documenting the SQL and CSV Importer options in gruesome detail.

Another workaround covered is the Copy Custom Field Values built-in script in the ScriptRunner plugin. Give it a filter of affected issues, an old and new field, and it transfers values from old to new.

I can somewhat understand what Atlassian didn't want to touch this. Think of all the places a custom field could be referenced: filters, gadgets, Agile card layouts, workflow conditions/validators/postfunctions, Groovy scripts, and configuration of random plugins. Now consider: which of these custom field 'consumers' care about the field type and cardinality? Clearly many will. JIRA's core is unable to guarantee that changing a field type won't break stuff. 

I need this feature too. Not sure why this cannot be supported