IBM’s base support for Db2 11.5 for Linux, UNIX and Windows ends on April 30, 2027. That leaves about six months and one budget cycle. You have three real choices: upgrade in place to Db2 12.1, pay IBM for Extended Support (available to April 30, 2031), or migrate to PostgreSQL and retire the Db2 license. We help teams make that call and carry out whichever one they pick. Below is how we’d think it through.
When exactly does Db2 11.5 support end?
According to IBM’s Db2 Distributed end-of-support table (also on the Db2 11.5 docs EOS page):
| Version | Editions | End of base support | End of Extended Support |
|---|---|---|---|
| Db2 11.5 LUW and Db2 Connect | All editions except Base Edition | April 30, 2027 | April 30, 2031 |
| Db2 11.5 LUW | Db2 Base Edition | September 30, 2025 | Not available |
| Db2 12.1 LUW and Db2 Connect | All editions | TBD | 4 years after base support |
Two details catch people out:
- Extended Support costs extra. IBM says you can extend support past the EOS date “for a fee” by contacting your IBM representative.
- Bundled Db2 is different. If Db2 came bundled as a supporting program inside another IBM product, IBM says Extended Support is not provided; you have to upgrade the product that bundles it. SAP customers should check IBM’s SAP-specific note and their SAP support terms.
Fix packs don’t move the date. IBM states that fix packs fall within the same support lifecycle, so 11.5.9 ends on the same day as 11.5.0.
What are the three options after Db2 11.5 end of support?
Option 1: Upgrade in place to Db2 12.1
This is the least disruptive path for the application. Your SQL PL, tools, backup jobs and Db2 Connect clients stay roughly as they are, and the license relationship with IBM continues. It still needs a real project: test the upgrade on a copy, check client and driver versions, rerun performance baselines, and plan for 12.1’s own security patching. IBM hasn’t published a base end-of-support date for 12.1 yet.
Choose this when the Db2 estate is large, heavily tied to SQL PL or IBM tooling, and the license cost isn’t the problem.
Option 2: Pay for Extended Support
Extended Support buys time to April 30, 2031, not a destination. It makes sense when a migration is already planned but can’t finish by April 2027, or when the application itself is being retired. Get the quote early so you can compare it honestly with the other two options.
Option 3: Migrate Db2 to PostgreSQL
This removes the Db2 license line and lands you on an open-source database you can run self-managed or on a managed service such as Amazon RDS for PostgreSQL or Aurora PostgreSQL. It is the most work up front, and it is the option that benefits most from starting now.
Choose this when the Db2 license is a large recurring cost, the application is still being actively developed, or you want one database platform instead of two.
What breaks in a Db2 to PostgreSQL migration?
Most tables and plain SQL move cleanly. The trouble is in behaviors that look the same but aren’t. AWS’s guide to migrating Db2 LUW to Aurora PostgreSQL or RDS for PostgreSQL documents several we see on real projects:
- Partitioned tables. In PostgreSQL the primary key must include the partition key; Db2 has no such rule. Adding it can let rows through that Db2 would have rejected as duplicates. Db2 range boundaries also use INCLUSIVE/EXCLUSIVE clauses, while PostgreSQL ranges are inclusive at the start and exclusive at the end, and PostgreSQL (as of v15) can’t partition on a generated column.
- Identity columns and sequence caching. Db2 caches sequence values at the server; PostgreSQL caches per session, so values can jump (1, then 21) across connections. Identity sequences also don’t advance on their own after a bulk load, so reset each one to max + 1 before cutover.
- Unique indexes and NULLs. Db2 treats NULLs as equal in a unique index; PostgreSQL treats them as distinct, so duplicates Db2 would block get through. Use
NULLS NOT DISTINCTon PostgreSQL 15 or newer, or partial indexes on older versions. - Materialized query tables. PostgreSQL materialized views support only full, manual refresh, aren’t used by the optimizer for query rewrite, and don’t accept DML. System-maintained MQTs usually become tables kept current by triggers.
- Stored procedures. SQL PL procedures, functions and triggers need conversion to PL/pgSQL and testing against real data. This is usually where most of the effort goes.
On the data side, AWS notes that Db2 EXPORT files quote most fields, so PostgreSQL COPY needs the QUOTE option; that the default exported timestamp format can load as garbage unless you format it in the export query; and that generated columns must be left out of the export files.
Which Db2 to Postgres migration tools should you use?
There isn’t one tool that does everything. A typical toolkit:
- Assessment and schema conversion. AWS Schema Conversion Tool (SCT) produces an assessment report of action items, which is the best way to size the job before you commit. Db2’s own
db2lookreverse-engineers DDL as a starting point. - Bulk data load. Db2
EXPORTto delimited files, then PostgreSQLCOPY(or, on Aurora/RDS, theaws_s3extension to load from S3). Move cold, read-only tables early so the cutover window only carries hot tables. - Ongoing change capture. If you can’t take a long outage, use a replication tool so PostgreSQL keeps up while both systems run. AWS DMS supports Db2 LUW as a source; check its supported versions and platforms against your environment (AIX in particular) before you design around it.
- Validation. Row counts and checksums first, then a row-by-row comparison of the tables that matter.
How do you plan a Db2 to Postgres migration on AWS with low downtime?
The pattern we use for a Db2 to Postgres migration on AWS, or anywhere else, is the same one we describe in migration without downtime:
- Inventory and assess. List databases, schemas, SQL PL objects, Db2 Connect clients and every application connection. Run the SCT assessment.
- Convert and test the schema. Fix the partition, identity, unique-index and MQT gaps above, and convert procedures with tests that compare outputs from both databases.
- Load cold data early. Historical and read-only tables move first.
- Replicate hot data. Start change capture so PostgreSQL stays current.
- Validate continuously. Compare row by row before cutover, not after.
- Cut over with a rollback path. Reset sequences, switch connections, and keep Db2 able to take traffic back until you’re confident.
Starting in November leaves room to do this carefully before April 30, 2027. Starting in March usually means buying Extended Support anyway.
Not sure which option fits your estate? Book a call and we’ll walk through your Db2 footprint and give you a straight recommendation, including when the answer is “just upgrade.”
How is this different from a Db2 for z/OS migration?
This post is about Db2 for Linux, UNIX and Windows. Mainframe Db2 for z/OS brings EBCDIC encoding, packed decimal, COBOL copybooks and different tooling limits. We covered that in moving Db2, IMS and VSAM to PostgreSQL.
FAQ
Does Db2 11.5 end of support apply to every edition?
No. The April 30, 2027 date covers all Db2 11.5 LUW and Db2 Connect editions except Db2 Base Edition, which already reached end of support on September 30, 2025 with no Extended Support available.
Does applying the latest 11.5 fix pack extend support?
No. IBM states that fix packs fall within the same product support lifecycle and don’t change the end-of-support date.
How long can Extended Support last?
For Db2 11.5, to April 30, 2031, for a fee. It isn’t offered when Db2 is bundled inside another IBM product.
Can AWS DMS migrate Db2 to PostgreSQL?
AWS DMS supports Db2 LUW as a source and PostgreSQL as a target. Confirm your exact source version and platform in the DMS documentation; teams on AIX often find they need an extra step or a different replication tool.
How long does a Db2 to PostgreSQL migration take?
It depends mostly on how much SQL PL you have and how much downtime you can accept. The SCT assessment report is the quickest way to get a defensible estimate for your own schema.
Where to go from here
If Db2 11.5 is in your environment, the first step is cheap: list your instances and editions, get an Extended Support quote, and run an assessment of the PostgreSQL path. Then you’re choosing with numbers. Our database migration services cover the assessment, the conversion and the cutover, and we’re happy to talk it through whenever you’re ready.
