When the Server Dies and the Backup Is Three Years Old: Reviving a Legacy Biturox SCADA System

It wasn’t supposed to be that complicated

The call came on a Monday morning. The SCADA (supervisory control and data acquisition) server on the refinery’s Biturox research unit had stopped working completely: no POST (power-on self-test), no boot, nothing. Someone opened the server room to find the machine stone cold dead after what appeared to be a hardware failure. The research program using that unit was supposed to resume that week.

What followed was one of the more instructive projects I’ve worked on in six years of industrial automation. Not because the technology was exotic, but because every assumption you might make about “just migrating” a legacy SCADA turns out to need revisiting. This article covers what we actually encountered: the hardware diagnosis that made migration unavoidable, a Sybase database problem with no easy download fix, the multi-step migration path that Siemens documentation specifies but not everyone follows, a CP5611 driver situation that consumed more time than it should have and why the oldest backup you can find is still worth its weight in gold.

What is a Biturox unit and why does it matter?

Before getting into the automation side, it’s worth explaining what this equipment actually does because it’s not something you encounter every day.

The Biturox process is a continuous air-oxidation technology for producing high-quality bitumen from refinery feedstocks. It was originally developed by the Austrian oil company OMV and has been licensed and engineered worldwide by the Pörner Group, a Vienna-based process engineering firm operating since 1978. To date, more than 60 Biturox plants have been licensed globally, collectively accounting for roughly 12% of world bitumen production capacity.

The process works by injecting air into molten bitumen feedstock held at an elevated temperature inside a continuous-flow reactor. The controlled oxidation reaction changes the rheological properties of the product, converting softer vacuum residue grades into the harder, more durable grades used in road construction, industrial waterproofing and roofing applications.

This unit (Figures 1, 2 and 3) is significant because it was a research installation. It was not used for commercial production but for testing new feedstock compositions and product formulations. That distinction matters enormously for how the control system needs to work. A research setup requires flexibility, detailed data capture and the ability to run non-standard sequences that a production SCADA is simply not designed for.

Figure 1: Biturox research unit overview. Pneumatic control valves (Kämmer/Flowserve), air supply piping and the S7-300 I/O cabinet (on the left, see Figure 3).

Figure 2: Close-up of the Pörner Ingenieurgesellschaft m.b.H. nameplate in Figure 1.  

Figure 3: S7-300 automation cabinet. The PLC and I/O modules visible at the top continued to operate throughout the server failure. The control program ran autonomously, keeping the unit in a safe state.

Losing the automation system meant losing the ability to run any of this research. The clock was ticking.

What we were working with

The control system, as found, consisted of:

• SCADA: Siemens WinCC v5.6, running on a dedicated industrial server
• Programmable logic controller (PLC): Siemens SIMATIC S7-300 with the original control program in STL/LAD
• Communication: CP5611 PCI card providing the multi-point interface (MPI) connection between the server and the PLC
• Human-machine interface (HMI): Operator workstations on the local network connected to the WinCC server
• Process I/O: Temperature control loops, air flow regulation, product viscosity monitoring and safety interlocks

The system had been running for years without significant modification. The documentation was incomplete, which is not unusual for a unit that had been in operation for a long time and through multiple engineers. The most recent project backup we could locate was a WinCC v5.6 archive from roughly three years prior. This was not ideal, but we had no other starting point.

Why we didn’t just find another server

The obvious first question was: Can we repair or replace the failed server like-for-like? If we could source the same hardware, we’d avoid any migration. We could restore the backup onto an identical machine and be done with it.

The physical diagnosis gave a clear answer. After opening the unit and running basic tests, we confirmed that the motherboard had failed. The server was an Advantech industrial PC, a solid, purpose-built piece of hardware with wide-temperature tolerance and the long component lifecycles that process industry applications demand. Advantech machines are built to last, and this one clearly had.

The problem was that it had lasted almost too well. At over 20 years old, that product line had been discontinued long ago. A genuine replacement board was simply not available—not from Advantech and not from any industrial reseller we could identify. The secondary market for hardware that age is unreliable at best.

Spending weeks hunting for a discontinued part while the research program sat idle wasn’t realistic. The decision to replace it with a current-generation Advantech industrial PC was straightforward: Use the same vendor for industrial-grade reliability and current hardware with a known operating system (OS) compatibility matrix for the SIMATIC NET and WinCC versions we’d be targeting.

This decision made migration unavoidable. A new machine means a modern 64-bit Windows OS. WinCC v5.6 does not run on modern Windows; it was designed for Windows NT and early Windows XP environments, as the screenshot in Figure 4 makes clear. So, the question shifted from “Can we avoid migration?” to “What is the correct migration path, and how do we execute it without losing what’s in the archive?”  

