Upgrading/replacing a database or OpenText Documentum server

From time to time every database or content server needs to be upgraded or replaced. Sometimes it’s just to update the application, sometimes you need to replace or upgrade the operating system and sometimes you want to get rid of a software vendor to replace it with another.

There can be different reasons: a version of an application or a hardware operation system is running out of support, or a newer version of one product doesn’t work for an older version of the other. Rarely a product is even discontinued and thus must be replaced entirely.

If there are no additional requirements to the intend, an inplace upgrade can be done without much hassle. The required effort is rather limited: just start the installer provided by the vendor and let it do the job. If an operating system change is involved, you have to do a little more but overall it’s an easy procedure as well. It’s important to keep track of the different versions (database, content server, and applications) so they all work seamlessly together – but other than that there is only one thing to keep in mind: there will be a downtime.

Although it is only a short downtime window where the system is not usable, it could make the solution completely unusable. In some areas applications must be up and running nearly 24/7, e.g. an online shop or public healthcare files. So what are alternatives with which to address this?

How to deal with a system which needs to be up 24 hours a day, 7 days a week and 12 months a year?

The answer is delta migration and the idea is simple: prepare and setup the target system with all needed upgrades, new operating system and/or a new database. Install a fresh and clean content server.

Then migrate the old (and still up & running) system to the new target system in the background all day long. It will basically create a clone of the existing system and it does not really matter how long it will take.

The process just runs in the background without users even making notice of it. It will migrate bit by bit all documents and information to the target system. Once the first “wave” is finished, a second wave will begin, typically called “delta migration“.

With migration-center the process is fully controlled. The delta run will collect all documents changed since the first run and newly created content. The duration of the “delta” will be much shorter than the first run because it will skip all already scanned documents which haven’t changed since the last scan. Then there are more waves to follow – as many as needed (depending on the overall size of the repository) until the very last delta run will only take a few minutes or even seconds.

Now it’s time for the final switch-over. In that last phase, the applications and services pointing to the old system will be reconfigured and redirected to point to the cloned system. During this phase, the background delta migration can still be performed so no information is lost during the transition phase.
From then on all users will automatically work on the new system and after a testing phase, the old system can be switched off if the new system works as expected. Good news is that if something goes wrong or the new system is not working as expected, everything can be restored, and the old system is still working. Also, the migration work is not lost because you can, with the help of migration-center, fix the target system and do the switch-over again.

There’s one catch for this upgrade approach. The documents get a new, unique ID in the new system. This becomes a problem if this ID is stored outside of the system: as a reference in third-party systems or simply because direct links to the documents have been exchanged via email. But fortunately, this is also solvable. Among other things, migration-center stores the assignment of old to new IDs. And a list of these can be exported. With the help of those, you can now extend your applications with a feature that recognizes the old IDs, determines the appropriate new ID, and redirects the request from the third-party system or a user to the correct ID.