With HA 2021.3.1 my automations in automations.yaml were forced into the UI without my permission. I had to move all my stripped comments into the description field. So I have successfully migrated.
I noticed the data_template: is not supported in the UI.
Why not? Is there a syntax change. Should I change data_template: to just data:
Yes. data_template was deprecated in favor of data several versions ago.
From which version did you upgrade to 2021.3.1?
Can you elaborate on what you mean?
Automations you create manually in automations.yaml cannot be edited in the Automation Editor because they lack a unique id. However, the moment you use the Automation Editor to compose a new automation and save it, it’s saved in automations.yaml. Any existing automations it finds in there that were created manually are automatically assigned a unique id and reformatted (including but not limited to: comments are discarded, double-quotes are replaced by two consecutive single-quotes, multiline templates are flattened, etc).
If you’re interested, there’s a simple way to keep manually-created automation separate from the ones composed using the Automation Editor.
Migrated from 2021.2.3 but have automations started several years ago. I think my “mistake” has to create a new automation in the UI. That triggered a conversion process that added id: and stripped comments. I replaced data_template: with data: I think that the conversion process could have done that for me? Most of the data: fields don’t appear in the UI like for these services: input_number.set_value and notify.mobile_app_iphone. I have to used the “edit as yaml” UI menu item. I do think it is less error prone to create an automation in the UI. Some “complex” operations must revert to yaml editting.
That’s what caused it (detailed explanation in my previous post).
I keep my manually created automations separate from any I may compose with the Automation Editor.
I found that some of my automation broke when converted to UI. For example this action:
service: climate.set_temperature
data:
entity_id: climate.house
temperature: "{{ states('input_number.slider_home')}}"
If I enter the above as yaml and save it does not accept it. Goes back to:
service: climate.set_temperature
data: {}
target:
entity_id: climate.house
Unless I can fix the syntax, I need to have a few automations separated into a new yaml file.
I see documentation how to split here. (At the very bottom of page.)
In your configuration directory, create a sub-directory called automations
Edit your configuration.yaml file, find the line referring to automation and add another one as shown below:
automation: !include automations.yaml
automation manual: !include_dir_merge_list automations/
Restart Home Assistant.
Any automations you create with the Automation Editor will be stored in the automations.yaml file within the configuration directory (i.e. as usual). However, any automations you create manually should be stored in the automations sub-directory where they are out of reach of the Automation Editor.
You can create as many automation files you want within the sub-directory. Each file can have a descriptive name (as long as it ends with the .yaml suffix). This gives you the flexibility to organize your automations by function.
I ended up manually editing the automations.yaml file to repair the broken automations that required a template expression for the service data. (Seems to affect the climate.set_temperature and input_number.set_value services)
The UI still reports the yaml as data: {} but the automation.yaml file contents shows the correct service data and the automations work.
The moment you use the Automation Editor to create/modify and save an automation, any manually-created/modified automations you may have in that file will be reformatted. The only way to avoid that is to separate the files as I described in my previous post.
FWIW, I used 2021.3.2 to confirm your observation that the template is seemingly lost when switching from YAML to UI mode in the Automation Editor. Showing one thing but doing something else is often categorized as a bug. You may wish to report it as an Issue in the Frontend repository.
Personally, I don’t use the Automation Editor because it has too many limitations and quirks for my needs.
@123 I understand this is an older post but was looking for detail to separating Automation Editor files (aka UI?) for the same reasons as you, but patience didn’t quite understand wording nor did it last to bottom of the splitting config [page].
This is great to comment & help learning akin to FrontPage 
At 60+, minute varying details produce profound impact on learning. Similar to bad English, dialects on most Youtube tutorials are challenging for me, adding confusion & some additional frustration.
In the new /automations directory, does each descriptivename.yaml require [id or uuid] or is it so long as each descriptivename.yaml is different, it does it not matter…?
Appreciate the community much & many of your posts as I navigate; in this case was enough to post a thank you 
In the end I did not bother separating the automations into different files. I just manually edited automations.yaml for the few cases that were not supported by the UI editor. ie a data template
The docs describe how to split the configurations files here. See the Advanced section at the bottom. Also see the Taras Mar 6 post. I guess that the unique ids are only required for the UI automation editor.
Automations created with the Automation Editor are automatically assigned an id with a unique, randomly generated value.
If you create an automation manually, you have to the choice of adding an id (with a unique value) or not. If you choose to omit it, when the automation executes it will not generate a trace. Traces are useful in diagnosing any problems that might occur during execution.
For more information about traces, refer to: Troubleshooting Automations.
@123 Wow, now I’ve got more to digest, this is great. Already used a few traces early on to help out. Suppose this would include generated UUID’s too as they seem unique…
Organizing by function -I like this idea as I’m not quite sure I understand the nomenclature about templates. To me, templates, like the use of the word scripts, seem not as I would describe. However until I understand getting around a little more, I’m organizing in that manner such that I can simply copy, modify, rename, use.
I’m not on Git yet, nor understand that (again, yet) so, many examples I’m unable to look at, though a building appetite from advanced projects. Currently using Visual Studio & RJ TextEd on individual automations, but need to see how others are organizing/building as this could get a tad larger and I hope to scale it 
Thanks…!