Figure 4: Original server running Windows NT. Set PG/PC Interface v5.0 showing CP5611 (MPI) as the active communication path to the S7-300. This shows how old the system was.

The migration path: Why you cannot go straight from V5 to V7

The first instinct when told to migrate WinCC v5.6 to v7.5 was to install v7.5 and run the Project Migrator. That instinct is wrong and it will cost you time.

Siemens documentation (Entry ID 44029132) is explicit: Direct migration from WinCC V5 to V7 is not supported and results in database corruption and project inaccessibility. The migration must be staged as illustrated in Table 1:

Table 1: WinCC migration stages.

Siemens also notes from field experience that some older projects cannot survive large version jumps at all and recommends stepping through every major version: V6 → V7.0 → V7.2 → V7.5. The reason is the database architecture. WinCC V5 uses Sybase SQL Anywhere 7 as its database engine. WinCC V6 migrates the project to Microsoft SQL Server. WinCC V7 further updates the SQL schema and switches all strings to Unicode. Each transition requires the specific migration tool that ships with that version. There is no shortcut and the stages cannot be combined.

For a project as old and as undocumented as ours, we took the conservative path and didn’t skip any steps.

The Sybase problem and why it blocked everything

Here is where we lost the most time, and it’s worth describing in detail because the solution isn’t obvious.

The CCMigrator (WinCC Project Migrator) requires Sybase SQL Anywhere 7 to be installed on the migration machine in order to read the V5 project database. Without it, migration cannot start. The error shown in Figure 5 is unambiguous.

Figure 5: CCMigrator Step 2 of 3 error: “An error occurred while starting Sybase 7. Please check whether Sybase 7 has been correctly installed. Migration could not be performed.”

The fix, in principle, is to install Sybase SQL Anywhere 7 alongside WinCC V6.2. Siemens historically included it on the WinCC V5.x installation media or provided it as a separate download through their support portal.

The catch in 2025–2026. Sybase SQL Anywhere 7 is no longer available for download anywhere through official channels. SAP acquired Sybase in 2010, and legacy versions of SQL Anywhere have been progressively removed from public access. The Siemens support portal no longer hosts the installer. The software is effectively abandoned. I spent the better part of an afternoon convinced I was missing something obvious before accepting that the installer simply doesn’t exist online anymore.

We resolved this by locating the original WinCC V5.1 SP2 installation media, the physical disc set that came with the system when it was originally commissioned. That media contains the Sybase SQL Anywhere 7 installer. If you don’t have the original discs, your options are to contact Siemens technical support directly (they may be able to provide the installer through a support case) or search within your organization’s archive of old installation media from that era.

The lesson. Before starting any WinCC V5 migration, locate the original installation media first. Don’t assume that you can download what you need. In this case, the physical discs—stored somewhere in the facility’s archives for over two decades—turned out to be essential.

Once Sybase was correctly installed, the CCMigrator completed Step 1 (V5 → V6.2) without further errors. The migration log still flagged items to fix manually, but at least it ran.

What changed between versions and what broke

Each migration step introduced incompatibilities that required manual intervention:

• Tag names with special characters (including Cyrillic) were rejected by V6.2. Each had to be renamed and the references updated throughout the project.
• Visual Basic scripts written against the V5 object model called methods and properties that no longer existed in V6 and V7. These had to be rewritten in the VBS-Action editor to be compatible with the new WinCC object model.
• Picture objects in process mimic screens lost their associated servers during migration. Each screen had to be opened and the dynamic connections re-established manually.
• V7.0 migrated all string data to Unicode, which caused display issues with any text that had been stored as legacy encoding. We had to review alarm messages, tag descriptions and on-screen labels.

The migration log is not optional reading. It tells you exactly what the migrator couldn’t handle automatically. In our project, the log was several pages long. Working through it systematically took most of a day.

The CP5611 problem: When the card is there but the driver isn’t

With the migrated project ready to test on the new Advantech server, we hit the next obstacle: communication. The CP5611 PCI card was physically seated in the slot and it appeared in Windows Device Manager, but WinCC couldn’t see the PLC.

The symptom. The card showed up as an unknown or unrecognized network adapter with a yellow warning triangle. The S7-300 was unreachable.

The root cause. This catches people off guard. The CP5611 driver is not a standalone installer; it is embedded in the SIMATIC NET PC software package. You cannot download a driver file and install it through Device Manager. The driver comes only by installing the correct version of SIMATIC NET, and that version must match both the WinCC version and the Windows OS on the new server.

