
Konstantin Krivopustov
Head of Jmix Engineering

Migration from CUBA Platform to Jmix is no longer just a general modernization plan. It is a practical engineering task with a repeatable workflow, dedicated tooling, and real lessons learned from migrating an actual business application.
In this webinar, we will show how the Jmix team approaches migration, what tools are already available, and what to expect when moving from CUBA Generic UI to modern Jmix architecture.

This webinar is for teams still running applications on CUBA Platform and evaluating the next step.
📍Technical decision-makers — assess feasibility, risks, and effort
📍Team leads & architects — understand target architecture and migration flow
📍Developers working with CUBA — see how migration works in practice
📍Organizations planning modernization — decide between in-house vs Jmix-assisted migration
.png?width=2000&height=1646&name=%D0%8F%C2%AE%C2%A7%20%20(18).png)
How to break migration into manageable phases instead of treating it as one giant rewrite
What the Jmix team already provides to support migration, including tooling, workflow, and practical guidance
How to assess effort and identify the areas that usually drive complexity
A walkthrough of migrating the Timesheets application from CUBA Platform to Jmix, including non-trivial UI and business logic
What tends to go smoothly, where teams usually hit friction, and how to reduce migration risk
Where AI can accelerate repetitive migration work and where human engineering judgment is still required
What changes when a legacy platform stops being a comfortable base for future delivery
What can be migrated systematically, what needs redesign, and why UI deserves special attention
A practical look at the workflow and tooling provided by the Jmix team
How to assess project scope before work starts
A walkthrough of migrating a real application from CUBA Platform to Jmix
Custom screens, tricky behavior, iterative fixes, and validation
How AI agents support migration
work in practice
How to approach migration in your own project, either independently or with support from the Jmix team
You still have one or more active applications on CUBA Platform
You want to estimate migration effort before committing budget
Your team needs a structured migration strategy, not just general advice
Your application includes custom UI, reports, or security logic
You want to understand whether migration can start internally
You want to know when involving the Jmix team makes economic sense


What does migration from CUBA to Jmix actually involve?
Which parts are relatively predictable, and which need special care?
What tools and practices does the Jmix team already provide?
How should we estimate our own migration scope?
Can our team start this work ourselves?
When should we bring in the Jmix team for assistance?

Head of Jmix Engineering

Jmix Product Manager