What changes for you
Your product moves off a language version whose support is ending, onto one its maintainers still support, and it runs on that version in production.
The programming language your product is written in comes in versions. The people who maintain the language look after each version for a limited time. When that time is up, the version gets no more security fixes. Your product goes on running the day after, just as it ran the day before. What has changed is that a flaw found in the language from then on stays unfixed for the version you are on.
Your product may be on such a version today, or close to one. The move is made in steps, and your product keeps shipping while it happens. Your code is brought along to the new version. So are the packages it depends on, each moved to a release that works there. The move is finished when your product runs on the supported version in production, and the old one is no longer in use.
That is the whole of this page: the move, the packages brought along, and your product running on the new version. It is not a rewrite in another language, and it adds no features.
Support end dates are set by each language’s maintainers, and this page quotes none. Our framework end-of-life calendar links the dates for some widely used runtimes and frameworks to the maintainers’ own pages. For any other language, its maintainers’ support page is where the date lives.
If what has aged is the framework your product is built on, rather than the language underneath it, moving off an ageing framework is the page for you. If it is one package nobody maintains any more, see replacing an abandoned library.
What you decide
You decide three things: the version your product moves to, what may wait, and what ships.
You decide the target version. It may be the newest version the maintainers publish, or one a step behind it that they still support. Either is a version its maintainers support at the time you choose; which one suits your product is your call.
You decide what may wait. The move itself is the work on this page. Code your engineers would like to write differently on the new version, or a package they would like to take further than the move needs, can be left for later pieces of work, if you say so.
You decide what ships. Nothing reaches your users without your approval.
What you see along the way
You see the move arrive in your repository as changes your engineers can read and approve.
The work lands in your own code repository. With those changes, the version line your product names goes from the old version to the supported one, the line the drawing above shows. The packages that moved with it appear there too, each at its new release.
When the move is done, your product runs on the supported version in production, and your team can check that for themselves in the code.
What it costs you in time
A first conversation about your product: the version it runs on now, the one you would like it on, and anything you already know stands in the way. After that, some time from an engineer who knows the product well, for the questions that only someone on your team can answer.
What if you want to stop
Every change you approved before stopping stays in your repository. If you stop partway, the changes your engineers approved show how far the move had come and what is still on the old version. The code we build for you is yours. Your code and your product stay yours to take anywhere.
Starting small
We have not moved a customer’s product to a newer version of its language yet, and this page does not suggest otherwise. A sensible first piece is the product whose language version is closest to the end of its support. Every engagement is tailored to your product and your goals. It starts with a conversation, with no obligation.
