The Migration & Deprecation Radar

This one isn't a recommendation, it's a fact: PhysX and APEX were replaced by Chaos and are gone from modern Unreal Engine. There is no compatibility toggle to flip back, no setting to keep the old simulation alive. If a codebase still carries PhysX-era assumptions — direct PhysX API calls, APEX cloth/destruction assets, `bUseChaos`-style branches — they are dead paths on 5.7.

We place it firmly in Migrate now because the migration is not optional and not deferrable: the engine you build on today already made the decision for you. In practice the work is mechanical — re-author cloth and destruction on Chaos equivalents, and delete the dead branches. For most projects this was done releases ago; if it wasn't, it's the first thing to clear, because nothing else compiles around it.

This blip is about a *default assumption*, not a removed feature. Static lightmapping still exists and is supported, and it remains the correct choice for fixed-hardware, performance-critical scenes where you can afford no dynamic GI cost. What's changed is that Lumen is now the production-ready dynamic-lighting default in UE5, and reaching reflexively for a fully-baked pipeline on a new project is increasingly the legacy instinct.

We say Migrate soon at the level of the default, not the technique. If you start every new scene by building lightmaps out of habit, that habit is dated — start from Lumen and fall back to baking deliberately where the budget demands it. Note that the old CPU lightmass path has long since given way to the GPU Lightmass for teams that do bake. Don't tear baked lighting out of a shipping project that relies on it; do stop treating it as the automatic starting point.

We include this one specifically to *stop* a migration mistake. The deferred renderer is the default and the home of Nanite, Lumen and Virtual Shadow Maps; the forward renderer is not deprecated — it's the right, supported choice for VR and many mobile and performance-bound targets where the deferred path's costs don't fit. Treating 'forward' as a thing to migrate away from is a category error.

So we place it in Still fine, with a caveat that runs the opposite direction to the rest of this radar. The legacy instinct to watch for isn't *using* forward rendering — it's *assuming* it for a desktop or current-gen-console project that would be better served by the deferred, Nanite-and-Lumen pipeline. Choose your renderer by your platform and budget, not by habit, and don't migrate off forward just because a checklist told you it was old.

Before World Partition, large UE worlds were assembled from a persistent level plus streaming sublevels, hand-managed by streaming volumes and level blueprints. World Partition — with Data Layers, One File Per Actor and automatic grid streaming — is now the production-ready, expected approach, and Epic's own large-world tooling is built around it. The old sublevel maps still load and run, so existing projects aren't broken.

We say Migrate soon for new large worlds and most actively-developed ones. The win isn't just streaming behaviour; it's the source-control and collaboration model — One File Per Actor removes the single-level merge-conflict bottleneck that made big-team level work miserable. The migration has a genuine learning curve and changes how the team works day to day, so it's a planned project, not a flip — but the destination is settled and the old workflow is the past tense.

Vegetation has always been Nanite's hardest case, and 5.7 added an experimental Nanite Foliage path plus a Procedural Vegetation Editor aiming to bring virtualised-geometry density to foliage. The direction is clearly right and the early results are exciting. But experimental means experimental — it is not something to rebuild a shipping vegetation pipeline on this release.

That's why this sits in Plan the move rather than 'soon'. Your current hierarchical-instanced-static-mesh foliage is not deprecated and works fine; there is no mature destination to migrate *to* yet. The right posture is to understand where the foliage pipeline is heading, prototype against the experimental path to learn its shape, and avoid over-investing in elaborate legacy foliage tooling you'll only have to unwind. Revisit the urgency when the Nanite Foliage path leaves experimental.

The classic heightfield Landscape system is not going anywhere yet — it coexists with newer terrain work and remains supported. What's on the horizon is an experimental Mesh Terrain system in the 5.8 preview, building large landscapes from a 3D mesh rather than a heightfield. If it matures, it's a meaningful rethink of the terrain pipeline; today it exists only in a preview build.

So the verdict is Plan the move, and barely on the board at that. There is nothing production-ready to migrate to, so don't. The legacy assumption worth questioning is the architectural one — designing a project as though heightfield Landscape is the *only* terrain model the engine will ever offer. Keep the option open, watch 5.8, and don't pour a fortune into bespoke heightfield-only tooling. Revisit when Mesh Terrain ships and earns a status.

The old project-settings Action and Axis Mappings have been superseded by Enhanced Input, which is the production-ready, expected input system in UE5 — input actions, mapping contexts and modifiers, and the assumed target of nearly all current tutorials and templates. The legacy bindings still function, so a project on them keeps working, but you're building on yesterday's default.

