Add section describing how OIE is expected to be compatible with Mirt…

[jonbartels]

…h and other forks

[pacmano1]

You need to talk about vmoptions.

[tonygermano]

This section reads more like a general server migration guide than docker fork compatibility. It's asking people to do a lot to switch to our docker container if they are already using the NG one.

I expect most people to be setting mirth.properties values via environment variables. As best as I can tell that hasn't changed and should be compatible. If they are pointing this container to an existing database, then none of the export/imports should be relevant. As always, the software must be pointed to a database at the same version level or lower in order for database migration to work, which automatically excludes Mirth 4.6+ and BridgeLink at this time (as they started at version 4.5.3 and we are still at 4.5.2.)

Relevant to current users of the NextGen containers version 4.5.2 and earlier is how they can use existing docker volumes with the new container, or if that is not supported at this time (I think it should be possible to do and would make upgrades much smoother.)

[leovander]

Containerized instances will use environment variables to set these options.

Is that generally true? It's the tiniest nit in the world, but the docker hub connect hub page/readme has the following:

You can use environment variables to configure the mirth.properties⁠ file or to add custom JVM options.

e.g. shall/should/must.

That is the ideal way, but couldn't a containerized version also read from a mirth.properties file?