Moranbah North CHPP: AVEVA Ampla to Production Management 2025 Migration

The Challenge

The coal handling and preparation plant (CHPP) at Moranbah North runs its production truth through AVEVA Ampla — automatic downtime detection, production and metrics accounting, operator shift logs and downtime classification, feeding roughly 35 operational SSRS reports from the shiftly SIC report through to train loadout and weekly operations and maintenance summaries. Eight years on, that system was a 2018-era Ampla 7.0 install running on an ageing standalone virtual machine with a local SQL Server — an unsupported software version on end-of-life infrastructure, carrying real operational and security risk.

Two things made the upgrade to AVEVA Production Management 2025 harder than a routine reinstall:

• No direct upgrade path. AVEVA confirmed the database had to be stepped through a chain — 7.0 to 7.3 to 9.0 to 9.2 — before it could run on the new platform. Four versions, in sequence, with no shortcut.
• History had to survive. Years of operator downtime classifications are irreplaceable institutional knowledge. A like-for-like reinstall would have orphaned them. Preserving 100% of that history, intact and verifiable, was non-negotiable.

All of this had to land inside a single plant maintenance window, with the production reporting system as the one thing that could not be treated as an experiment.

Our Approach

The core of the engagement was a deliberate architectural decision we call a throwaway parallel run with a data-swap cutover — a two-server model designed so that the live production system was never the thing being tinkered with.

A new production server, proven in advance. We built the new AVEVA Production Management 2025 stack from the ground up — licensing, OPC HDA connectors over DCOM to the plant historian, a port of the site’s custom code, and a full rebuild of the SSRS report suite. This new server was connected to live plant data sources and run in parallel against a disposable copy of the production database for around a week. Every configuration fix — connectors, custom calculations, report layouts, security — was made and validated here, on a copy, while the old server carried on as the source of truth. A purpose-built PowerShell validation harness ran daily automated comparisons: downtime event parity, production totals, metrics, and report output checked against golden PDFs, with go/no-go reporting.

A staging server for the version ladder. Separately, a staging server repeatedly ran the full 7.0 → 7.3 → 9.0 → 9.2 upgrade chain against scratch copies of the database — first as a proof in July, then for real on cutover day. This is where the four-version migration risk was retired, well away from anything operational.

The data-swap innovation. A conventional migration restores the whole database — data and configuration — onto the new platform and then spends the window chasing everything that broke. We inverted that. On cutover day, only the data was freshly captured from the old server, laddered up through the four versions on staging, and then swapped underneath the new server’s already-proven configuration. The new server’s config database, security store, report fixes and connector settings were never touched. Because the new server had been validated for a week and the incoming data arrived at a matching version by design, the post-cutover fix list collapsed to essentially nothing.

Rollback was doing nothing. The old server was left completely untouched all day — its service was stopped, and that was the extent of it. Any failure at any point before we declared success meant restarting a single Windows service. The safety of the whole plan came from that untouched old server, not from any one clever mechanism — which is exactly what the cutover day went on to prove.

We made one considered risk decision worth naming: the standalone formal rehearsal was folded into the July chain proof and a timed transfer leg rather than run as a separate event. With the upgrade chain already proven end-to-end and the data transfer already timed, a dedicated dry run would have re-tested known-good ground.

The Cutover

The cutover was scheduled for a planned plant maintenance day, with the plant deliberately idle — so any collection gap carried no real production data loss.

• 14:05 — old server service stopped; fresh backup and restore of the data database to scratch names (about a minute; 905 MB compressed).
• Staging ran the full three-pass upgrade chain. The version ladders themselves were fast — two minutes, then twelve seconds, then six. The engineering had all been done in preparation; the window was mostly software installs.
• A ten-minute database swap brought the upgraded data under the new production server.
• The new server started with zero upgrade work to do — version-matched by design.
• Smoke test: historical downtime with operator classifications verified by query, reports rendering, connectors live. Collection resumed at 16:09.

