Readiness Checklist

WebSphere End-of-Support: A 12-Point Readiness Checklist

Twelve things to inventory, document, and decide before you commit to a WebSphere or Oracle migration path — written for the team that has to keep the current system running while they figure it out.

1. Inventory every WebSphere version and fix pack actually running in production — not just what's documented in the runbook.

2. Confirm the vendor support end date for each version separately. "Extended support" and "end of service" are different dates with different costs.

3. Catalog every EJB, Struts, and JSP/JSF module that would need a compatible target runtime.

4. Map database driver and JDBC compatibility for whatever application server or platform you're migrating toward.

5. Document custom JVM arguments and non-default WebSphere configuration a new environment would need to replicate to behave the same way.

6. List every scheduled or batch job — cron, JES, Korn shell — that depends on the current server's file system layout or environment variables.

7. Document every integration point: MQ queues, SOAP/REST endpoints, mainframe bridges (e.g. IBM HATS), and how each one authenticates.

8. Confirm whether any code depends on WebSphere-proprietary APIs that don't exist on open-source or alternative application servers.

9. Identify the single points of knowledge — the people who understand undocumented behavior — and get that knowledge captured before they leave.

10. Check whether the underlying OS or hardware is also approaching end-of-life. That can force a harder deadline than the middleware alone.

11. Get a risk-ranked list of what breaks first if the vendor stops issuing security patches on the current version.

12. Decide the sequencing question up front: full replatform vs. phased strangler-pattern migration. The two have very different budgets and timelines.