Home / Blog / Article
Unity Engineering · Aug 5, 2026
Unity DOTS/ECS for Mobile: When the Migration Is Actually Worth It
Every few months a studio asks us to “port the game to DOTS” because a conference talk made it sound like free performance. DOTS is real, and the performance gains are real, but the migration cost is also real, and for most mobile titles it is the wrong trade. This is how we actually decide, and what the decision looks like once entity counts and team size are on the table instead of a slide deck.
What DOTS Actually Changes At Runtime
Unity’s Data-Oriented Technology Stack replaces the GameObject/MonoBehaviour model with entities, components, and systems that operate on tightly packed memory. The practical effect is cache-friendly iteration: instead of chasing pointers across scattered heap allocations, the Burst-compiled job system processes thousands of entities in contiguous arrays, often across multiple CPU cores at once. For a game simulating a few hundred agents, this is invisible. For a game simulating tens of thousands of units, projectiles, or particles every frame, this is the difference between 15 FPS and 60 FPS on the same device.
The Real Cost Of A DOTS Migration
The part conference talks skip is that DOTS is not a checkbox, it is a different programming model. Existing MonoBehaviour logic, your UI bindings, your animation state machines, your third-party plugins built for classic GameObjects: none of it ports directly. Teams underestimate this by a wide margin. A mid-size mobile codebase with two years of GameObject-based gameplay logic realistically needs three to six months of dedicated engineering time to convert the performance-critical subsystems, not the whole game, just the parts that actually need DOTS. Budget accordingly, and budget for a slower first few weeks while the team builds fluency with jobs, Burst compilation constraints, and the different debugging workflow.
Where DOTS Wins: High Entity Counts And Deterministic Simulation
DOTS earns its keep in a narrow but real set of cases: tower defense games with hundreds of simultaneous units and projectiles, city builders simulating thousands of independent agents, physics-heavy simulations, and any title that needs deterministic lockstep simulation for competitive multiplayer. We have taken a tower-defense prototype from 22 FPS with 400 active units on a mid-range Android device to a stable 60 FPS after converting the unit movement, targeting, and projectile systems to ECS, while leaving UI, menus, and audio entirely on the classic GameObject pipeline. That hybrid split is the pattern that actually ships.
Where DOTS Loses: UI-Heavy Casual And Mid-Core Games
Most hybrid-casual and mid-core mobile games simply do not have the entity counts to justify DOTS. A match-3 board, a runner with a few dozen obstacles, a card game, a simulation game with a hundred or so interactive objects: these run comfortably on the classic GameObject model with ordinary optimization discipline. Migrating them to DOTS adds real engineering risk (a smaller talent pool who can maintain the code, a less mature UI toolkit inside DOTS, fewer battle-tested third-party plugins) for performance headroom the game will never actually spend. If your build is not CPU-bound at the entity-simulation layer, DOTS will not fix your frame rate, and the profiler will tell you that before any migration decision should be made.
The Hybrid Pattern We Actually Ship
The DOTS migrations that succeed are never full rewrites. They convert exactly the subsystem that is CPU-bound, usually simulation, movement, or collision at scale, into ECS, and leave everything else, UI, audio, save systems, ads and IAP integration, on the classic GameObject pipeline using the GameObject/Entity conversion workflow to bridge the two. This keeps the surface area of the migration small, keeps your existing plugin ecosystem intact, and lets the team ramp up on jobs and Burst without having to relearn UI, animation, and audio at the same time. We treat DOTS the same way we treat any other targeted optimization: profile first, isolate the bottleneck, convert only that, measure again.
A Migration Readiness Checklist
Before committing engineering time to a DOTS migration, confirm four things: the Profiler shows the CPU cost concentrated in a specific simulation or update loop, not spread evenly across many small systems; the affected system involves at least several hundred concurrently active entities, since below that threshold the classic pipeline is not your bottleneck; the team has, or can dedicate someone to build, working familiarity with the Entities package, Burst compiler constraints, and the job safety system before the migration starts, not during it; and the subsystem being converted is relatively self-contained, without deep coupling to UI or third-party plugins that would need to be rewritten alongside it. If two or more of these are not true, the migration cost will exceed the return.
What We Tell Studios Asking About DOTS
Almost every conversation starts the same way: “should we move to DOTS.” We answer with a different question first: what does the Profiler say is actually slow. In roughly seven out of ten cases the real bottleneck is draw calls, overdraw, GC allocations, or unoptimized shaders, none of which DOTS fixes, and all of which are cheaper to resolve than a migration. In the remaining cases, where the bottleneck genuinely is large-scale simulation, DOTS is worth the investment, and we scope it as a targeted conversion of that one subsystem, with a measurable before-and-after frame time as the acceptance criteria, not a full-engine rewrite.
Keep Reading
More from the blog
Want these insights on your build?
The engineers writing these articles are the ones who would work on your game.