Skip to Main Content
Need Support? Let’s guide you to the right answer or agent.
Status Future consideration
Created by Guest
Created on Apr 23, 2026

import former project in new version

Nowadays, who dares to make a new version not compatible with previous? nobody.

But Itwin, yes! It could be a converter or whatever but its mandatory. Otherwise, you need to maintain in parallel 2 versions? I have a good example: we have a project of 8000 Gpixel that was in processing on former version and processed at 15%. This means i must restart from scratch with new version that allows to process on more that 2 computers. It is ridiculous. If you do that, customers will use other solution like context capture or Metashape. It is a critical mistake to me!

  • Guest
    Jun 19, 2026

    We can understand the strategy of unifiying your products, what is still unconceivable is the lack of bridges allowing to import old version to new one. Honestly, restarting from scratch a project when you have about 3-4 month of computation, it is unacceptable. As the former version was only allowing network computation on 2 computers, it shows that product is not mature. Recentely, we faced huge problem on a project of 49'000 images of 100Mpix. We have terminated the job in metashape. Regards

  • Admin
    Liv Lotteau
    Jun 19, 2026

    Hello,

    Thank you for you comment and the feature request. Let me add a bit of context to try to give some clarity on choices that were made and that is possibly making no sense to you at the moment.

    I understand your frustration. It is completely fair to say that, from your perspective this critical feature missing is a total nonsense.

    To give you some context, we have a highly diverse user base—ranging from advanced users to various first and third party integrators. Historically, our portfolio grew to include multiple editions and underlying engines, which became increasingly complex to develop, maintain, and explain.

    To ensure the long-term viability and performance of our solutions, we made the strategic decision over the last two years to focus heavily on the backend: unifying our APIs, consolidating our architecture across cloud and on-premise, and rationalizing our portfolio from six products down to two. While this foundational work meant fewer visible updates on the desktop client in the short term, it was an absolute necessity. It has provided us with the clean, documented APIs required for modern integrations (including Agentic AI) and sets us up to develop, fix, and maintain our solutions much faster moving forward. But also means that the project compatibility will be completely broken.

    Regarding the launch of our Flex offering, we knew from the start that it might not immediately cover every advanced workflow for our most hardcore users and project migration would be an issue as well. This is exactly why we designed the transition to allow users to keep utilizing legacy products while still benefiting from the new subscription and pricing models. We decided it was better to get the new, unified architecture into the hands of users now rather than delaying for another two years to reach full feature parity.

    We are actively migrating more users to Flex and are taking an iterative approach to closing the remaining gaps.


    Thanks for your understanding.

    Liv

  • Guest
    May 4, 2026

    Totally agree, It does not make sense to any users, but they did it...

  • Guest
    Apr 27, 2026

    Flex is irrelevant for next couple of years until old projects are archived. There is even need to downgrade to even older ITCM so to get back lasso selection in retouch.