Convert old service and platform keys to modern action syntax

Modernize an existing automation without changing its entity targets or intended behavior.

Older Home Assistant examples often contain service calls and platform trigger definitions. Modern examples use action and trigger in those places, together with plural top-level list names. A careful conversion improves consistency when you read current documentation. Treat it as a small configuration refactor: preserve behavior, review the diff, and test one automation before updating a collection.

Save a working copy first

Copy the original automation into a local backup before editing. Record its alias, entity IDs, conditions, timing, and run mode. If it already has an id, preserve that identity unless you intentionally want a separate automation. Avoid creating two enabled copies of the same rule during testing, because duplicate runs make it hard to tell which version performed an action. Work on one rule with a visible, reversible effect.

Rename the outer list keys

At the top level of the automation mapping, change trigger to triggers, condition to conditions, and action to actions. These keys describe collections. Keep their contents and indentation intact. A singular condition inside a condition mapping still describes its type, such as condition: state, and must not become conditions. The same word can have a different purpose at another depth, which is why global text replacement is risky.

A starting-point automation

Every entity ID below is an example. Replace it with your actual entity ID and review all settings before use.

alias: Modernized hallway light
description: The same motion response expressed with modern keys.
triggers:
  - trigger: state
    entity_id: binary_sensor.hall_motion
    to: "on"
conditions: []
actions:
  - action: light.turn_on
    target:
      entity_id: light.hall
mode: single

Update each trigger definition

Within the triggers list, the legacy platform key becomes trigger. For example, platform: state becomes trigger: state. Keep entity_id, from, to, for, and any trigger id as they were. Do not rename unrelated platform fields in other configuration files. This guide concerns automation structure; Home Assistant uses many integrations with their own schemas, and a matching word elsewhere does not establish the same migration rule.

Update action calls and nested sequences

Within actions, replace service: light.turn_on with action: light.turn_on. Keep target and data unchanged unless you are deliberately making another functional change. Calls can also appear under choose sequences, repeat sequences, if branches, default branches, or parallel groups. Review those nested blocks individually. The change of key does not mean an integration gained new capabilities or that an old action name should be invented anew.

Leave templates and user text alone

A template might contain a variable named service or a string mentioning a platform. Notifications and descriptions may use those words in ordinary sentences. They are data, not necessarily schema keys. YAML-aware processing can distinguish mappings from text more reliably than a regular-expression replacement. Even a structured converter still needs review: integrations can accept arbitrary data mappings, and changing those values may break something outside the automation schema.

Compare meaning, then test

After conversion, compare the old and new documents side by side. Check target scope, quoted states, durations, conditions, and mode. Save through Home Assistant and resolve any validation errors. Test an actual trigger and inspect its trace, then confirm the resulting device state. If the original automation already works, there is no need to mix this cleanup with a new schedule or additional branches. Small changes are easier to understand and reverse.

Avoid mistaking formatting for a functional change

A YAML serializer may reorder keys or switch quote styles while preserving the underlying data. Those differences can make a text diff noisy, so focus on the parsed values and structural locations that changed. Comments may need to be restored after conversion, particularly notes explaining an unusual timeout or exception. Keep those explanations near the relevant logic. Once the converted automation has passed a real trigger test, remove any temporary disabled copy you made so later maintenance does not accidentally revive an obsolete version.

Further reference: official Home Assistant documentation.