I have a client that would like to upgrade Ignition 7.7.5. It's running on Windows Server 2012 and uses MySQL 5.6 as the DB. Everything is EOL; or just about.
At a minimum, I would propose a installing a VM client to run separate Ignition 8.1 and MariaDB 11.
Optimally, I would propose new hardware with EsXI, and run Ignition and MariaDB in separate VM's.
Is there other, in-between (or better) options?
Cheers!
I can vouch for separating the DB and Ignition instances as well as MariaDB. It's a drop-in replacement for MySQL and I've had no issues since transitioning myself. I also really love the HeidiSQL db gui it comes with.
What Daniel said, but also note VMs probably should not be deployed on-prem unless there's someone who knows how to care for them. And knows not to overcommit CPU and RAM resources.
(Opinions vary within IA on this topic... I've not had VM issues where the above conditions are true.)
Wouldn't be wise to go from 7.7. to 8.1 in one leap, I would think.
I would do 7.8.latest, 7.9.latest, think you could maybe safely skip 8.0, 8.1.latest
I wouldn't bother with 7.8 or 8.0. If you can guarantee there's no legacy FPMI or FSQL resources, you should be able to go straight to 8.1. Look and feel changes may cause you some headaches for Vision projects 
Thanks for all that.
I'm not sure how to guarantee the (lack of) legacy FPMI or FSQL resources. I assume there part of MySQL?
In any event, lot's of headaches with all this: First, there's no (that I can find) installer for MySQL 5.6. Options were to "hand install" from the available binary archive, of install 5.5 from MSI and upgrade from binary archive. I chose the latter, but an the incompatible my.cnf setting table_cache needed to be change to table_open_cache. Other than that, just copy/replace the binary folder structure seems to have worked.
There was also an issue with the client's mysqldump/schema, where a table index built from a field varbinary(some_large_number) needed to be changed to a more reasonable field(small_number) in the index. Obviously not Ignition related.
The last remaining issue is Java related:
Java exception.txt (3.6 KB)
Seems that no matter how I muck with Java (1.8.361) security settings, can't get the designer or client to load.
I'm not worried about security since this is not a production environment.
Thanks!
Just try the upgrade in your dev environment. If it succeeds, there weren't any. If it fails, you may need to study the wrapper log to see if you can identify the culprits.
No.
It was suggested you use MariaDB. I concur. You should not be installing ancient DBs. Take a full backup of the production server. Restore it into a recent MariaDB installation.
(When MariaDB forked from MySQL, most of the developers went with the MariaDB fork. MariaDB is far more advanced.)
Ignition 8+ comes with its own Java. It doesn't use the system java unless forced to, and java 11 is the minimum version. Mucking with java8's settings does nothing. Your IT department is preventing your system from running the java included with Ignition, it seems.
If this is being run into before the upgrade with 7.7.5, then this KBA should provide you the changes needed. Alternatively, I don't think you need to adjust security settings if you use the Native Client Launcher instead of the Java Web Start (.jnlp) file.
Thanks @pturmel. Unfortunately, I'm locked into MySQL 5.6 until the client is willing to commit to more.
I'm also locked into getting everything working (including java) in my dev env on 7.7.5. I understand the Java headaches will ease as I move forward, but I need to be sure I'm starting from a working env.
Yes, I saw that. Didn't work.
Have you tried the Native Client Launcher?
Yes, client launcher works. However, the issue is with the designer. I forgot to say.
Does the same thing happen if you launch the designer from within the client launcher? There should be a button in the top right of the client launcher.
I forgot about that one, and yes, that does work.
However, on the client/customer's machine/VM, the designer launches (directly) without any issue from the gateway web page link.
On my test VM, it downloads the jnlp file, and then I still can't run/launch it.
I suppose I could just ignore all this, but being the sort that wants everything perfect, I was trying to make it the same as on the client's system.
I get that, I'm the same way. I've personally never run into the settings from that KBA not working to get around the expired certificate. You could share screenshots of the java security settings if you'd like, but reaching out to support is probably your best option to see if they might be able to help get it working.
I've spent way too much time on this already and am out of time. I'll need to opt for the ignore options I guess.