Research insights

End-of-support dates driving migrations, 2026–2030

The published support dates for SQL Server and Hadoop distributions, and how to plan a warehouse migration backwards from them

Debjani Dhar, Co-founder and CEO

Debjani Dhar

Co-founder and CEO

Novuz Inc. · · 12 min read

Executive summary

Most warehouse migrations are not started by ambition. They are started by a date: the end of support for the database a warehouse runs on, the end of a Hadoop distribution, or a license renewal. Between 2026 and 2030, several of those dates arrive for SQL Server and Hadoop estates. Extended support for SQL Server 2016 ended in July 2026, SQL Server 2017 follows in October 2027 and SQL Server 2019 in January 2030. Most Hadoop distributions are already past their end of support. This note collects the published dates in one place and sets out a planning timeline that works backwards from them.

Key points

  • SQL Server 2016 extended support ended in July 2026; Microsoft lists Extended Security Updates running to July 2029.
  • SQL Server 2017 extended support ends in October 2027, and SQL Server 2019 extended support ends in January 2030. SQL Server 2019 mainstream support ended in February 2025.
  • Cloudera Enterprise 6.3 (CDH) and HDP 3.1 are past end of support; CDP Private Cloud Base 7.1.9 is supported to October 2028.

Recommended actions

  • List every platform your warehouse logic depends on, with its version and its published end-of-support date.
  • Count the logic on each platform early. The date does not move, so the plan must end before it.
  • Treat security updates as time to finish a move, not as a reason to delay starting one.

Why do support dates drive migrations?

Because they turn a deferred decision into a dated one. A warehouse that works can run for years without a business case to move it. An end-of-support date changes that. After it, the vendor stops shipping security fixes, auditors start asking questions, and insurers and regulators may follow.

The date also limits the options. A team that starts counting its logic three months before the date has fewer choices than one that starts eighteen months before. This note collects the published dates so the planning can start early.

Method. Dates come from Microsoft’s and Cloudera’s published lifecycle pages, checked on 11 November 2026. Vendors sometimes change their policies, so check the linked pages before relying on a date.

When does support end for SQL Server?

Microsoft publishes a fixed lifecycle for each SQL Server version: mainstream support, then extended support, then in some cases paid Extended Security Updates (ESUs). Mainstream support includes feature and non-security fixes. Extended support provides security updates only.

VersionMainstream support endedExtended support endsWhat it means
SQL Server 2016EndedJuly 2026 (ended); Microsoft lists ESUs to July 2029Past extended support. Security fixes now need paid ESUs.
SQL Server 2017EndedOctober 2027About eleven months of extended support left from this note’s date.
SQL Server 2019February 2025January 2030In extended support: security fixes only. SQL Server Big Data Clusters were retired in February 2025.

Dates from Microsoft Learn lifecycle pages. Microsoft lists SQL Server 2019’s extended end date as 9 January 2030, 06:59 Pacific Time, so support ends at the end of 8 January 2030 US time.

When does support end for Hadoop distributions?

Most on-premises Hadoop estates run a commercial distribution from Cloudera, which merged with Hortonworks in 2019. Cloudera publishes support dates by version.

Distribution and versionEnd of supportNotes
HDP 3.1 (Hortonworks Data Platform)December 2021Past end of support
Cloudera Enterprise 6.3 (CDH 6.3)March 2022Past end of support; limited support ran to 30 September 2022 for eligible customers
CDP Private Cloud Base 7.1.7August 2025Past end of support
CDP Private Cloud Base 7.1.8August 2024Past end of support
CDP Private Cloud Base 7.1.9October 2028Supported; Cloudera states end of support falls on the last day of the month listed

Dates from Cloudera’s published support lifecycle policy. Estates on CDH 6 or HDP 3 are already unsupported; the Hive and Impala logic on them still has to move.

What do Extended Security Updates buy?

Time, not progress. ESUs keep security fixes coming for a fee after extended support ends. They do not move a single stored procedure, and they do not reduce the logic that has to be converted later.

ESUs are a reasonable bridge for a team that has already counted its estate, chosen its target and started moving domains. They are an expensive way to postpone a decision for a team that has not.

How should a team plan backwards from the date?

Start from the date and work back. The timeline below assumes a mid-size estate of a few thousand objects; larger estates need more time for the later waves.

Months before the dateWhat should be doneWhy
18Count every object on the platform, with dead code and complexity bandsWithout a count, every option is priced on a guess
15Choose the target platform and the migration method, with a fixed priceThe method decides the timeline, and the price decides the budget
12Move and prove the first self-contained domainIt tests the method on your own code before the estate is committed
9 to 3Move the remaining domains in waves, each proven before cutoverDomain by domain keeps each parallel run short
3 to 0Final cutover, then retire the old platformLeave a margin for the domain that surprises you

What else sets a date?

Support dates are not the only trigger. License renewals for platforms such as Teradata and Snowflake give a date and a price, and the useful question is what it would cost to leave, fixed, before you sign. Platform mandates, such as a company decision to standardize on Microsoft Fabric or Databricks, set a date through budget and licensing rather than support. Hardware refreshes do the same for on-premises Hadoop clusters.

Each works like a support date: count the logic first, then decide with two numbers instead of one.

What are the limits of this note?

Dates are as published on 11 November 2026 and can change. Vendors sometimes extend support or change their ESU terms. Always check the vendor’s lifecycle page for your exact version and edition.

The planning timeline is a starting point, not a rule. It depends on the size of the estate, how much of it is dead code, and how quickly domain owners can test.

Sources

  1. Microsoft Learn, SQL Server 2016 lifecycle
  2. Microsoft Learn, SQL Server 2017 lifecycle
  3. Microsoft Learn, SQL Server 2019 lifecycle
  4. Cloudera, Support lifecycle policy

Next step

Start the count. The estate assessment counts every object on the platform, lists the dead code and fixes a migration price in three business days.

Last reviewed:

More questions

More questions buyers ask

When does SQL Server 2017 support end?

Microsoft lists the end of extended support for SQL Server 2017 as October 2027. SQL Server 2016 extended support ended in July 2026, with Extended Security Updates listed to July 2029, and SQL Server 2019 extended support ends in January 2030.

Is CDH or HDP still supported?

No. Cloudera lists HDP 3.1 end of support as December 2021 and Cloudera Enterprise 6.3 as March 2022. CDP Private Cloud Base 7.1.9 is supported to October 2028. Check Cloudera’s lifecycle page for your exact version.

How early should a migration start before an end-of-support date?

About 18 months before for a mid-size estate: count the logic first, choose the target and method by month 15, prove a first domain by month 12, then move the rest in waves with a margin before the date.

Find out what your logic debt is costing you.

Every object counted, lineage, dead code and a fixed price in three business days. $3,000, credited.

Take the logic debt scorecard

Not sure which door? The scorecard takes ten minutes and tells you.

Scorecard