I don’t think I have seen anything about it, but I could be wrong. Let me explain.
On the good old days of the Native installation before the era of Tutor installation, when you needed to move from one version like Hawthorn to another version like Koa, you needed to install Ironwood, Juniper and then Koa to make sure the Django migrations were run correctly in order to keep the integrity of your data between releases.
What about Tutor?
My business case is the following. I am currently running a Native installation with Koa. I need to move to Maple or Nutmeg when it will become available. I need to carry my current data with me while I upgrade from one release to the other.
How do I specify which open-release version to install with Tutor? I assume I will have to first install either a Koa or Lilac release of Tutor and then move on to upgrade to Maple and then Nutmeg in order for the Django migrations to run correctly, right?
You need to understand the versioning scheme of Tutor: Tutor development — Tutor documentation
Basically, to run Lilac, you need tutor v12. To run Koa, v11, etc. The latest tutor release can always upgrade from any older release at any point in the past. That means that you can upgrade from Koa to Maple in one-go. That’s a daring feat though so it’s usually recommended to upgrade from v11 to v12, then to v13, etc.
In you case, you need to first migrate from the Koa native installation to Tutor v11. Then you can consider migrating to v12 or v13.
There are few people who have faced a similar question before:
I had seen part of it but didn’t understand the versioning scheme of Tutor.
I have installed Koa but I ran into a lot of issues with regards to recovering MySQL and MongoDB thus far.
Let’s remember that my data starts from way back then in Aspen. There are MySQL tables that survived in my instance that didn’t make it to Koa in Tutor. There are even fields I had to edit in my MySQL dump because notify_subscription used “subscription_id” in Tutor and I still had “id” in Native. And with the size of my MySQL dump it was an adventure just finding an editor to open the file and allow me to make the modifications so that it could restore correctly. Of course, there are tables I didn’t have because I dropped the old shopping cart years ago when it was replaced by ecommerce.
I am taking notes and I will document everything after a few tests and a successful migration without a glitch.
Right now I was able to recover MySQL. Unfortunately, Mongo broke something and I no longer have access to the main page. Looks like an nginx error because I see our error page, but I still need to investigate what is causing it. I may need to make some modifications since the nginx logs seem to go to /dev/stdout and /dev/stderr in the nginx container. That was a MySQL error in the end. My restore also restored the password for edxapp001 from my Native installation. All is good!
so it’s usually recommended to upgrade from v11 to v12, then to v13, etc.