The migration problem was bigger than a technology swap
The old custom engine had become expensive to maintain and increasingly hard to staff. Meanwhile the portfolio was already live, so the migration had to happen without breaking the user experience across roughly 20 existing apps.
The work moved in waves rather than one big cutover. The products were swapped one by one, which let the client modernize while keeping the portfolio active.
Older devices were part of the business logic
In children’s apps, older devices were not an edge case. They were an important part of the actual market. Families often installed these products on older phones and tablets, so compatibility and footprint mattered commercially.
That shaped the implementation heavily. The Unity target had to stay light, efficient, and capable of running on older hardware and older OS versions.
- Low app weight
- Compatibility with older mobile devices
- Careful visual optimization
- Preserved smoothness and art fidelity
The bigger move was turning many apps into one content container
The client wanted to stop selling only a large portfolio of separate apps and move toward one larger application with many smaller experiences inside it. That opened the door to better lifecycle value and a more unified user journey.
The resulting platform allowed the base app to stay lightweight and install quickly, while additional mini-apps or content packs could be downloaded on demand.
The project stopped being only a porting effort once the product became a container for future content instead of a shelf of disconnected apps.
The delivery system became a content factory
The real long-term advantage came from the internal framework layer. Reusable mechanics, packaging rules, and build guardrails let outside developers create new content much faster and with lower qualification requirements.
That meant the client did not have to scale the internal team in the same way. A relatively small core group could govern a much broader content machine.
What the business gained
The result was more than a working migration. Support became easier on a unified stack, bug-fixing simplified, content production costs dropped, and new content could be created and delivered with much less friction.
Most importantly, the client used external engineering intensity for a limited period, learned from the resulting codebase and systems, and continued growing with a small internal team instead of permanently ballooning headcount.