The date already passed. On September 30, 2026, base support ended for every FileNet Content Manager 5.5.x release, 5.5.0 through 5.5.12. Estates still running 5.5 are now on Extended Support territory: a paid runway, not a strategy. The uncomfortable part is that the decision waiting at the end of that runway is no longer "which version do we upgrade to?" It has become "which platform are we on in three years?"
Two destinations, not one. The first path is continuity: move to a current FileNet release and keep the architecture you know. It is legitimate, lower risk, and for some estates the right answer. The second path appeared at IBM Think 2026: Content Cortex, positioned as the evolution of FileNet Content Manager, Content Manager OnDemand and Content Manager Enterprise Edition, unified into a single content platform built for AI, with the same capability on premises, in private cloud and in public cloud. For organizations running two or three of those products side by side, the consolidation alone changes the math.
Why this is not "FileNet 6". The difference is not a longer feature list. It is what the content layer is for. In the Cortex model, documents stop being things people retrieve and become things systems can ask about: metadata enrichment and classification happen automatically, content is exposed to AI runtimes through MCP servers, and natural language becomes a first-class way to query a repository. Crucially, governance travels with the content. Access rights follow the document into every AI interaction, and deleting a document deletes the embeddings derived from it. If your organization is building agents anywhere, this is the part that matters: the repository becomes a tool an agent can call, under the same entitlements a human would have.
What the decision actually hinges on. Not the feature comparison. Three questions decide it in practice. First, downstream dependencies: how many custom applications, integrations and event subscriptions sit directly on your current APIs, and who still understands them? Second, the security model: decades-old FileNet estates carry access structures that grew organically, and any move, to a new release or to Cortex, forces you to reconcile them, so the real question is whether you do that work once or twice. Third, the archive: if you also run Content Manager OnDemand, consolidation onto one platform may carry more value than any single feature.
The staged path. We advise treating this the way we treat process migrations: in waves, not in one jump. Stabilize on a supported release so the clock stops ticking. Inventory the dependency map while the people who built it are still available. Then pilot the AI layer on one bounded repository, with real entitlements and real audit requirements, before any decision about the whole estate. A platform choice made after a governed pilot is a decision. Made before one, it is a bet.
Closing the loop. End of support dates are how platform strategy announces itself to the budget. The estates that come out ahead will be the ones that used this deadline to decide where their content layer is going, not just which patch level it sits on. We run this assessment against real FileNet estates, dependency map first.