Leaving JAR files unmodified if they don't reference any EE class sounds like the best solution to me. This will probably require buffering the files in memory.

I think users should probably use scripting to exclude problem JARs from the migration.

Trying to do too much would lead to more problems, here a likely excessive memory use [there is the same problem with SB which wants some uncompressed JARs, also not doable without full load in memory]. This tool is IMO better if it stays simple.

How about adding a command line option to exclude certain JAR files from getting migrated? It adds just a little bit of complexity in how to use the tool, but it has no impact on memory usage. And it is maybe useful in other scenarios as well.

Yes, a resource filtering pattern or some kind could be a good add with plenty of uses.
Still copy out and in should work and would likely be easier for you to do with your JCE JAR.

Trying to do too much would lead to more problems, here a likely excessive memory use.

What is an excessive memory usage? A typical jar easily fits in the heap allocated by default to the JVM. This tool is mainly used at build time on beefy machines, I don't think the memory usage is really a concern.

How about adding a command line option to exclude certain JAR files from getting migrated?

Good idea, something like an --exclude option with a glob parameter that could be repeated many times.

Also bcprov*.jar could be excluded by default.