Jmix · CUBA Platform
Your CUBA system does not need rewriting. It needs its foundation replaced.
CUBA Platform has reached end of life. The vendor states it plainly: maintenance only, no new features, no security updates. That turns a technical preference into a compliance question — and it is the only reason this page exists, because nothing else about a working CUBA application is wrong with it.
The good news is the part nobody says out loud: Jmix is the same lineage. Your data model, your business logic and your database are not the problem, and they are not what you will pay for.
Scope
What moves by itself, what is checked, and what is written again
This is the only picture that matters when you are sizing the job. Jmix Studio performs a first pass automatically — it creates the new project, copies the sources, replaces the known framework classes, converts the screen descriptors, and writes a file listing what it could not do. Everything to the right of that file is your actual budget.
The honest part
Some things were removed and not replaced
This is the list an assessment exists to check, and it is the reason a migration quote given over the phone is worthless. If your application leans on one of these, the work stops being mechanical and starts being design.
- Attribute-level access control through the data manager, and the state-based variety with it.
- Screen component permissions — the fine-grained kind applied to individual controls.
- Session attributes in access groups, which is often how a CUBA system expresses "this user sees only their branch".
- The cluster manager API.
- Editor screen history.
- SQL Server 2005 support, which matters more often than it should.
None of these makes a migration impossible. Each of them changes the number, and a supplier who has not asked about them has not priced your project — they have priced an average one.
About the numbers you will be shown
One published figure, and why it should not reassure you
In March 2026 the vendor published an account of migrating their own Timesheets sample application — fourteen entities, thirty-five screens — with AI agents helping. The reported effort was 25 man-hours against a project estimate of 215. It is a real number, honestly reported, and the author says in the same article that results vary with project structure, custom UI, code quality and team experience, and that the case is not a general benchmark.
We quote it here for the opposite of the usual reason. A fourteen-entity sample written by the people who wrote the framework is the best case that exists. Your application has the screen somebody built in 2016 that nobody wants to touch, the access group with a condition in it, and the report nobody can regenerate. The gap between 25 and 215 in that article is not a discount you can expect — it is the size of the range an estimate without an assessment is guessing inside.
Agents genuinely help, and we use them: for repetitive framework-pattern conversion they are faster and steadier than a person. They do not help with the screen that has to be redesigned rather than converted, and that screen is usually the one your users care about most.
How it runs
Four stages, and the old system stays up through all of them
01 · Assessment
Two to five days with your codebase and your people. What you used of CUBA, what has no replacement, what the data looks like. Output is the document above, not a proposal.
02 · Foundation
The automatic pass, then the work it leaves behind: the project builds, the data model is in place, the database connects, and the security model has been rebuilt rather than approximated.
03 · Waves
Screens in batches, simple before complex, each batch tested before the next starts. The CUBA system keeps running and keeps being releasable the whole time — an urgent fix can still go out.
04 · Switch and hand over
Users move across when the Jmix system does what the old one did, not when the plan says so. Then documentation and a handover session with whoever maintains it — your team or another supplier.
Standing
We are not describing this from the documentation
Smart Comune — a municipal request-management system serving around 80,000 residents — was built on CUBA Platform and has been in production since 2020. We chose that framework years before the rename, which is the plain answer to how long we have worked with this stack: since its previous generation.
Far Rainbow is also the seller of record for Jmix licences in Italy. That matters less for the engineering than for the paperwork: the migration, the licences and an Italian invoice come from one supplier, which for a company with a procurement process is usually the difference between a two-week purchase and a two-month one.
Questions
What people ask before committing
Is this a migration or a rewrite?
A migration. The database, the entities, the business logic and the integrations carry over — in Jmix an entity needs an annotation rather than a framework base class, so most of the model survives untouched. What changes is the layer around them: project structure, the UI, and the security model. Calling it a rewrite would be easier to sell and would not be true.
How long does it take?
The vendor publishes three to twelve months for a typical migration, and that range is wide for a reason: the answer depends on how much of CUBA's machinery your application actually used. An application with two hundred conventional CRUD screens and simple roles is a different job from one with a deep access-group hierarchy and twenty hand-built screens. We will not quote you before an assessment, and you should be careful with anyone who does.
Can we keep running the old system during the migration?
Yes, and normally you should. The CUBA application keeps running and keeps being releasable while the Jmix one is built beside it, usually screen group by screen group. Switching users over in one night is possible for a small system and is rarely the right risk for a large one.
What about our users and their permissions?
User records are preserved. The permissions are the part that needs attention: CUBA roles are classes, Jmix resource roles are interfaces, and CUBA access groups become row-level roles in a flat list with no hierarchy. The vendor's own guide states that access groups and constraints have to be converted by hand. If your access model is the clever part of your system, budget for it as the clever part of the migration.
We are on Jmix 1.x rather than CUBA. Does this apply?
The same reasoning, a smaller job. The vendor puts CUBA Platform and Jmix 1.x in the same position — maintenance only, no new features, no security updates — so the clock is the same even though the distance is shorter.
Why you rather than the platform vendor?
Use the vendor where the vendor is better: they wrote the framework and they sell an assessment. We are useful for a different reason — we have run a CUBA system in production since 2020 and we sell Jmix licences in Italy, so you get the migration, the licence and an Italian contract from one supplier. If after an assessment the honest answer is that you should hire the vendor, we will say so.
Next step
Start with the document, not with the proposal
The useful first conversation is about what your application actually uses, not about what a migration costs on average.
Migration assessment
What converts, what has to be rewritten, which removed features you depend on, and a range with its assumptions. Yours to take anywhere.
ContextWhat Jmix is, and where it does not fit
The platform explained without the brochure: the licensing model, the shape of project it suits, and the shapes it does not.