Ember.js End of Life —
The LTS Cadence & Every EOL Date

Ember.js moves on a steady release train, designating Long-Term Support (LTS) releases on a regular cadence — which means older versions reach end of life just as steadily. As of now, Ember 7.0 is the current release, with the 6.12 and 6.8 LTS lines still supported; Ember 6.4 reached EOL on June 22, 2026, the interim 6.9–6.11 releases are already EOL, and every 5.x release and earlier is end of life, including the once-ubiquitous 3.28 LTS.

This page is the reference for Ember.js end-of-life: every tracked version's EOL date and EOL Risk Score™, how the LTS cadence works, the Octane shift that stranded so many older apps, and the ember-cli-update path to a supported release.

Ember Version EOL Schedule

Everything through Ember 6.4 is now end of life; the supported set today is 6.8 LTS, 6.12 LTS, and 7.0. Scores below are live EOL Risk Scores™ — click any for the full breakdown.

How Ember's LTS Cadence Works

Ember releases on a roughly six-week train, and periodically blesses a release as LTS (Long-Term Support). The LTS releases are the ones most teams target, because they get a longer, fixed support window than the regular six-week releases. When that window ends, the LTS — and everything before it — is end of life.

The practical effect: a new LTS arrives roughly every couple of quarters, and an older one drops off at a similar rhythm. Like Angular, Ember rewards a standing upgrade habit and punishes the "set it and forget it" approach: stay on the current or immediately-previous LTS and upgrades are small; let several LTS windows pass and the gap compounds into a real project.

The Octane Shift — Why 3.x Apps Got Stuck

The reason so many Ember apps are stranded years back isn't the six-week cadence — it's Octane. Ember Octane (which became the default edition in the 3.x series) modernised Ember substantially: Glimmer components, tracked properties for reactivity, native classes, and a move away from the classic object model and computed properties. It was a genuine improvement, but it changed enough idioms that migrating a large classic-Ember app to Octane patterns is real work.

Many teams paused on a late classic 3.x release — 3.28 being the common resting point — and never made the jump. Those apps are now multiple major versions and several years past EOL (3.28 has been end of life since January 2023). The longer they sit, the larger the combined Octane-plus-version-gap migration becomes.

Ember 6.x LTS and 7.0 — The Supported Line

Upgrading with ember-cli-update

Ember provides first-party tooling for exactly this migration, and the discipline is the same as any fast-cadence framework: small, frequent steps beat one giant leap.

• 01
  Find your current version and LTS gap Check ember --version and your package.json. Cross-reference against the table above to see how many LTS windows behind you are and when your version reached EOL — that's your migration backlog.
• 02
  Run ember-cli-update, one LTS at a time The official ember-cli-update tool migrates your app's files and configuration toward a target version and surfaces the diffs to resolve. Step through LTS to LTS rather than jumping the whole gap at once — each step is reviewable and testable.
• 03
  Clear deprecations before each major Ember's deprecation warnings are your migration checklist. Resolve the deprecations flagged in your current version before moving to the next major — that's what keeps each jump from turning into a debugging marathon.
• 04
  Adopt Octane idioms where you're still classic If you're coming from classic Ember, migrate to Glimmer components, tracked properties, and native classes as you go. The codemods and the official Octane migration guide handle much of the mechanical conversion.
• 05
  Update addons in lockstep Ember's addon ecosystem tracks the framework's versions — a lagging addon is the most common blocker for an Ember upgrade. Confirm each addon supports your target before moving, and replace any that are themselves abandoned.