Case Study

MMM

Enterprise Historian Modernised Across 12 Sites Without Losing History

ANZCO Foods needed to modernise a business-critical enterprise historian receiving continuous data from 12 production sites across New Zealand and Australia — without losing historical archives, interrupting live SCADA data collection, or compounding an existing enterprise data access failure.

Project Reference

2025/13606

Handover Date

February 2026

v22 to v25

Historian Modernised

12 Sites

NZ & Australia

13 Systems

Ignition Continuity Maintained

HDB2

Archives Consolidated

“Modernise without losing history — a controlled brownfield upgrade that preserved operational data, maintained Ignition connectivity and reduced cutover risk through staged testing and validation.”

Project Overview

ANZCO Foods operates a geographically distributed production environment across New Zealand and Australia, with site-based Ignition SCADA systems sending operational data to a central Canary Enterprise Historian. The existing v22.x platform had become business-critical while ageing infrastructure, planned site growth and evolving OT/IT cybersecurity requirements created a need for modernisation.

A key driver was the loss of the existing ODBC connection to ANZCO's SQL Server data warehouse. Multiple recovery attempts had been unsuccessful. Parasyn implemented and validated a new Canary v25.x environment in parallel with the live system, preserving historical data and live Ignition integration while establishing a supported foundation for Web API-based data access and future growth.

Technical Scope & Requirements

The scope combined a major platform version upgrade with the resolution of an existing enterprise data access failure — without interrupting live SCADA data collection across 12 production sites.

Parallel v25 Environment

A new Canary v25 platform was established independently of the production historian, allowing configuration, compatibility and interface testing without disturbing live operations.

Historical Archive Migration

Existing HDB2 historian archives were imported and validated on the modernised platform, confirming that operational history remained accessible and intact.

Ignition Integration

13 site-based Ignition SCADA systems were validated against the new v25 environment — including Canary Ignition modules, Tag Splitter behaviour and Sender/Receiver communications.

Enterprise Data Access

The failed ODBC connection to ANZCO's SQL Server data warehouse was replaced with a supported Web API-based access pathway, establishing a maintainable foundation for downstream data consumers.

The Challenge — Modernising a Live, Integrated Historian

The project extended beyond a conventional software upgrade. ANZCO needed to modernise a central historian receiving continuous data from distributed Ignition SCADA systems — while protecting historical information, maintaining production visibility and addressing an existing enterprise integration failure.

Legacy Platform Dependency

The existing Canary v22.x environment consolidated the Historian, Axiom and supporting services on a single Windows Server 2019 VM. ANZCO required a new infrastructure approach that could be independently tested before individual SCADA systems were transitioned.

Failed Enterprise Data Access

The ODBC connection to ANZCO's SQL Server data warehouse had stopped functioning in 2024. Multiple recovery attempts were unsuccessful, making a supported alternative a hard project requirement.

Operational Continuity

Site SCADAs continuously historised operational data through Ignition Tag Splitter to both local Ignition historian storage and the central Canary platform. Changes required careful sequencing to protect data continuity and minimise production impact.

Version & Migration Compatibility

Upgrade-path constraints and differences between legacy and current Canary architectures required targeted engineering across Views, Identity Service, SQL interfaces and Ignition connectivity. Parasyn worked with Canary Support to validate version-specific behaviours before committing to the selected approach.

The Parasyn Solution — Controlled Parallel Deployment

Parasyn adopted a staged, parallel deployment strategy rather than an in-place production upgrade. A new Canary v25 environment was established separately, allowing the platform, historical archives and interfaces to be tested and validated before production transition. This provided clear verification and rollback points throughout the cutover sequence.

Baseline & Discovery

Reviewed the existing Canary v22.x architecture, site Ignition interfaces, historian archives, data consumers and operational dependencies before any change was introduced.

Parallel Platform Build

Established the new Canary v25 environment independently, introducing Identity Service, modern API-based integration and a defined pathway from legacy Sender/Receiver toward Store & Forward.

Historical Data Validation

Imported and validated existing HDB2 archives, confirming that operational history remained accessible and intact through the modernised platform.

Controlled Cutover & Ghosting

Executed the production migration through planned cutover procedures with defined verification and rollback steps. A mandatory two-week ghosting period confirmed stability across public holidays and peak production loads before final handover.

Implementation Methodology

Baseline & Discovery
Reviewed existing Canary v22.x architecture, site Ignition interfaces, historian archives, downstream data consumers and operational dependencies.
Parallel v25 Environment
Established the new Canary v25 platform on a separate VM, allowing configuration and compatibility testing without disturbing the live production historian.
Historical Data Validation
Imported and validated existing HDB2 archives, confirming accessibility and integrity on the modernised platform.
Ignition Integration & Parallel Testing
Tested the Ignition-to-Canary interface jointly with ANZCO — including Canary Ignition modules, Tag Splitter behaviour and Sender/Receiver communications. Parallel historian testing proved data delivery and compatibility before production transition.
Controlled Cutover
Executed migration through planned cutover procedures with defined verification and rollback steps, followed by a mandatory two-week ghosting period confirming stability before final handover.
Handover & Documentation
Issued as-built documentation, validated archive accessibility, confirmed API data access and formally handed over the modernised platform.

Project Outcomes

ANZCO Foods received a modernised, supported enterprise historian platform in February 2026 — with no loss of historical data and no interruption to live SCADA data collection across 12 production sites.

✓

Historical Continuity Preserved

HDB2 archives retained and validated on the modernised platform — protecting access to operational history built up under the previous system.

↑

Live Integration Maintained

All 13 Ignition SCADA systems continued to deliver data to the central historian without interruption throughout the upgrade and cutover sequence.

★

Enterprise Data Access Restored

The failed ODBC pathway was replaced with a supported Web API-based connection — establishing a maintainable foundation for downstream data consumers and future integration.

Standards & Frameworks Applied

ISO 9001 / SEMP — Parasyn Certified Management Systems applied throughout baseline review, parallel validation, cutover governance and post-change verification.

Canary Labs v25.x — Identity Service, Web API, Store & Forward pathway, HDB2 archive migration and Ignition module compatibility validated against current platform documentation.

Lessons Learned & Future Recommendations

Insight	Impact & Context	Recommendation
Test Before Production	Validate the new environment, archives and interfaces before changing the live historian.	Establish a separate validation environment as a mandatory first step on every historian upgrade engagement.
Treat Historian Upgrades as Integration Upgrades	Canary, Ignition modules, Sender/Receiver, Store and Forward, Identity Service, APIs and downstream consumers must be assessed as one integrated system.	Produce a complete integration map including all data consumers before commencing any historian version upgrade.
Keep Rollback Available	Parallel validation and documented rollback steps reduced operational exposure during cutover.	Define rollback procedures and verification checkpoints in the cutover plan before site work begins.
Mandate a Ghosting Period	A two-week ghosting period confirmed system stability across public holidays and peak production loads.	Include a mandatory ghosting period of at least two weeks as a contractual requirement on all historian migration engagements.