Have you heard of the latest Axon Ivy Engine 10 features?
Here's how you can migrate your existing productive or staging Engines to LTS 10.
First of all, the migration of an Engine to another version has been simplified and automated 🌪️ .
So, if you are an experienced migration sage 👴 , there are things to 'unlearn' as they are simply no longer required.
A good starting point for your Engine migration are our Migration Docs 📚️ .
We have completely rewritten these docs. With the aim to offer specific answers for your concrete migration scenario. Therefore you have to pick your starting point:
- Migration Path: Major Upgrade (8 > 10) versus Hotfix Upgrade (10.0.1 > 10.0.3)
- Operating System: Linux, Windows, Docker ...
Major Upgrade to 10
You start your migration to LTS 10 the best, if you drop an eye on our migration notes. We document changes done between major versions in our Migration Notes 📋️ .
Note that changes are enriched with Badges. These badges should help you to identify, whether a change entry is relevant for you or not. If you are an Engine operator, just look for the changes prefixed with
In many cases the changes do not affect you. At any rate, you can quickly skip badges with green background. These changes are automatically applied and you shouldn't really have to think about it.
To start your migration, just download and start the Engine 10, that matches your environment.
Boot it on the same host where you have the older version installed, without any further changes in advance.
The Engine will be started in
Demo as it is fresh and unconfigured.
- Click on the
Setup-Wizard notification, to start configuring.
- Pick the 'Migrate' Option to start the Migration Wizard
Now the Migration Wizard opens. This is your key tool to apply necessary migration steps.
- Pass the File location, where the old Engine lives, to the Migration Wizard.
- Stop ⏸️ your old Engine, so that the Migrations steps, can operate safely with the Database and Files.
- Run the migration
- The Wizard will ask for your choice, if a change can optionally done or needs human confirmation. 🧑💻
Finally you can reboot the Engine. And everything should work as before.
On the first boot, all your running workflow projects will be updated automatically to the latest version.
Note however, that many of your projects will need to be migrated anyway by a Developer 🤓 , e.g. as internal APIs have changed that were used in the project.
This auto migration of LTS 8 projects to 10 is auto applied also if you are deploying older projects.
Once you are on LTS 10, you may ask how to keep your Engine up 2 date 🗓️ . We are shipping hotfixes on a regular basis, so you should be aware of this update procedure too.
In general, these updates are much simpler as we do not apply breaking changes. But roll out fixes and address stability issues.
Still, the process depends on your Operating System. And on some systems you have more comfort than on others.
So make a wise choice here. Today you should opt for a Docker or Debian Linux system, to make the Hotfix update simple. 🪟 ⚠️
Even so, the Migration Wizard makes hotfix upgrades simple and lets classical system catch up with highly automated approaches.
If you are maintaining many Engine instances, you may still are not yet totally happy with the Migration Wizard. As you have to click through UIs for each Engine Migration.
We have a CLI to the rescue, that allows you to run Engine migrations. With this tool, you may automate your Migration steps.
Besides Engine migration, you can also migrate projects with this CLI. This can be very handy if you have to migrate many projects form 8 to 10. Maybe living in several distinct repositories. This CLI and your simple custom script, can apply these migrations in seconds.
As stated in the introduction, there are things you needed to do up to version 8, which are no longer necessary.
do not copy files manually from one Engine to another: this is done by the Migration Wizard, doing this manually is prone to errors. E.g. because there are multiple locations where crucial config files reside.
do not migrate only the database (e.g. via CLI), today we also migrate files and their contents : running just the database conversion is not enough and will lead the corrupt configuration states. Unless you carefully scan our migration notes and apply all the documented changes manually.