Upgrades & modernization

Ember's release discipline is one of the best reasons to keep an app on it — LTS lines, documented deprecations, codemods for the big idiom shifts. But that only helps if someone does the work, and on a business-critical app with the original authors gone, "someone" is the hard part. That's the work we take on.

What this covers

• LTS-to-LTS upgrades — moving through supported release lines deliberately: clear deprecations on the current version, bump, stabilize, repeat. We keep the app shippable at every step; upgrades land as a stream of normal PRs, not a frozen branch.
• Classic-to-Octane conversion — native classes, Glimmer components, tracked properties, angle-bracket invocation. Run in a working order that keeps the codebase mixed-but-consistent while conversion proceeds, with codemods where they're safe and hand work where they aren't.
• Addon replacement — retiring abandoned or incompatible addons: swapping in maintained equivalents, vendoring what's small enough to own, or rewriting the few pieces that deserve it.
• Embroider and build modernization — moving the build to Embroider, ratcheting up the static flags, and getting to route-based code splitting and modern tooling.

How we work

Modernization is incremental by policy. We don't park the roadmap while we upgrade — the measure of success is that feature work continues throughout, and your team understands every change that landed. Where your engineers pair with ours, the upgrade also functions as training.

Engagements are hourly time and materials with senior US engineers; an assessment usually comes first so effort ranges are grounded in your actual codebase. Get in touch to talk through where your app is stuck.