Best practice to deploy an update which depend of a new configuration
I would recommend that you create the field programatically. In your update function. You could also create multiple update functions, just create the field in one, then migrate the data then remove the old field.

If you have a lot of data, then your update function should be done as a batch, so it doesn't run in any PHP timeouts or memory limits. In that case, having the update functions separate makes it easier to implement them.

To avoid duplicating code, you could read the config from the config sync storage and create it through the config entity storage, something like this:

$config_record = \Drupal::service('config.storage.sync')-&gt;read('field.storage....');
$storage = \Drupal::entityTypeManager()-&gt;getStorage($entity_type);
$entity = $storage-&gt;createFromStorageRecord($config_record);
$entity-&gt;save();


This is usually fine for custom update functions in projects because it will only be executed once. This approach is risky for core/contrib/reused modules (which usually import it from their default config) because you don't know when the update will be executed. Maybe you have to make another change to that config next week and add another update function to deal with that change, but if someone didn't execute the first yet, this initial update will already create the field based on the latest schema and then your update logic might get very confused about that.