SCADA cutover with zero downtime. Strategy and lessons for Australian plants.

The cutover is the project.

Who calls whom at 02:00 on the cutover Saturday?

If the answer is "we'll sort it out on the night," the cutover plan does not yet exist. Most cutover failures are not technical. The system was tested, the build is correct, the network handshake works in the lab. What fails is the orchestration: who has authority to call rollback, what counts as "good enough to go live," which operator is on the line when the first surprise surfaces. The cutover that goes well is the boring one. The cutover that loses a production week is usually the one where the technical work was fine but nobody had decided in advance what to do when a thing they had not anticipated happened at 03:14.

Three cutover models, in detail.

The brownfield pillar introduces the three cutover models in passing. Here is the version with the trade-offs spelt out.

Big-bang weekend cutover.

The old system goes off Friday evening. The new system goes live Monday morning. Saturday and Sunday are migration, FAT-style verification, and the rollback rehearsal nobody hopes to need. This model suits lines that can absorb a planned weekend shutdown without breaking a supply commitment: sortation cells, end-of-line packers, single-product manufacturing runs, plants that already shut down for weekend maintenance. The rehearsed team carries this model. The fallback plan saves it when something does not behave the way it did in the lab.

What kills weekend cutovers: optimism. Plants that have not rehearsed the rollback, have not written the trigger criteria, or have not staffed the operator-side stabilisation watch are not running a weekend cutover. They are running a weekend gamble.

Parallel run with phased migration.

The new and old systems run side by side. Each subsystem switches over when both the engineering team and the operations team agree it is comfortable. Integration cost is higher because the team builds twice and maintains both. Risk on any single switchover is lower because the fallback is the system already running alongside, ready to resume. This is the right model for complex multi-line plants where a single weekend cannot contain the cutover, where the cost of an unplanned production day exceeds the cost of the parallel build, or where the regulatory environment will not tolerate a rollback recovery measured in shifts.

The hidden cost of parallel run is reconciliation. Two systems producing data that should agree but sometimes does not. The cutover plan needs explicit reconciliation criteria for every shared data path before the parallel mode goes live.

Module-by-module replacement.

One PLC, one cell, one line at a time, over months or quarters. The slowest model and the lowest single-day risk. It suits continuous-process operations, sites with regulatory uptime obligations, and plants where the upgrade is a strategic investment rather than a response to immediate failure. The drawback is calendar drag and the temptation to leave the last 20% incomplete because the line is "good enough." Modules left half-migrated tend to stay half-migrated for years, and the residual platform-split eats engineering attention with every subsequent change.

The four documents that decide it.

The cutover documents that pay back the most are not the ones the integrator builds for themselves. They are the ones operations relies on at 02:00. The minimum:

• Rollback trigger criteria. The specific test failures that revert the cutover, written as a yes/no checklist, signed off in advance by both the integrator and the operations team. Not "if it doesn't feel right" but "if test X returns Y, the rollback runs." Binary decisions made in advance survive 02:00 better than judgement calls made in the moment.
• Comms tree. Names and phone numbers. Who calls whom at what time. Who has authority to call rollback. Who briefs the operations director on Monday morning regardless of how the cutover went. Cutovers that rely on the on-call rotation rather than named individuals lose the first hour figuring out who is responsible for what.
• Test scripts in operator language. Green-light checks for each subsystem, written so that the operator on the line can read and execute them without needing the integrator to translate. Each step has an expected result. Each result has a pass/fail criterion. The script is the live document during the cutover window. If the script does not cover a situation, the cutover does not cover it either.
• Operator coverage roster. Who is on the line during cutover. Who reviews each shift. Who runs the post-cutover stabilisation week. The stabilisation week is where most cutover problems actually surface. A team that disbanded on Monday lunchtime cannot fix what shows up on Wednesday's overnight shift.

These four documents are not interchangeable with a Gantt chart or a project plan. They are operational documents that get used at the worst hour of the project. Treat them as such.

When something fails at 02:00.

Every cutover that has been on a real plant has had at least one 02:00 moment. The patterns repeat.

Symptom: a subsystem fails its green-light check in a way the test script does not cover.

This is the most common failure mode and the most disorienting. The new SCADA reports a value the old SCADA never produced. A vision system rejects packs at twice the expected rate. A PLC alarm fires that was supposed to be deprecated. The response is not to debug it in the moment. The response is to apply the rollback trigger: if the symptom matches a defined criterion, revert. If it does not match any criterion, the people in the room have to decide quickly whether they trust the symptom is benign. Default to revert if the decision is contested. The cost of a rollback is one weekend. The cost of a partial go-live that needs to be reversed on Tuesday is a production week.

Symptom: the network handshake works but throughput is wrong.

Profinet, OPC UA, or MQTT all behave well in the lab and surface latency issues on the live plant network. This is usually a switch configuration problem (broadcast storms, VLAN misconfiguration, ring topology not converging) rather than a controller problem. Network engineers should be on the cutover roster precisely because this class of failure is on their side, not the controls integrator's.

Symptom: an operator reports the line "feels off."

The hardest call. The system passes every defined test but the operator on the line is uneasy. The rehearsed response is not to dismiss it. Operators on a brownfield site have years of pattern recognition for their own line. A "feels off" report at 03:00 has caught more real failures than any green-light script. Investigate before signing off the cutover as complete. Often the operator has noticed a timing drift, an alarm that fires fractionally late, or a sequence that hesitates for half a second. Each is a thread worth pulling.

A weekend-cutover lesson from a sortation line.

Pac Technologies delivered a weekend cutover on a Victorian sortation line where the alternative was a multi-week phased migration with two unscheduled go-backs. The decision to use weekend cutover instead of phased migration came down to one factor: the supply chain could absorb 48 hours offline but could not absorb a fortnight of partial throughput.

The weekend went mostly as planned. The 02:00 moment was a parcel-rejection sequence that fired correctly on the new system but published the reject reason to a tag the operator dashboard had not been updated to read. The rejected parcels piled up in the divert lane and the operator escalated to the integrator at 02:37. The fix was a 90-second SCADA configuration change, made via the comms tree, signed off as a non-rollback condition under the trigger criteria. The weekend approach won on total downtime by a factor of three over the phased alternative.

The lesson is not that weekend cutovers always win. The lesson is that the cutover model has to match the failure tolerance of the customer's supply chain, and that decision belongs to the customer with the integrator's honest input, not the integrator alone.

Common questions.

Sources and further reading.

Industry references that complement the practical experience in this guide. Retrieved 18 May 2026.

• Automation World. Checklist for Short-Duration Cutover Success. automationworld.com
• Control Engineering. How to slash downtime with a phased approach to PLC migration. controleng.com
• NFM Consulting. SCADA System Upgrade and Migration Planning. nfmconsulting.com

This article sits under the Brownfield PLC Upgrade Guide. For the platform-side of a Siemens migration that often precedes the cutover work above, see the S7-300 to S7-1500 migration article.