We place this in Migrate soon. There is no reason to author new input on the old system, and the migration is well-trodden and well-documented. For an existing project the move is bounded and worth scheduling; for new work it shouldn't even be a question. This is one of the cleaner 'new system has clearly won' transitions in the engine.

The single most consequential migration decision isn't any one subsystem — it's whether you let a project ossify on an old engine version at all. Every other entry here becomes painful in proportion to how long you defer the upgrade: PhysX assumptions, Cascade libraries, legacy input, UE4-era content all compound the further behind you fall. Building indefinitely on one ageing version isn't 'stability', it's debt accruing interest, and it's why we put this in Migrate now — the action is to adopt a deliberate upgrade cadence today, not to perform one heroic jump in three years.

The marketplace makes the stakes concrete. By the MythicLemon Marketplace Index, our own compiled dataset (as of 2026-05), UE5 is 93.2% of new monthly releases yet only 53.3% of the version-tagged catalogue — meaning 46.7% of tagged listings are still UE4, a standing modernisation backlog of content anchored to the old version. New supply has overwhelmingly moved to UE5; the back-catalogue hasn't followed. For a publisher, that gap is both a warning (don't add to the stale pile) and an opportunity (clean, current-version content stands out against it). Pick a cadence, keep moving, and you'll never face the others on this radar as a crisis.

Cascade is the original Unreal particle editor, and Niagara is its successor — the production VFX system across the whole 5.x line. Cascade still opens and still plays back, so an existing effect won't break tomorrow, which is exactly why so much legacy content still ships on it. But it is legacy in the plainest sense: no new investment, no new features, and every piece of current learning material assumes Niagara.

We say Migrate soon rather than 'now' because it isn't removed and a shipped effect that works is not an emergency. The line we'd draw is on *new* work: never author a new effect in Cascade, and convert your reusable, high-traffic systems to Niagara on a planned cadence rather than in a panic. The longer a Cascade library lives, the more it costs to move, and the day Epic finally retires the editor is a question of when, not if.

MetaSounds is the production-ready, node-based audio system and the modern way to author sound in UE5, with sample-accurate procedural control that the older Sound Cue workflow can't match. That makes MetaSounds the clear default for new audio work. But — and we're being deliberately careful here — Sound Cues are not removed and not formally deprecated; they remain supported, and plenty of perfectly good audio ships on them.

We place this in Still fine rather than 'Migrate soon' precisely to resist over-stating the urgency. The honest call: author *new* sources in MetaSounds, and don't bother ripping out a working Sound Cue setup that does its job. Migrate the pieces where MetaSounds' procedural power actually buys you something — dynamic, parameter-driven audio — and leave simple, static cues alone until you're touching that area anyway. This is the opposite of the Cascade story: same 'old vs new editor' shape, much lower temperature.

This blip is about *content authored to UE4-era assumptions* rather than a single API: skeletal-mesh setups and material graphs built before UE5's rendering, skin-weight and material changes. Such content usually opens in 5.7 via the conversion pipeline, but 'opens' and 'is clean' are different things — conversion warnings, shading-model mismatches, and material nodes that behave differently under the modern renderer are the day-to-day reality of dragging UE4-era assets forward.

We say Migrate soon, and this is where the marketplace numbers bite. By the MythicLemon Marketplace Index, our own compiled dataset (as of 2026-05), 46.7% of the version-tagged Fab catalogue is still UE4. A large share of that is exactly this kind of content — assets that technically install in a buyer's 5.7 project but greet them with a conversion wall. If you publish, re-authoring to UE5 assumptions is the difference between a clean install and a one-star surprise; if you consume, budget for the conversion rather than assuming a tagged-UE4 asset will land tidily. The newer Substrate material framework (production in 5.7) is the longer-horizon destination for material work — but its ecosystem is still catching up, so we'd not force that part of the move this release.

A subtle one, and we include it so the radar isn't only about leaving old *systems*. Niagara itself is the production VFX system and the right place to be — but it's an actively-developed one, and patterns from earlier 5.x versions (deprecated modules, older scratch-pad conventions, emitter setups Epic has since reworked) can throw deprecation notices or behave differently as you move up engine versions. This is intra-Niagara drift, not a Cascade-style 'whole system superseded' story.

We place it in Still fine: there's nothing to migrate *off* — you're already on the right system — so the posture is hygiene, not urgency. When you bump engine versions, read Niagara's deprecation notices, swap flagged modules for their current equivalents, and keep reusable emitter libraries tidy so the drift doesn't compound. Treat it as routine upkeep on a healthy system, not a project.