Tuning production system is an iterative process. Instead of testing multiple application versions here and comparing them to each other, you are changing WebSphere configuration parameters themselves and optimize them to suit your runtime environment.
You should use the final application code to perform tuning in the production environment. This version should have passed performance tests on the integration environment prior to changing any WebSphere parameters on the production system.
When changing a production environment, you should use regular system administration practices...
These test runs should not differ by more than a small percentage or you have some other problem with your environment that sort out before you continue tuning.
As soon as you have finished tuning your production systems, you should apply the settings, where it makes sense, to your other test environments to make sure they are similar to production. You should also re-run your tests there to establish new baselines on these systems and to see how these changes affect the performance.
Please keep in mind that usually you only have one chance on getting this right. Normally, as soon as you are in production with your system, you can no longer run performance tests on this environment because you cannot take the production system offline to run more performance tests. If a production system is being tested, it is likely that the system is running in a severely degraded position, and you have already lost half the battle.
Because it is rare to use a production system for load tests, it is usually a bad idea to migrate these environments to new WebSphere versions without doing a proper test on an equivalent test system or new hardware.
After completing your first performance tests on your production systems and tuning the WebSphere parameters, you should evaluate your results and compare them to your objectives to see how all of this worked out.