This is an case where you know that the change won't destroy existing data, but Drupal doesn't have the ability to figure that out, so it blanket blocks all such requests.
Here's an example that manipulates radio options, but the technique for changing an address field will be fundamentally the same:
/**
* Updates allowed values for field_custom_radio_buttons.
*/
function mymodule_update_8001(&$sandbox) {
// Queries for relevant nodes already using that field.
$nids = \Drupal::entityQuery('node')
->condition('type', 'my_custom_content_type')
->condition('field_custom_radio_buttons', 'green')
->execute();
// Loads queried nodes.
// NOTE: If you have a non-trivial number of nodes to modify,
// you should use the Batch API to drive your update function instead.
// @see https://api.drupal.org/api/examples/batch_example%21batch_example.install/function/batch_example_update_8001/8.x-1.x
$nodes = Node::loadMultiple($nids);
// Updates field_custom_radio_buttons values.
// Replaces any “green” values with “blue”.
$updated_value_map = [
'green' => 'blue',
];
/** @var \Drupal\node\Entity\Node $node */
foreach ($nodes as $node) {
$node
->set('field_custom_radio_buttons', $updated_value_map[$node->field_custom_radio_buttons->value])
->save();
}
// Updates field storage config for field_custom_radio_buttons.
// @see https://www.drupal.org/node/2012896
// @see https://www.drupal.org/docs/8/api/update-api/updating-entities-and-fields-in-drupal-8#example-updating-a-field-from-an-obsolete-type-to-a-new-type
$old_config = FieldStorageConfig::loadByName('node', 'field_custom_radio_buttons');
$new_config = $old_config->createDuplicate();
$new_config->original = $new_config;
$new_config->enforceIsNew(FALSE);
$new_config
->setSetting('allowed_values', [
'red' => 'red',
'blue' => 'blue',
])
->save();
}
Company
you must first remove all submitted content using this field.