Develop Reference

OpenJDK for production and LTS?

My understanding from "Do you have to pay to use Java?" of Java programming language Free
is that I can go for OpenJDK(version 11) build provided I don't need LTS as both OpenJDK and commercial version are identical in terms of features. If I need to purchase LTS(Long term support) either I have to purchase support for OpenJDK or upgrade to same version of "commercial Oracle JDK build". Is that correct ?
Another question is why I need LTS ?
I think if we don't take LTS then any we don't get any support/patch for defects( or security patch). Right ?

I wrote a blog article discussing that topic in early 2019.
First, as far as I know, the OpenJDK team does not offer any premium support.
Second, normally one goes to the LTS for longterm support, mainly security updates.
Third, Oracle will only hand over the code for the LTS version to the OpenJDK team and only after the LTS has reached its end of life. This means that the OpenJDK community has to keep up with changes on their own.
Now to the topic on the JDKs being identical. They both pass the JCK and thus can be used as drop-in replacement for each other. The implementations, however, may vary.
There is a host of JDK providers, all with different support plans. Fact of the matter is, there is no free lunch. If one wants support, one has to pay.
A remark on your post: Please limit yourself to one question per post

OpenJDK is a free and open-source implementation of the Java Platform. The implementation is licensed under the GNU General Public License. You are free to use at any environment. But you won't get any kind of support from the Oracle and you've to rely on open communities support, later can be best than the OEM support some times.
LTS is a product life cycle management policy in which a stable release of software is maintained for a longer period of time than the standard edition. You get security updates for some good number of years.
Do you have to pay to use Java?
Answer is yes, Iff you use Oracle JDK for business, commercial, or production purposes.
Answer is No, if you use OpenJDK irrespective purpose or environment.
PS: this is all about licensing and it can change over a period of time.

LTS is supported for 3 years and will receive updates until it expires. When you use openjdk you need not pay for support or patches. I always go with LTS like java 11.
The non-LTS version will have newer features but they are short lived like 6 months. They don’t receive updates for long rather it is expected to upgrade to next version. Security patches are available on same version or next version.
If you don’t have a special usecase then open jdk is more than enough

Is there any valid point upgrading Java 8 to Java 11?

