OpenText announced Content Management 26.2 in June 2026. For organisations running Content Server on 24.x or earlier, the practical question is how to move without putting a business-critical platform at risk.
Before we advise anyone on that, we wanted to do it ourselves. In October 2026 we upgraded Nuca’s own development environment from Content Server 24.3 to 26.2. This was our lab, not a client system. Here is what we found, and the checklist we would now use on any estate.
This is the first-hand companion to our page on planning a Content Management 26.2 upgrade as a production change.
Why we upgraded our own lab first
Nuca combines OpenText platform administration, business administration and database administration under one coordinated support model. An upgrade is where those three disciplines meet most sharply, so it is the best place to test whether our own process holds up.
Running it on our own environment let us follow the full path: planning, backup, the upgrade itself and the open items afterwards.
One caution before the detail. Our lab is small and simple. Real estates have larger databases, more customisation and more integrations. Nothing below predicts how your upgrade will behave, and we are deliberately not quoting timings. The lessons are about where the risks sit, not how long things take.
What changed
We used OpenText System Center to carry out an in-place update, which is OpenText’s normal method when the underlying infrastructure is not changing.
- Content Server: 24.3 to 26.2
- OpenText Directory Services (OTDS): 24.4 to 26.2, upgraded before Content Server so that it was at least at the Content Server version
- Database: Oracle 19c, with the Content Server database upgrade completing without errors
At the end, Content Server 26.2 and OTDS 26.2 were running. Two items remained open: a licence for 26.x, and moving Module Suite to version 4.0. Both are lessons in themselves.
Lesson 1: the database upgrade is one way, so prove you can roll back
Most of a System Center update feels like a normal software update. The tool downloads the new release, analyses what will change, and deploys it. One step is different.
Once the new binaries are in place, Content Server prompts you to upgrade its database to the new format. After that has run, the previous version cannot use the database. Our notes record this step as irreversible without a database restore.
That changes what “rollback” means. In our run, rollback meant restoring the database and the application together, from a point taken before we started. Check the System Center documentation for your version before relying on any application-only rollback.
Before we touched anything, we prepared exactly that:
- a saved image of the application as it stood before the upgrade
- a verified backup that included a cold copy of the database, taken with the database cleanly shut down
- a logical export of the database as a second route back
- written restore steps, so that rolling back was a procedure rather than an improvisation
We did not need it, but we knew we could use it. Treat the database upgrade as your point of no return, and do not reach it until your restore plan has been written down and your backup checked.
Lesson 2: check your licence before and after the upgrade
The upgrade itself completed, but a licence for 26.x was still an open item afterwards. In a development environment that is an inconvenience. On a production platform that people rely on every day, it is not something you want to discover after the change window has closed.
Our advice is simple: check your licence before and after the upgrade. Confirm with your licensing contact what you need for the target version before the window is booked, and check again once the upgrade is complete. Do the same for any add-ons that carry their own licence keys.
Lesson 3: add-ons such as Module Suite need their own upgrade
Many Content Server estates run Module Suite, the AnswerModules product used for forms, scripts and user interface extensions. Our lab ran Module Suite 3.7.
AnswerModules makes this easy to plan: it publishes a clear compatibility matrix in its Module Suite 4.0.0 release notes, and it is the first thing to read. Module Suite 3.7 is supported up to Content Server 24.3, and Module Suite 4.0 is the release for Content Server 26.1 and 26.2, with the hotfixes listed in the release notes applied. Our lab confirmed the matrix exactly: 3.7 did not run on 26.2, as the matrix says, so the matrix is the one to trust.
Module Suite 4.0 is also delivered as System Center ready module packages rather than the older Windows installer, which is a welcome change: the add-on now deploys through the same tooling as the platform. AnswerModules also gives clear guidance on timing for estates that use Script Console in production, so read the release notes for the components you use before deciding when to make the move to 4.0.
The wider lesson applies to every add-on, not just Module Suite. If your add-ons are not ready for the target version, your platform upgrade is not ready either. In practice, an upgrade is three upgrades: platform, add-ons and database, planned as one change.
A practical pre-upgrade checklist
Based on our own run, these are the six checks we would complete before any Content Server 26.2 upgrade, in this order.
| Check | Why it matters | What we found in our lab |
|---|---|---|
| 1. Inventory every version | You cannot plan compatibility from memory. Cover Content Server, OTDS, Archive Center, the database, Java, Tomcat and every add-on. | Our starting point was Content Server 24.3, OTDS 24.4, Module Suite 3.7 and an Oracle 19c database. |
| 2. Check each add-on against its vendor’s matrix | If your add-ons are not ready for the target version, your platform upgrade is not ready either. | Module Suite 3.7 did not run on 26.2, exactly as the AnswerModules matrix says. The matrix points to 4.0 with its listed hotfixes, and gives timing guidance for Script Console users. |
| 3. Sort licences before the window | On a production platform, a missing licence is not something to discover after the change window has closed. | A licence for 26.x was still an open item after the upgrade. |
| 4. Upgrade OTDS first | Bring it to at least the Content Server version before Content Server itself. | We took OTDS from 24.4 to 26.2 before Content Server. |
| 5. Take a verified backup and write down the restore | The database upgrade is the point of no return, so rolling back means a restore. | We prepared an application image, a cold copy of the database, a logical export and written restore steps. We did not need them. |
| 6. Plan smoke tests and a time box | Agree what “working” means (login, upload, versioning, search, workflow, a form or script, archive read and write) and keep time in reserve to roll back. | Content Server 26.2 and OTDS 26.2 were running at the end, with the licence and the Module Suite 4.0 step still to complete. |
Planning your own upgrade?
If you are weighing up a move to Content Server 26.2 and would like a second view on your versions, add-ons or rollback plan, book a 45-minute continuity check call.
For the planning side, see Content Management 26.2 upgrade readiness.
Frequently asked questions
Related reading