Since the schema version of modules is stored in the key-value storage, it is unique to each site and is not synced through configuration management. That makes sense, since updates may need to make adjustments that are not encapsulated in config (such as database updates), but there are other changes that may also be included in config (e.g. adding a new config value).

  • Are there any risks to running config import and database updates in either order?
  • What is the preferred order for running those operations?
  • Do update hooks need to make any special accommodations for config items that may have already been imported?
  • Are there any other operations that may be required to fully update the production environment?

1 Answer 1


Updates must be run before configuration is imported

A pending issue against core will ensure that the code and schema versions match before allowing configuration to be imported.

Problems with config import before updates

  • An update hook relying on a configuration value could end in a different result than if it were run on the pre-import value.

  • An update could potentially fail if it tried to create configuration entities that already exist.

Concerns for config import after updates

  • If an update that introduces a new configuration entity is run first, it will create a new configuration item that will have a differing UUID than the one that is in config. However, once the config is imported the entity should be replaced with the config version.

    There could be a potential problem here if replacing the entity would affect associated content. For example, if an update migrates content from one field to another, on config import the field would be completely replaced and the content potentially lost. In this instance the deployment process may need to be adjusted to run the updates on the target environment and export the resulting configuration.

  • I had previously left an answer that order doesn't matter (just that the order of updates and config should be the same as it was implemented). I'm thinking I was wrong, because you should always export config after updating. So, on local, update then export, on deploy, update then import. May 26, 2016 at 14:59
  • As the linked issue discusses, there is a case where our entity updates require a new field to be imported or else the post_update hook will fail. In this case, we need the config import done before the database updates. Seems the freshest take on this is here: drupal.org/project/drupal/issues/2901418
    – atwixtor
    Nov 1, 2018 at 17:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.