Editorial illustration; the screen is representative and is not a real Drupal installation.
Drupal sites often change in two places at once. Editors create content in the database, while site builders change content types, fields, views, roles and other settings. If a configuration change is made directly on production and nobody records it, the next deployment can overwrite it or leave environments behaving differently.
Quick Answer
Treat Drupal configuration as a deployable artifact. Make the change in a development or staging environment, export configuration to YAML, review the diff, commit it with the code that needs it, import it into the target environment and verify the result. Keep content separate from configuration and take a backup before a production import.
Drupal’s official documentation describes configuration as the administrative settings that determine how a site functions. It includes items such as content types, fields, taxonomy vocabularies and Views. The active configuration is stored in the database, while the configuration-management workflow lets teams export and synchronize it through files.
Configuration is not content
The distinction matters. A new article is content. A new field on the Article content type is configuration. A new taxonomy term may be content, while the vocabulary and its settings are configuration. A View definition is configuration, while the nodes returned by that View are content.
If you treat everything as content, important site structure remains trapped in one database. If you treat everything as configuration, you may accidentally overwrite editorial data or expect a configuration import to move user-generated content. Write down which category a change belongs to before planning the deployment.
The safer workflow
1. Start from a known environment
Refresh a development or staging database when appropriate and record the Drupal core, contributed module and PHP versions. The exact commands depend on how your project is managed, but the principle is the same: do not export from an environment whose code and database state are unexplained.
2. Make one focused change
Create the field, adjust the View, change a role permission or configure a module. Avoid mixing a large redesign with unrelated configuration changes. Small batches make the exported diff understandable and make rollback decisions less frightening.
3. Export configuration
Use the Drupal administration UI or Drush workflow documented for your project to export configuration to the sync directory. Do not assume that a successful export means the change is correct. Open the generated YAML and inspect the files that changed.
4. Review the diff
Look for the intended machine names, field settings, dependencies and permissions. A diff can reveal that an accidental UI click changed a View filter or enabled a module configuration you did not intend to ship. Never commit secrets or environment-specific values that do not belong in the repository.
5. Commit the configuration with supporting code
If the configuration refers to a custom module, theme, template or migration, deploy the compatible code as part of the same change. Configuration may import successfully while the site still fails at runtime if the code it expects is absent.
6. Test the import on staging
Take a fresh backup, import the reviewed configuration and exercise the affected path. Check anonymous and authenticated access, forms, Views, translations and cache behavior as relevant. If the import reports a dependency or schema problem, stop and resolve it before production.
7. Protect production content
Schedule the import with a plan for editors. Confirm whether new content may be created during the deployment and how you will handle it. Configuration imports should not be used as a casual substitute for content synchronization.
8. Import and verify
After importing on production, clear or rebuild caches only as required by the change, then test the public page and the administrative path. Compare the result with staging. Record the configuration commit, import time and verification notes.
What can go wrong
Direct production edits disappear
A site builder changes a View on production, but the next deployment imports an older configuration export. The View silently returns to its previous state. The fix is process, not a bigger cache clear: export and commit the production change, or recreate it in the proper development environment before the next import.
The sync directory is unclear
Teams sometimes assume the configuration directory lives in a particular folder without checking the project settings. Confirm the actual sync location and protect it from public access. Do not publish configuration files through a web-accessible files directory.
Configuration and code are out of step
A field formatter or custom plugin may require code that is not yet deployed. Importing the configuration first can leave the site with missing plugins or errors. Deploy compatible code and configuration in a tested order.
A configuration import is mistaken for a backup
Configuration files do not contain every piece of site state. Keep separate backups for the database, uploaded files and deployment artifacts. Test restoration before an emergency, not during one.
Practical habits for small teams
Keep commits focused and write a useful message. Ask someone else to review the YAML when permissions, access rules or public exposure are involved. Use a staging copy that resembles production. Keep a short deployment checklist with the backup location, import command, verification URLs and rollback decision.
Avoid importing a huge unexplained configuration bundle just because it is available. If the diff contains hundreds of unrelated changes, stop and find out why. Noise makes it easier to miss a permission change or an accidental module setting.
My Take
Drupal configuration management is valuable because it turns invisible database state into something a team can review. It does not remove the need for judgment. A clean export, a readable diff and a tested import are more important than memorising one command.
Bottom Line
Keep content in the editorial workflow and configuration in the deployment workflow. Build the change away from production, export it, review it, test it and import it with a backup and verification plan. Once this becomes routine, Drupal deployments become easier to explain and much harder to surprise.