I'm working in a company that has many projects in Java 8. Those projects are valued as old, and our team would like to upgrade the version. However, we need valid points in order to unlock the situation.
Those projects are using Spring and Hibernate (if it's ever useful).
What factual points could we give to our company to upgrade the versions, if any factual points there is ?
Examples of useful, valid points would be:
Security improvements
Performances improvements
New libraries or framework updates which could ease the development process
New possibilites/features with an upgraded Java Version
...
Possibly, backed up with documentation or links to useful resources.

old Java version will eventually stop getting new security fixes, which will make your software more vulnerable
using an old software stack will make it harder to find new developers willing to work on your software. Java 8 probably isn't too old for that yet, but in a few years that will be similar to finding "Java 1.4 developers" right now.
using an old software stack can severely limit your selection of useful third-party libraries and/or tools. A given library that you really need might require a more recent Java version or (possibly even worse) a library that you already use increases it's Java version requirement with a new major release (leaving you stuck with an old Java version and an old software version that might be missing important bug fixes).
There are several advantages from switching to newer Java versions, which are probably not the main reason to switch, but could be considered additional incentives:
newer JDK implementations might have better optimizations (in JIT and Garbage Collection mostly) that might help you get better performance from existing hardware (or reduce your cloud computing costs)
newer Java versions tend to have support for more modern technology, like the newest TLS versions and cryptographic algorithms which can help you data more secure, if you use them correctly.
new language features might improve your code style, which makes your developers happier, which means less churn which saves money on hiring new developers.

The reason to jump from 8 to 11 is the support of Oracle (or other implementation).
You can find the roadmap of Oracle here. For Java8 you are safe up to March 2022 for the premier support and extended support to December 2030. For Amazon Corretto they will provide free support and updates for version 8 to (at least) June 2026.
So the major reason to update your JVM version is support and updates. You still have time to update your version but you also have to wait for you 3rd party library to deliver compatibility with Java 11.
If you wonder why from 8 to 11 and not to 9 or 10, the reason is that 9 and 10 are not marked as LTS (Long Time Support) meaning that the different implementation won't provide any support and updates (or not for long) for those version when the next one is release.

Security updates for Oracle Java 8 are only provided via enterprise licenses and you could save that amount by using newer stable releases.
Apart from that, using newer versions also guarantee better integration with modern JVM tools, like up-to-date build tools.

Is there any OpenJDK that is fully free and will be available for commercial use

I just recently heard about the licensing for Oracle JDK, after trying to create a springboot app for a year. I wanted to find out if there are other alternative JDK which are free for production/commercial use, and if they are what is the certainty that it wouldnt be paid for after or that it would be in the market for long. My only alternative now is to rewrite my code in another language.

Yes, Java is still free
It is vital that you study: Java Is Still Free. Written by key members of the Java community, providing both a summary and all the gory details.
Guidance
The OpenJDK source code is available free-of-cost per its GNU GPL+linking exception license.
Several vendors provide releases based on that OpenJDK source code. They can do so free-of-cost or they can charge a fee or set other licensing terms, as long as they abide by the GNU GPL+linking exception licensing.
The Oracle JDK in latest versions has changed its licensing. It can no longer be used in production without a paid support plan. Contact Oracle for details. The Oracle JDK has converged to be at feature-parity with OpenJDK, with Oracle having contributed to OpenJDK even more of their formerly commercial parts such as Flight Recorder and Mission Control.
Other vendors also provide releases with commercial terms, for a product which may contain some OpenJDK code.
And some vendors such as Adoptium with their Eclipse Temurin product (formerly AdoptOpenJDK), Azul Systems with their Zulu product, and Amazon Web Services with their Corretto product, all provide builds of OpenJDK without payment required.
A release may or may not be labeled “Java”. If a vendor want their release to carry the branding “Java”, they must pass rigorous testing for compliance with the Java specifications and abide by Oracle’s terms for using their trademark.
Here is a flowchart that may help guide you in determining how and where to obtain Java 11. Important: This info may be incorrect. You are responsible for studying the details of the license under which you use any software.
(Note that the diagrams say "Adoptium", which is not a distribution, but instead the organization that produces the distribution called "Eclipse Temurin". See here for more info.)

All Oracle's OpenJDK's are free, in any environment. The issue arises when you use the Oracle JDK (not with the OpenJDK). Since they are functionally the same since Java 11, there is no need to switch languages.
More details here:
https://blog.jetbrains.com/idea/2018/09/using-java-11-in-production-important-things-to-know/

As java releases are coming faster do we need to migrate the old java code base to latest version?

Java releases are coming faster than expected do we need to migrate the code stuff which is old version to newer one to make it more performance based and upto date.

do we need to migrate the old java code base to latest version?
No.
Quite the opposite. You may decide to stick with deploying only the Long Term Support (LTS) (see Wikipedia) versions of Java. The promise: A version that will be actively supported for years with updates for critical bugs/issues but no new features or changes that might break existing deployments. The first such LTS version is scheduled for 2018-09, to be known as either Java 11 or 18.9 LTS (with year and month as release number).
Oracle has announced the changes in release cadences and support policies in late 2017 and again 2018-03. So it may take some more months until we know the exact nature of what releases are supported for how long by whom at what price.
In particular, you may want to avoid ever deploying Java 9 as it has had a brief life, with free-of-cost public updates from Oracle ending this month, 2018-03. By the way, Simon Ritter wrote about 109 New Features in JDK 10.
One of the core ideas behind the new regularly-scheduled “release train” plan is that hundreds of finished features were held up for years waiting on the Java 9 release. In a project as wide and diverse as the Java platform, it makes much more sense to ship whatever features are deemed ready every quarter or semester. If you find such features useful for your future deployments, you may choose to adopt that release. Or you choose to limit yourself to mere experimentation, while waiting for a future LTS version with those features.
more performance based
Future releases may or may not have improvements related to performance. And those improvements may or may not benefit your particular deployments. You will have to make a choice at that time about whether any of the particular improvements are worth migrating any of your particular deployments.
By the way, regarding performance, work is underway to make alternate garbage collector implementations easier to build and deploy. You may wish to keep your eye on developments there.
and upto date
As discussed above, “being up-to-date” is a choice you will have to make release-by-release. Making that choice will be easier as the list of changes to each release will be shorter and therefor easier to understand, digest, and test.
While Oracle and the community are committing to make each release fully qualified as stable and definitely not a “beta” disguised as an official release, change always brings some degree of risk. You may decide to stick with LTS versions to avoid the changes.
Early access
You can still access pre-release versions of Java. At this moment with Java 9 being the official release, Java 10 release candidate is available for trial. And JDK 11 has early access builds available.
Resources
See the official Oracle Java SE Support Roadmap. And be aware that Oracle has announced and confirmed that it is busily working to make their Oracle Java implementation virtually identical to OpenJDK, including contributing some of their add-on tools that are currently commercial products.
Also, you may want to consider alternate sources of implementation and support for Java. For example: Azul Systems with Zing & Zulu, IBM/Eclipse with OpenJ9, RedHat, and so on.

There is no need to do it, but the question is whether the rest of your code base is distributed in e.g. 1.8 compliant.
Having 1.8 is mostly a comfort for developers, keeping old code base is fine. But I've also been revisiting a few old classes dealing with e.g. Process creation and concurrency basic bricks and I'm very happy to have done so.
So do it where you clearly gain for doing it, iff. you think you can expect such recent JRE from your clients. If you already have recent JRE dependency, do some refactoring as code is reused and you revisit old APIs, if some new feature clearly kills your old solution, but not systematically is my advice.
Biggest issue with upping Java version is clients can't run newer versions, otherwise old code runs just fine on newer JRE.

What do I need to know about the different versions of Java from a .NET perspective?

I'm not sure how to phrase this question, but considering the differences in .NET listed below, is there any comparison to Java and all it's deployments?
Platform
The same version of .NET can run on either a server or workstatation
Since the full version of .NET may be too much for some deployments, there is a client profile only version
Silverlight and .NET are not binary-compatible.
There are additional versions of .NET that are meant for other platforms. They are not binary compatible, and may have different API's available: (.NET Micro, Mobile, CE, Embedded, Mono)
Changes between versions
The CLR is version "1.x" in .NET versions 1.0 and 1.1
The CLR is version "2.x" in .NET versions 2, 3.0, and 3.5
.NET 3.0 adds WF and WCF
.NET 3.5 is mostly a feature pack on top of the .NET 2.0 "base"
A .NET 2.0 application will run if only .NET 3.x is installed, but what may appear as a version mismatch doesn't apply to any other assembly/.NET build combination
Given all the different versions of Java SE EE and all the acronyms, I'm sure there may be more under the hood I need to learn besides the spelling difference between each implementation.
Can you tell me what I need to know regarding the various versions that exist and when is one more appropriate than the other.
http://www.oracle.com/technetwork/java/index.html

Until now if a program ran under any release of Java SE - Java 1.1, Java 1.2, Java 1.3, Java 1.4, Java 5, Java 6 - it runs under any later release too (except for unintentional bugs, but these has been very few).
Sun has given this extreme attention, and it has meant that upgrading has been a non-issue. You just do it. With the advances achieved in the JVM this has also been highly desirable.
Hence, unless you have very good reason not to, your users should use Java 6. The Sun Java 6 gives very good performance but at the cost of memory to do so.
I have only worked with the "web application" part of Java EE, but here the Servlet API has been very stable and well supported. A given WAR file can be deployed on any web container, plus some configuration glue. This includes web containers much newer than the specification the web application was written against.

I think all you need to know is that Java JDK 6 is the only one that's currently supported by Oracle. The other earlier versions have all passed their useful support life.
There's no good reason on earth for anybody to be running a JDK or JRE version 1.4 or earlier. It doesn't even have generics, and it's missing a number of important improvements to the memory model.
JDK 5 is defensible, but I believe it's already reached the end of its support life as well.