There is also a hardware constraint: the CP5611 requires a 32-bit PCI slot and is not compatible with 64-bit Windows for MPI communication. The new Advantech machine had a standard PCI slot available, but the SIMATIC NET version initially installed was a mismatch for WinCC V7.5.

Resolution. We had to uninstall the existing SIMATIC NET, install the correct version for WinCC V7.5, reboot, reconfigure the access point in “Set PG/PC Interface” to CP5611 (MPI) and verify enumeration. After that, the S7-300 came online.

One practical note that saved time later: After any hardware change on the SCADA server, always create the configuration for the PC station in the Station Configuration Editor from scratch. Importing an old station configuration from a different machine causes more problems than it solves. That whole CP5611 episode cost us most of Tuesday.

Updating the S7-300: From production logic to research tool

With SCADA running and communicating, we moved to the reason the recovery had been initiated: extending the S7-300 program to support the research activities planned for the unit.

The original PLC program was built around stable production operation: fixed setpoints, standard proportional-integral-derivative (PID) loops and a conventional alarm structure. The research team needed something different: multi-stage oxidation sequences with variable temperature profiles, high-frequency data capture and in some cases, the ability to run the unit under conditions that would trip standard production interlocks.

New logic blocks were added to the S7-300 program:

• Step sequencer for oxidation profiles: A function-based sequence controller allowing researchers to define multi-stage time/temperature transitions without touching the base control logic
• High-frequency data capture triggers: Additional logging tags in WinCC for variables requiring millisecond-level trend resolution during experimental runs
• Research mode with controlled interlock bypass: A keyed mode selector providing a parallel interlock structure—when active, specific production-grade shutdowns become alerts-only and every state change is time-stamped in the WinCC alarm log
• Operator intervention logging: Database entries tracking all manual overrides, enabling exact reconstruction of operator actions during any experimental run

All additions were implemented as separate functions and data blocks, leaving the original base program intact. This was deliberate. It keeps future maintenance clean, and it means the new logic could be validated independently without risk to the existing control structure.

The result

After working through the hardware replacement, the Sybase problem, the staged migration, the CP5611 driver reinstall and the PLC logic extension, the unit came back online.

The WinCC mimic screen in Figure 6 shows the migrated and restored system running: live values from the S7-300, the reactor graphic with real-time temperature readouts, the off-gas condenser section and the research-mode alarm at the bottom of the screen. This is what the recovery was for.  

Figure 6: Restored WinCC operator screen showing the Biturox reactor mimic with live process values.

The control system that emerged from the process was more capable than the one that failed. It was migrated to a supported WinCC version on current hardware, extended with logic designed explicitly for experimental operation, and—this time—documented.

Lessons learned

The Sybase problem. If you are migrating any WinCC V5.x project, locate the original installation media before you start. Sybase SQL Anywhere 7 is no longer downloadable through official channels. Without it, CCMigrator will not run. The physical discs from the original system commissioning may be the only source.

Backup currency. A three-year-old backup is vastly better than nothing. We spent considerable time cross-referencing the old project against the S7-300 symbol table and piping and instrumentation drawing (P&ID) fragments to identify what had changed, but we had a foundation. Without that archive, we would have been rebuilding from scratch. Ours was on a USB drive in a drawer labeled “OLD BITUROX STUFF” (I am not making this up). The lesson is this: Regular, off-server, versioned backups of SCADA projects deserve the same discipline as PLC program backups.

Migration documentation. Siemens FAQ document Entry ID 44029132 is thorough and accurate. Read it before starting, not after you hit the first error. The intermediate version requirement is not a suggestion—skipping it produces a corrupted project.

Communication hardware. The CP5611 has known quirks around driver installation. On a new server, install SIMATIC NET first, verify that the card enumerates correctly and test communication before migrating the SCADA project. Debugging a communication failure and a migration failure simultaneously is unpleasant.

Research versus production control systems. A control system designed for production stability is not automatically suitable for research use. Sequence control, enhanced logging and controlled interlock bypass are standard engineering features. If a facility runs experimental programs on process equipment, these capabilities are worth building into the architecture from the start. They should not be bolted on as workarounds later.

Conclusion

Legacy SCADA recovery is unglamorous work. It involves reading migration logs line by line, hunting for 25-year-old installation discs, fighting with driver versions and spending more time in Windows Device Manager than anyone would choose. But the alternative—losing specialized research infrastructure that cannot be easily replaced—is considerably worse.

For automation engineers facing similar situations, the path exists, the documentation is there and the problems are solvable. It just takes longer than you think it will.