Is it possible to move data from a contact type to a component/extension?
It's good to be thinking about where the data is stored, but don't let your thinking ahead get in the way of getting started somewhere.  It's not unusual for organizations using CiviCRM heavily to decide they need to remap data somehow, and the fact that the data is in CiviCRM somewhere already makes it one step easier.  The short answer is that you should put your data in the place that makes the most sense right now, and if you have to move it later, it'll take a little bit of work, but nothing overwhelming.

Since you're worried about just some potential future place to store data, I'll have to be a bit abstract, but the principle should hold.

There are two main tasks you'd face if you were to decide that your data in custom fields really belongs in different custom fields or an extension's ad-hoc tables.  The first is moving data, and the second is any transformation that may be necessary.

Using SQL queries, moving data to and from custom fields is relatively easy.  You'll end up doing something like

INSERT INTO civicrm_value_newtable
SELECT NULL as id, entity_id, oldfield AS newfield
FROM civicrm_value_oldtable


to move the data from one custom field to another.  Of course, you could also export to CSV and then import from CSV, mapping the old field's column to the new field.  Since you have the contact ID, you know who a value belongs to.

The more challenging aspect is if you need to transform the data.  Maybe you have three categories, and the new system takes four.  Maybe you have two fields where the new system has one, or vice-versa.

Not knowing what situation you might encounter, the only thing you can do is to pick the most useful and accurate ways to store your data now.  The better your data now reflects reality, the more reliably you can transform it into something else.

When it does come time to transform, you can do SQL functions; and export, alter within CSV, and import; or a series of SQL insert queries, such as

INSERT INTO civicrm_value_newtable
SELECT NULL AS id, entity_id, "option1" AS newfield
FROM civicrm_value_oldtable
WHERE oldfield = "A";

INSERT INTO civicrm_value_newtable
SELECT NULL AS id, entity_id, "option2" AS newfield
FROM civicrm_value_oldtable
WHERE oldfield = "B"
  OR oldfield = "C";


and so on for each new possible value.

In sum, don't let the perfect be the enemy of the good, and don't work so hard to prepare for vague possibilities that it's not functional now.  "If it's a life of possibilities that you wanna live...."