This guide demonstrates how to upgrade all components of the ORIGAM platform, namely the Server and Architect.
[!success]- Prerequisites for proceeding
To follow along, you must meet the following prerequisites:
The ORIGAM platform is still under development, with new features continuously being added and bugs being fixed. The release cycle for new versions is monthly, meaning that 12 new versions with either minor or major changes are released every year, in addition to often having sub-versions—patches for each release.
The reasons you need to upgrade are:
- If a new functionality is released that you are interested in and need
- When there is a fix for a critical bug
- Once a year, if not otherwise needed
Continuous upgrade
We recommend upgrading the platform continuously, even when there isn’t a specific need, such as acquiring a new feature. While the platform will still function without continuous upgrades, upgrading after skipping several versions can become more difficult and time-consuming, requiring additional effort for implementation and testing.
Each new version introduces various changes, all of which are detailed in the release notes. For example, you can find release notes for the current version here. Pay particular attention to any breaking changes and metamodel updates, as these affect backward compatibility.
If you’re upgrading across multiple versions, we recommend reading the release notes for each version between your starting version and the new version. This will give you a comprehensive understanding of all the changes that will be implemented with the new release.
Single platform version
It is crucial to understand that each project is tied to a specific version of the platform, which includes a particular version of the ORIGAM Server, Architect, and application metamodel. If you wish to upgrade to a newer version, you must upgrade the entire platform to ensure the versions of the Server, Architect, and metamodel are consistent.
On the Github ORIGAM release page, for example, you may see the following:
These versions of Server and Architect work with a specific version of the metamodel and the version of your application model should match that. More about versioning of your model you can find in this article.
Now, let’s examine the upgrade process for each component in detail.
Architect upgrade
The Architect desktop application isn’t upgraded in place; instead, you install and run a new version alongside the current version, and potentially all previous versions that you have installed.
Therefore, upgrading Architect follows the same process as installing it from scratch, as described in this article.
If you’re using MS Windows, you will typically find all Architect versions under C:\Program Files (x86)\ORIGAM:
The Architect folder name is set when it is first installed, so it may be different on your system.
Having different versions of Architect installed separately allows you to run all of them independently and keep every project in a particular version of the platform.
To avoid confusion between versions, remember managing your Architect shortcuts or taskbar icons properly.
Server upgrade
To upgrade your ORIGAM Server, you need to download a new image and create a new container from it in Docker. This enables you to run different Server versions in separate containers and be able to switch among them. More details are in this article.
The procedure is the following:
1, Download a new Server image
2, Delete the container with the Server you want to upgrade (or just stop it if you want to keep it)
3, Run Docker deployment script to create a new container from the new image
There is also a couple of useful things you need to know.
When a new project is created, the Docker .cmd file defaults to the origam/server:master-latest.linux image, meaning the latest published Server image is used. If you wish to target a specific Server version, you can change it to something like origam/server:2025.3.1.3760.linux for example.
If you just want to upgrade the master-latest image, you can pull the update directly using the image actions (icon with three dots):
Metamodel upgrade
The metamodel, often referred to simply as the “model,” contains the content definitions for all XML files that define a project or application.
Just like the Server and Architect, the default metamodel evolves over time—new items are added, and existing items may be renamed. To work with a particular version of the metamodel, you need a corresponding version of Architect and the Server to ensure proper functionality.
If you open your application’s model in a newer version of Architect, it will upgrade the model automatically. However, if you try to load the model in an older version of Architect, it will be rejected. If no changes have occurred in the metamodel between two specific Architect versions, this will not be an issue.
Project upgrade
To open projects created in older versions of Architect in a new version after upgrading, you need to copy the OrigamSettings.config file from the old Architect folder to the new one.
For example, if you upgraded from version 2025.1 to 2025.3 and you are using MS Windows, copy the file OrigamSettings.config from:
C:\Users\victo\AppData\Roaming\ORIGAM\2025.1
to
C:\Users\victo\AppData\Roaming\ORIGAM\2025.3.
The path of the file you can always find in the Connection Configuration screen located in the main menu under File in Architect:
After upgrading the platform, remember to test all relevant and important functions in your application. While upgrades generally do not cause issues, it is advisable to verify at least the critical functions or processes, especially if your upgrade spans multiple versions or if any of the changes in the new version are directly related to your project.
Version comparison
That being said, we recommend upgrading on an ongoing basis. However, if for some reason it is necessary to upgrade across multiple versions, it is possible to use Github’s version comparison to easily get a list of all the changes that have been implemented between the original and the new (target) version.
In Github, just use the Compare button on the target version and select the version to be upgraded to compare:
Here is an example of the output we get when comparing version 2025.3 with the older version 2024.5:
Here you will see very detailed information about all changes made to the code. If you want more summarized information, you need to look at the release notes of each version.