Hi @albertosanchez,
I’m glad my previous reply was helpful. It’s also great to hear that the file import add-on was useful to you in the past. Just as a quick note: Jmix now includes a built-in data import solution as part of its standard Haulmont add-ons (jmix/jmix-dataimport at master · jmix-framework/jmix · GitHub) - although it is still marked as incubating. It’s a more robust implementation, and that’s why I decided to not migrating my custom add-on – the framework now offers something better by default.
Coming back to your reflections: I’ve also faced similar situations in my work over the years, and I’ve noticed a few recurring themes that might resonate with what you’re describing. It is partly about CUBA / Jmix, but also about framework usage in general. Once again, I’m not privy to the inside baseball of Haulmont, so I’m just writing down what I observed.
The Framework as a dependency
When we choose a framework or library, we are, quite literally, accepting a dependency - we depend on it. And while this is perfectly natural, it also comes with trade-offs. The more a framework does for us, the more we rely on it. And let’s be honest here: CUBA / Jmix does a lot.
But at the same time, it allows us to move faster, because we don’t need to reinvent the wheel for things like user management or report generation. Frameworks like CUBA and Jmix, in particular, are designed to offer as much out-of-the-box functionality as possible, so they naturally create a tighter coupling between our applications and the framework itself.
In CUBA I also saw that this dependency often extends beyond just code. It can also influence how our end users perceive the software. For example, if we expose pre-built UI screens from the framework – things like standard user management screens or report editors – these become part of the user experience. When the framework changes or evolves, and those screens are no longer available or work differently, it’s not just a technical challenge for developers. It’s also a challenge to manage expectations from users and stakeholders, who are accustomed to the old behavior. But on the other side providing those management UIs (or end-to-end functionality shipped as an add-on) are also a key differentiator compared to the majority of other frameworks. Normally the frameworks stop at some technical layer, but not really touch the workflow end-to-end. This is a huge time-saver, but as a downside it reveals a dependency from a technical decision to the end-user of the software.
I think this is where migrations become particularly tricky. It’s not just about updating code; it’s about maintaining continuity for the people who use the software every day. And if key features are missing or delayed in the new version, it can lead to difficult decisions: Do we stick with the old version longer, knowing that it will eventually be unsupported? Or do we move forward and deal with the pain of re-implementing features ourselves? But sometimes we practically can’t, leaving us almost no real space to act. And since the exposure to the end-user is done via the user interface, it’s not something that we as app devs can easily hide through a layer of indirection. All of a sudden out of a technical problem it becomes an end-user problem.
The CUBA / Jmix Migration Path
One of the key points about Jmix 1.0 is that it was still tied to Vaadin 8. At first glance, this might seem like a limitation or a missed opportunity to adopt newer technologies. But from what I understood / interpreted, this was actually a very deliberate and thoughtful decision by the Haulmont folks, made with the best interests of developers in mind.
When Jmix 1.0 was released, Vaadin 14 was already available for quite some time. However, moving directly to Vaadin 14 would have significantly increased the effort required for application developers migrating from CUBA to Jmix. It’s not just about adopting new UI components – the changes in Vaadin 14 were so fundamental that most applications would have needed a complete rewrite of the UI layer.
Even more importantly, Haulmont evaluated Vaadin 10 / 14 at the time and decided it was not yet mature enough for production use (see Vaadin Flow – a marvelous deer – Jmix and more importantly Vaadin 10+ as the Future of CUBA UI – Jmix) . It seemed that the priority was ensuring stability and minimizing disruption for developers, so Jmix 1.0 started with Vaadin 8 for two more years (from 1.0 to 2.0 release of Jmix). This wasn’t about delaying innovation but I think about 1. prioritization and 2. about protecting developers from potential pitfalls and giving them a smoother migration path.
If you look at it from this lens, I think Jmix 1.0 was a quite good example of a risk mitigation strategy. The changes introduced were substantial, but they were also carefully staged. Instead of overwhelming developers with a “big bang” transition from CUBA to Jmix 2.0, which would have combined all the backend changes with a completely new UI framework, Haulmont split the transition into manageable steps.
As a result, developers now have options. You can decide to make a single big leap from CUBA to Jmix 2.0 and tackle everything at once, or you can take a phased approach: first migrate to Jmix 1.x, keeping the UI layer largely unchanged, and then update to Jmix 2.x when you’re ready to adopt the new Vaadin version.
The whole question of why a 2.x shortly after a 1.0 (well - actually it was two years after) and in particular why it forces to switch to Vaadin 24 is not a result of Jmix isolated decision, but a force from the underlying libraries (Spring & JPA javax → jakarta namespace change as well as Vaadins migration to Spring Boot 3 and in particular Vaadin 8 end-of-life in 2022). I discussed about that in another thread: Jmix 2.x upgrade - a practical guide for rent-your-stuff example - #7 by mario.
The wider migration landscape
If we zoom out and compare this migration to other frameworks, I think Jmix and CUBA have handled it relatively well. Over the years, I’ve been involved in several framework upgrades, like moving from Spring Boot 1 to Spring Boot 2, or transitioning from Backbone.js to React. A classic well known example I not personally experienced in production, but heard a lot of interesting horror stories is clearly Python 2 to Python 3. In the JVM world, I experienced one thing in particular, which was super painful (and thus in fact we never finished) was from Grails 2 to Grails 3.
Many ecosystems and frameworks handle upgrades much worse than what we’ve seen with CUBA and Jmix. I saw Haulmont has put a lot of effort into making the migration as smooth as possible. Tools like the CUBA Studio migration wizard helped automate parts of the process, and while it’s impossible to cover everything due to the framework’s wide surface area, they still did a pretty good job.
But let’s be clear here: It is also not fair to compare it 1:1 to purely open source alternatives. With the much wider surface area, the paid subscription model and the focus on long running enterprise applications, the stakes & expectations are much higher. It can and was expected from Haulmont to have a better migration story than a random open source framework.
What I think was misleading is that somehow people got the impression (not talking about you, but comments from the forum in general) that there will be tool that will do a migration and then afterwards they only have to click the play button in IDEA and everything will work again. I personally wasn’t really expecting that and I even was kinda positively surprised about what was there - as in other migrations I didn’t even see any kind of tooling from the framework vendors.
But I do think there was miscommunication and / or not aligned expectations for sure.
All that being said, at least for me using a framework isn’t just an asset that speeds you up 2x, 5 or 10x - or sometimes also slows you down 
). It’s 50% asset and at least 50% liability. The speed gains and development benefits are clear, but they come at a price, and we as developers need to account for that. Often, business stakeholders focus only on the advantages and forget about the technical debt and maintenance effort required. At least for myself I see that as a part of my role as a technical person to remind them that using frameworks increases dependencies, which in turn makes regular upgrades and maintenance essential.
Lets look into the future
If we take a look forward and consider the dependencies we currently have up-to-date, the foundation now looks very stable. Spring Boot, as the underlying technology, is on a highly current and mature base, and I don’t expect any fundamental changes in the near future. There will be a new major Spring Framework version (Spring 7) in November 2025, and likely a corresponding Spring Boot 4.0 release around the same time. These updates will raise the baselines, probably requiring Java 17 or later, and while there will undoubtedly be some changes, Spring is a very mature framework. I wouldn’t anticipate any groundbreaking shifts.
Vaadin, on the other hand, has seen much more fluctuation over the years, especially in versions 10 through 20. During this period, they made significant changes, particularly between versions 10 and 14, but also beyond 14. It was evident that they were still searching for a consistent approach to their core technologies. They transitioned from Polymer 2 to Polymer 3, introduced LitElement, adopted TypeScript, and later added React support. This frequent switching made it challenging to predict their long-term direction.
However, things have stabilized in recent versions like 23 and 24 (and this is exactly the point when Jmix adopted it BTW). While they’ve recently added React support, the underlying framework has felt more consistent, and the overall platform appears much more stable than it did during those earlier years of experimentation. In particular now since 2-3 years they also seem to have come to more / less feature parity with their previous flag-ship product: Vaadin 8.
Because of this stability in the underlying stack, I don’t foresee any dramatic changes on the Jmix side in the next 1–2 years (beyond that anything would be guess-work anyways). Of course, there will be ongoing updates to keep the platform modern, but they’re likely to be evolutionary rather than revolutionary. Unlike the big transitions from CUBA to Jmix 1 or from Jmix 1.x to Jmix 2, I would expect the upcoming years should focus more on incremental updates and stable feature enhancements.
From what I see, the current frameworks provide a solid and modern foundation, and I expect them to continue evolving in a way that supports long-term stability for Jmix applications.
I hope this helps putting the things a little bit more into perspective.
Have a nice day!
Mario