How do legacy _template definitions interact with composable _index_template definitions?

## Two generations, two matching rules Elasticsearch has carried two template systems since 7.8. The older one, registered at `PUT _template/<name>`, is now called a **legacy** or v1 template. The newer one, at `PUT _index_template/<name>`, is the **composable** template, and it brought component templates and `priority` with it. They do not merge with each other. The resolution rule is a strict tier check at index creation: 1. Does any composable index template match this index name? If yes, that tier decides — the highest-`priority` composable template applies and legacy templates are ignored entirely. 2. Only if no composable template matches does Elasticsearch fall back to legacy templates. Within the legacy tier the semantics are the old ones: **all** matching legacy templates are merged, sorted by the `order` field, with higher `order` applied later and therefore overriding lower ones. Within the composable tier, exactly one template applies. ## Why that makes migration awkward The two tiers encode opposite philosophies. Legacy templates compose implicitly through overlapping patterns — you add a template matching `logs-*` and it layers onto everything already matching `logs-app-*`. Composable templates compose explicitly through `composed_of` — overlap between index templates is a conflict, not a feature, and equal-priority overlap is rejected outright. So a mechanical conversion of each legacy template into a composable one is usually wrong. Three legacy templates matching `*`, `logs-*` and `logs-app-*` previously all contributed to `logs-app-1`. Convert them naively and only one of the three will apply; the other two contribute nothing, silently. The correct translation is: - inspect the current effective result — the merged configuration the legacy tier actually produced for a representative index name; - split that result into **component templates** by concern (cluster-wide settings, shared field schema, per-family fields); - create **one composable index template per index family**, with narrow `index_patterns`, an explicit `priority`, and a `composed_of` list that reproduces the old layering in order; - verify with `POST _index_template/_simulate_index/<name>` that the composed output matches what the legacy tier produced. ## The dangerous middle state During migration both tiers exist, and the tier rule creates a sharp edge: **the moment a composable template matches a name, the legacy templates for that name stop contributing.** Not "stop overriding" — stop contributing entirely. If your new composable template covers settings but you forgot the analyzer that a legacy `*` template used to supply, indices created from that point on quietly lose the analyzer. That makes the safe sequence: build the composable template, simulate the names it will claim, diff the composed result against the mapping of a recent index created under the legacy tier, and only then apply it. The diff is the whole safety net. Do it per index family and cut families over one at a time rather than in a big bang, so a mistake affects one family's next index rather than every family's. ## Practical mechanics `GET _template` lists the legacy templates, `GET _index_template` the composable ones — worth running on any cluster you inherit, because clusters accumulate templates from long-departed teams and from installed integrations. Applying legacy templates raises deprecation warnings, so grepping the deprecation log is a decent inventory of what is still live rather than merely stored. Two hard constraints push the timeline. Data streams can only be backed by composable templates — a legacy template cannot declare `data_stream` — so any move to data streams forces the migration for that family. And legacy templates are deprecated, meaning they are on a removal path; leaving them in place is accruing an upgrade blocker, not holding a stable position. ## What to say in an interview The three points that matter are: composable beats legacy outright rather than merging with it; legacy merges all matches by `order` while composable picks one winner by `priority`; and therefore the migration has to materialise an implicit merge into explicit components, verified with the simulate API before cutover. Candidates who can explain *why* the merge semantics differ — implicit composition through overlap versus explicit composition through `composed_of` — are demonstrating that they have actually done it rather than read about it.