WTL

Solaris 11.3 and Solaris 10 Extended Support Ends in January 2027: What to Do Now

If your organisation still runs business-critical applications on Oracle Solaris, mark January 2027 in your diary. Extended Support for Solaris 11.3 and Solaris 10 is due to end then. That does not mean your servers will stop working overnight. It does mean the safety net beneath them changes and the decisions you make in the next few weeks will shape how comfortable or how expensive the next few years are.

This guide explains what is changing, who is most exposed and a practical sequence of steps you can start this month.

What is actually ending?

Oracle’s support lifecycle has several tiers. For Solaris 11.3 and Solaris 10, Extended Support is scheduled to finish in January 2027. Extended Support is the stage in which customers continue to receive fixes, notably security patches, for older releases.

Two points are easy to confuse, so it is worth separating them:

  • The platform itself is not going away. Oracle has committed to supporting Solaris on SPARC until 2037. Solaris 11.4 is the route that carries that commitment.
  • Specific older releases are reaching the end of their support window. Systems on Solaris 11.3 or Solaris 10 that have not moved to 11.4 will fall outside standard vendor support once the date passes.

In other words, the question for most organisations is not “Is Solaris dead?” It is “Are my systems on a release that will still be supported, and if not, what is my plan?”

Why it matters even if everything is running smoothly

It is tempting to take an “if it ain’t broke” view. Solaris systems have a reputation for fantastic stability and many have run quietly for a decade or more. But the end of support changes the risk profile in four ways.

  1. Security exposure grows over time. Once security patches stop arriving, every newly discovered vulnerability stays open on those systems. The gap between “what is known to attackers” and “what is fixed on your servers” widens every month. For systems that hold regulated or sensitive data, that is a difficult position to defend in an audit.
  2. You may fall out of compliance. Frameworks such as ISO 27001, Cyber Essentials and sector-specific requirements generally expect software to be supported and patched. Running unsupported operating systems can create findings in audits, supplier questionnaires and cyber-insurance reviews.
  3. Operating costs tend to rise. Ageing platforms depend on fewer people, older spare parts and more bespoke workarounds. Each of those carries a premium. The cost of doing nothing is rarely zero. It is just spread out and harder to see.
  4. Hardware and skills are both constrained. Older SPARC servers have physical limits, and the pool of engineers with deep Solaris experience is shrinking as people retire or move on. The longer you wait, the harder it is to find the capacity to plan well.

Who is most exposed?

You are most likely to be affected if one or more of these describes your estate:

  1. Applications that are not certified or tested on Solaris 11.4. If a vendor application, or a bespoke in-house one, was built for 11.3 or earlier and has never been validated on 11.4, upgrading is not a simple patch.
  2. Systems with no documented owner. Servers that “just work” often have no one responsible for lifecycle decisions.
  3. Older SPARC hardware. Even if the OS can be upgraded, the hardware may be at or beyond its comfortable service life.
  4. Environments with limited in-house Solaris skills. If one or two individuals hold all the knowledge, that creates both a continuity and a technical risk.
  5. Regulated or audited organisations. The compliance consequences make this a board-level concern, not just an IT one.

Your three strategic options

There is no single right answer. Most organisations end up choosing one of three broad directions, sometimes applying different ones to different workloads.

Option 1: Stay on Solaris and SPARC for the medium term

If your applications run well on Solaris and the business case for changing them is weak, the sensible path may be to move to Solaris 11.4 and keep the platform. Oracle’s 2037 commitment makes this a credible choice. The work involves checking application compatibility, planning the upgrade carefully and, where necessary, refreshing hardware.

Option 2: Migrate applications away from legacy SPARC servers

Some workloads are better served on modern infrastructure, whether that is Linux on commodity hardware or a virtualised environment. This route can reduce hardware dependency and open up a wider hiring pool, but it demands careful application assessment and testing.

Option 3: Modernise through cloud-based transformation

For organisations looking to move away from owning hardware altogether, cloud is a natural destination. Oracle Cloud Infrastructure is one option to evaluate, particularly for Oracle-centric estates. This is the most transformative route and benefits from a phased plan.

In practice, many estates use a mix: upgrade the systems that are well suited to 11.4, migrate the ones that are not, and retire the ones that no longer justify their cost.

A practical five-step plan

Here is a sequence you can start straight away, even before you have decided on a strategy.

  1. Step 1: Build an honest inventory. List every Solaris system: hostname, OS release, hardware model and age, the application it runs, the business owner and the criticality. Many organisations discover systems they had forgotten about.
  2. Step 2: Identify what is on Solaris 11.3 or Solaris 10. This is your priority list. Anything on a newer release is lower urgency for this particular deadline.
  3. Step 3: Test application compatibility with Solaris 11.4. Talk to application vendors, review documentation and, where possible, test in a non-production environment. Compatibility is the single biggest factor in whether an in-place upgrade is realistic.
  4. Step 4: Assess the risk of each system. Combine criticality, exposure, compatibility and hardware age into a simple score. This lets you sequence work sensibly instead of reacting to whichever system complains loudest.
  5. Step 5: Choose a path per workload and build a phased plan. Resist the urge to treat the whole estate as a single project. A phased, risk-managed plan is almost always cheaper and safer than a single large cutover.

Be realistic about timelines

Upgrades and migrations take longer than people expect. Application testing, change windows, business sign-off, hardware lead times and holiday freezes all play a part. If your systems are on 11.3 or 10 and you have not started planning, the honest message is that you may not complete everything before the date. That is not a reason to panic, but it is a reason to start now and to prioritise.

If you cannot finish every system in time, your plan should answer three questions:

  • Which systems must be addressed first, and why?
  • What compensating controls (network isolation, tighter access, enhanced monitoring) will protect the systems that remain on older releases?
  • Who owns the risk decision, and is it documented?

How WTL can help

WTL is among the UK’s most experienced Oracle SPARC and Solaris specialists. We work with organisations to assess the current state, explore the options and deliver the transformation, whether that means upgrading, migrating or modernising. Our team supports Solaris on SPARC across legacy and modern hardware, in data centres, hybrid environments and SPARC cloud deployments.

If you would like a quick view of your exposure, our short assessment flyer helps you work out whether your systems are affected. If you would like to talk it through with an engineer, we offer a free consultation.

Next step: Check whether your systems are affected or book a free consultation.

Scroll to Top