The window ran longer than the original 60–90 minute target — a little over two hours of collection gap — for a specific, accepted reason. The staging VM snapshots that the fast “snapshot-hop” approach depended on had been cleaned up by IT overnight. Rather than abort, the plan reflowed on the spot: the software was installed inside the window (cheap, because the plant was idle) and fresh snapshots were taken at each stage as retry points. The extra time bought exactly the same safety, a different way — a direct demonstration that the model never depended on any single mechanism.

Headline numbers:

• Four-version database migration chain, executed in one window
• ~2 hours of collection gap on a plant-down maintenance day — effective production data loss: nil
• 100% of history preserved, including operator downtime classifications — verified same day by query and by report comparison against the old server
• Database transfer under one minute; version ladders of 2 min / 12 s / 6 s
• Rollback plan never invoked
• Zero changes required on the new production server after the swap

Migration as Archaeology

An eight-year-old production system quietly accumulates things nobody is watching. Because our method baselined every anomaly against historical logs before deciding whether the migration had caused it, the work doubled as an audit that mostly paid for itself.

A least-privilege service account, and the dependencies it exposed. Moving the AVEVA service off a legacy admin-by-group account and onto a least-privilege managed account surfaced five hidden dependencies one at a time — filesystem permission rewrites, an authorisation-store role, several per-account HTTP URL reservations, credentials that had been encrypted per Windows account (and so were silently unreadable after any account change), and a port-sharing registration failure that had been quietly killing a lab-data integration with no log entry at all. Each was diagnosed and fixed in an afternoon by comparing error logs against pre-change days rather than guessing — the security modernisation was worth doing, and it was only tractable because the investigation was evidence-led.

Connections that had been dead for years. A downtime-module database connection generating a flood of errors turned out to reference a legacy database that did not exist on the old server either — three calculated fields had silently never worked on any server in living memory. The migration did not break it; the migration was simply the first time in years anyone had looked.

Reports that had been failing in silence. A subscription inventory found that a significant share of scheduled reports had been quietly failing on the old server for months, against dead domain accounts. Nobody had been receiving them, and nobody had noticed. Rebuilding the subscription and email delivery on the new server put them back into people’s inboxes.

Throughout, we kept a strict config-freeze discipline: broken-but-stable things were deliberately not fixed in the days before cutover — they were logged for post-cutover change control instead, so the window changed as little as possible. The run sheet also carried a known-noise list telling the cutover crew exactly which errors not to chase at 2am, so the real signals stood out.

The Outcome

The new server is now the sole production system for plant reporting. The old server and staging server were powered off and retained as quarantine and retry safety nets for two weeks after go-live, with a complete backup lineage kept — the final old-server state, the pre-swap parallel state, and the upgraded final state.

Two post-cutover items were identified honestly and tracked to closure rather than papered over: a time-limited consignment licence produced a self-clearing revocation pattern (decoded from timestamps and escalated to the vendor with an evidence pack, pending a permanent licence), and one metrics view was flagged for investigation. Neither affected production data collection. A handful of planned follow-ups — permanent licence replacement, legacy connection retirement, and desktop client rollout — were owned and scheduled through normal change control.

We left the site with the tooling, not just the result: the service-account verification script, the validation and comparison harness with its go/no-go reporting, the timed database transfer script, and a living run sheet and runbook updated in real time as every gotcha surfaced — final versions that read as an executed record with per-leg actual timings. The pre-written database restore statement, verified against live paths and stamped into the run sheet before the window, meant nothing was composed under pressure.

A four-version migration of a mission-critical system, delivered so uneventfully that its most notable feature is how little happened during the window — because all the hard engineering happened before it.

Technologies and Capabilities

• AVEVA Ampla 7.0 to AVEVA Production Management 2025 (9.2.1) migration
• Four-version SQL Server database upgrade chain (7.0 → 7.3 → 9.0 → 9.2)
• Data-swap cutover architecture with untouched-old-server rollback
• Windows Server 2022 and SQL Server failover cluster
• SSRS report suite rebuild, subscriptions and email delivery
• OPC HDA (OSIsoft PI) connectivity over DCOM
• RabbitMQ messaging and WCF / net.tcp services
• AzMan authorisation store and least-privilege managed service accounts
• PowerShell automation — data transfer, validation and verification harnesses
• Production and metrics accounting, automatic downtime detection