Ember 4 To 5 Migration

Ember 4.12 → 5.x Migration

If the prerequisites in ember-4-recommendations are met (Embroider at least in compat mode, official TS setup, Octane settled, addons 5-compatible), the 4 → 5 jump is mostly a version bump plus opt-in features. The headline work is:

1. The version bump itself.
2. The addons rolling forward.
3. Adopting <template> tag and Glint's template-imports environment (optional but recommended).
4. Adopting the @ember-data/request request manager (optional).

4.12 LTS  →  5.4  →  5.8  →  5.12  →  ...latest LTS
                                         ↓
                                       (continue with `ember/` plugin)

Pre-flight

Verify on 4.12:

• No Ember.X global imports anywhere.
• All ember-data relationships specify async and inverse.
• No classic test API (moduleForXxx) anywhere.
• No (mut ...) or (action ...) template helpers.
• Embroider in compat mode (or optimized).
• If TypeScript: official setup, no ember-cli-typescript addon.
• All addons in package.json ship versions that support both 4.12 and 5.x.
• Test suite green; deprecation workflow file empty or owner-tagged.

If anything's unchecked, finish on 4.12.

What 5.x removes / changes

The full removed list is in the official Deprecations app; filter to "since: 4.x".

What 5.x adds

Hop-by-hop

5.x's release cadence has been less predictable than 4.x's, but the LTS-by-LTS approach is still the safest. Bump to each LTS in order, run the suite, run the codemods, smoke test, ship. Rough cadence:

4.12 → 5.4 LTS

The biggest hop. Most removals land here. Specifically:

• ember-cli-typescript is no longer needed — remove it from package.json, replace its tsconfig.json with @tsconfig/ember/tsconfig.json.
• Older ember-data paths get cleaned up — relationships without explicit options error out (they were warnings in 4.12).
• Many addons release "5.x-compatible" majors here — bump them in the same window.
• Embroider becomes the preferred build pipeline for 5.x. If you're still on classic ember-cli, expect rough edges.

pnpm exec ember-cli-update --to 5.4
pnpm exec ember-cli-update --run-codemods

5.4 → 5.8 LTS

Quieter. Mostly addon ecosystem catching up.

This is a good moment to:

• Adopt <template> tag for a small number of new components. Not a migration of existing code — just new files.
• Install @glint/environment-ember-template-imports and turn it on in tsconfig.json.

5.8 → 5.12 LTS

The last 5.x LTS in the predictable cadence (subject to the actual release schedule). At this point:

• Glint is stable enough for whole-codebase use.
• Most major addons ship Glint signatures.
• The <template> tag is everywhere in new code.
• The @ember-data/request request manager is the recommended way to do fetches.

This is the handoff point to the ember-polaris-migration skill — Polaris-style authoring is now mainstream.

TypeScript / Glint adoption order

If you're adding template type-checking during the 5.x window:

1. Bump to 5.x with the JS-only TS setup intact.
2. Stabilize. Run the suite. Smoke-test.
3. Install Glint and the ember-loose environment.
4. Add component signatures to every component. Most should already have them from the 4.x phase.
5. Run glint --watch until the codebase is clean.
6. Add glint --noEmit to CI.
7. Install ember-template-imports and the matching Glint environment.
8. Adopt <template> tag for new components. Don't migrate existing ones in the same window.
9. Plan a slow migration of existing components to <template> tag, opportunistically when you'd touch them anyway.

ember-data — the request-manager transition

@ember-data/request is opt-in throughout 5.x. The transition shape:

// existing 4.x style — still works in 5.x
const post = await this.store.findRecord('post', '42');

// new 5.x style — coexists with the above
import { findRecord } from '@ember-data/json-api/request';
const { content: post } = await this.store.request(findRecord('post', '42'));

Don't rewrite all existing fetches at once. Two practical lines:

1. New endpoints use the request manager. Especially custom RPC endpoints — no more custom adapter required.
2. Existing endpoints stay on the legacy findRecord/query API until you're touching them anyway.

The legacy adapter/serializer pipeline survives in 5.x. WarpDrive is the long-term direction; for a 5.x app today, you're fine with both styles coexisting.

<template> tag adoption

Same advice as for the request manager: new files in .gts, existing files stay. Plan a slow migration.

When you do migrate a file:

1. Rename foo.ts + foo.hbs → foo.gts.
2. Wrap the .hbs body in a <template>...</template> inside the class.
3. Add import statements for every component, helper, and modifier referenced.
4. Run Glint. Fix the resulting errors.
5. Delete the old .hbs (it's gone — confirm via git status).

See the ember-polaris-migration skill for the full workflow.

Addon survival list (4 → 5)

Rough categorization at the time of 5.x's mature releases:

Time estimates (rough, mid-size app, 4.12 prerequisites met)

If 4.x prerequisites aren't met, add 2–4 weeks to fix them on 4.12 first.

Common 4 → 5 surprises

Verification — at the latest 5.x LTS

• ember-source on the latest 5.x LTS.
• ember-data matching.
• ember-cli-typescript not in package.json.
• All component signatures declared.
• (Optional) Glint passes in CI on ember-loose environment.
• (Optional) Glint passes on ember-template-imports environment.
• (Optional) New components use <template> tag.
• All addons on 5-compatible versions.
• Embroider in compat or optimized mode.
• CI green; suite passes; manual smoke-test passes.
• Deprecation workflow file empty.

When all green, switch to the modern Ember skills for ongoing work — Polaris adoption, the modern addon skill, and the ember-architect / ember-test-engineer agents take over from here.

See also

• ember-4-recommendations — the prerequisite work.
• ember-polaris-migration — <template> tag adoption.
• ember-typescript-and-glint — Glint setup at the destination.
• Official: emberjs.com/releases/, Deprecations, @ember-data/request.