Any further thoughts here? 
We’ll certainly think about simplifying migration, but a bit later. First we need to launch 2.0 and important add-ons with Flow UI.
2 Likes
@krivopustov - Any word here? It’s been a year. We are still on 1.5 because our application is huge (I’m sure you’ve seen it) and the process of 1.5 → 2.0 is basically “start over.”
I’d recommend watching this guide:
@krivopustov - It is a good guide series, but guys, really, you can do better.
CUBA 6 to 7 must have been a nightmare for people. (Back in the CUBA days many stayed on 6…there must have been a reason).
CUBA → Jmix was a nightmare. That ended up costing us thousands of dollars and about a year of time. (we paid you to migrate for us in the end.).
Then very soon after, there was Jmix 1 → 2. Another nightmare.
There is a pattern here. 
You can do better! I know it’s a lot of work, but the “bootstrap” migrator we discussed over a year ago is something you could produce. Just something to automate the steps outlined by Mario plus a copying of screens and such, and adjusting what can be adjusted.
For example if you know that something was named “X” in 1.x and it’s now named “Y” that’s just a search and replace operation. There are many things like this that you could automate.
Jmix’s strength is that it allows small teams (like mine) to do truly, truly amazing things. But that’s also a weakness. Because such small teams (i.e., a team of one in many cases) can do such amazing things… we WILL do those things with tiny teams. But then when something like the 1 → 2 path comes along, that small team has a gigantic workload because - and here’s the truth - the migrations are far more difficult and labor-intensive than the actual application development! However, some or even “much” of that work is “grunt work” which could be (semi) easily automated.
(If you guys still have a copy of our application from when we contracted you to migrate CUBA → Jmix… Give a try at migrating it to Jmix 2.x. Perhaps that will give you perspective on it.)
I won’t even say that I agree very much with @modemmisuser . 
@krivopustov , on the other side of the Earth, man talks about the same thing that we talked about with you and with @v.fadeev :
- maybe you are planning to deploy the product towards only large teams with a large Java/Spring Boot expertise?
- migration is documented with gaps and it is more difficult than ever
- the documentation has become less clear and more “sketchy”
- Jmix entry has become higher than Cuba entry
- …
We were migrating Cuba 6 - > Cuba 7 and here I disagree with Jon.
It was easy.
Then I was ready that it would take us 1 month, but it took us 2-3 days and the application was already working on the new platform.
Then we smoothly changed the code to use the new API and did it in parallel with the planned development of the application.
Therefore, you can definitely make migration less painful. I know: -)
Now we are completing the migration of Cuba 7 - > Jmix 1.5 and it took us almost 5 months when we were engaged in Migration only and forgot about feature development.
About half of the time was spent on what is simply not described in the migration documentation.
I will try not to think about Jmix 1.5 migration - > Jmix 2.0 for another two years: -)
If for many the migration of Cuba 6 - > Cuba 7 turned out to be difficult, then the migration to Jmix for them will cost no less (or even more) than to develop applications anew.
In this case, will they develop it on Jmix or change the platform?
A huge plus of Cuba/Jmix is that a working application solution can be made quickly by a small team without Java/Spring expertise. And the team will focus on Applied Tasks.
But the saved time and money they will be “eaten” as soon as you need to migrate to the new version.
For many micro-commands, this will negate the merits of Jmix.
Pretty sure small teams don’t make you a lot of money. But there are many such teams.
They create the popularity of the product and help make it even more universal.
1 Like
Absolutely. The migration would be effortless if we wouldn’t update the underlying technologies (as was the case in CUBA 6 → 7 update).
But you would end up with unsupported stack, security vulnerabilities and outdated approaches.