case studies · industry platforms

Industry platforms, move by move.

Regulators read policy admin, claims, core banking and EHR systems closely, so every change has to appear in the change log. We stick to the vendor's upgrade path and keep the examiner's evidence up to date as we go.

10 case studies4 upgrades3 migrations2 implementations1 modernization26 platforms
featured case study

AVEVA PI data to cloud analytics on Databricks or Fabric

Told without the client's name or anything that could identify them.

what happened

A chemical manufacturer's data scientists kept asking for direct connections into plant historians, and cloud teams copied PI data with scripts that broke whenever a tag was renamed. Every site named tags differently, and a PI subscription renewal was coming without a clear list of the components analytics needed. We read interface logs, buffering settings and archive gaps by site and fixed the collection problems first, then agreed a tag naming and asset hierarchy standard with process engineers. Data now leaves the plant outbound through a DMZ PI replica and lands in Delta tables under Unity Catalog with asset context attached.

what the client got
  • Nothing in the cloud connects into the control networkPI data reaches the cloud through an outbound feed from a DMZ replica. No inbound firewall rules to the control network were needed.
  • Tags follow one naming and asset standardProcess engineers agreed a tag naming and asset hierarchy standard, starting with the units and equipment analysts ask about most, so cross-site analysis no longer starts in a spreadsheet.
  • Collection gaps are fixed at the sourceInterface, buffering and stale tag problems were fixed site by site before analytics leaned on the data. Otherwise they'd have turned up later as flat lines on someone's chart.
Read the full case study
after / pi-historian-to-cloud-analytics delivered
beforeAVEVA PI System site historians afterDatabricks or Microsoft Fabric
01 · PLANT NETWORK 02 · INDUSTRIAL DMZ 03 · CLOUD ANALYTICS 04 · CONSUMERS Control systems: DCS · PLCs Control systems DCS · PLCs PI interfaces: buffering fixed PI interfaces buffering fixed Site PI Data Archive: standard tag names Site PI Data Archive standard tag names DMZ PI replica: outbound feed only DMZ PI replica outbound feed only Delta tables: Unity Catalog · asset context Delta tables Unity Catalog · assetcontext Asset model: agreed naming · hierarchy Asset model agreed naming ·hierarchy Data scientists: notebooks · SQL Data scientists notebooks · SQL Data quality checks: site and data teams Data quality checks site and data teams
every case study

All 10 in industry platforms

Read any of them and you get the story, the before-and-after architecture, the plan phase by phase and the results.

modernization Industry platforms

AVEVA PI data to cloud analytics on Databricks or Fabric

Getting AVEVA PI System data into Databricks or Microsoft Fabric with asset context, outbound-only paths out of the plant and tag names people understand.

read the case study
migration Industry platforms

Duck Creek on-premises to Duck Creek OnDemand

We move self-hosted Duck Creek Policy, Billing and Claims onto Duck Creek OnDemand and keep the product and rating content, integrations and data intact.

read the case study
implementation Industry platforms

Epic integrations, FHIR APIs and TEFCA connectivity

Building and governing the HL7 and FHIR integrations, SMART on FHIR apps and TEFCA exchange around Epic, with an interface catalog and scope reviews.

read the case study
migration Industry platforms

Guidewire InsuranceSuite self-managed to Guidewire Cloud

Moving self-managed PolicyCenter, BillingCenter and ClaimCenter to Guidewire Cloud without carrying every Gosu customization and integration along.

read the case study
upgrade Industry platforms

Murex MX.3 upgrades and the move to MXSaaS

Planning the next Murex MX.3 upgrade, or a move to MXSaaS, with automated regression on trades, valuations and accounting and the datamart reports traced.

read the case study
upgrade Industry platforms

Nasdaq Calypso upgrade to V19

Upgrading Nasdaq Calypso to V19, with server consolidation, properties moved to the database, the WebUI and deployment changes tested on your own trades.

read the case study
upgrade Industry platforms

Oracle Utilities CC&B 2.x to the 25.x release line

Taking Oracle Utilities CC&B from 2.6, 2.7, 2.8 or 2.9 to 25.4 on a tested upgrade path, with custom algorithms checked and bill cycles compared.

read the case study
migration Industry platforms

SAP IS-U to S/4HANA Utilities

Taking SAP IS-U from ECC 6.0 to S/4HANA Utilities ahead of 2027, and proving billing variants, device data and FI-CA in parallel billing first.

read the case study
upgrade Industry platforms

Temenos core banking upgrades and Temenos SaaS

Upgrading Temenos Transact (formerly T24), or moving to Temenos SaaS, with local developments traced, retired or rebuilt, and regression automated.

read the case study
implementation Industry platforms

TriZetto Facets upgrades and CMS-0057-F interoperability APIs

Keeping TriZetto Facets current while we build the Provider Access, Payer-to-Payer and Prior Authorization APIs that CMS-0057-F requires by January 2027.

read the case study

Not sure which one fits?

Send us what you run and what's due. An engineer reads it and tells you where we'd start.

start an assessment →
what goes wrong

Risks that keep coming up

One risk from each of these moves, and the case study that shows how we handled it when it hit.

  1. Opening a path into OT ↗

    A design that needs inbound firewall rules to the control network will stall with the OT team, and it should. All feeds run outbound from the DMZ or CONNECT.

  2. Manuscript drift ↗

    Years of state-specific manuscript edits rarely match documentation. Comparing rated premium on real policies before and after the move is the only reliable check.

  3. Over-broad FHIR scopes ↗

    Apps approved with more scopes than they need expose patient data that was never in scope for their use case. We review every scope against the app's job.

  4. Rebuilding every customization ↗

    Moving all Gosu code as-is recreates the upgrade problem in the cloud. Each item needs a keep, replace or drop decision before build starts.

  5. Manual regression filling the window ↗

    With spreadsheet regression, only so many test cycles fit before go-live. Automation is usually what turns two cycles into several.

  6. Topology assumptions breaking ↗

    Server consolidation changes what runs where. Monitoring, failover and engine sizing built for the old layout need rework.

01Should we use AVEVA CONNECT or build our own feed from PI?

It depends on your licence, how many sites you have and whether you want AVEVA to run the cloud side. CONNECT with Delta Sharing suits Databricks users. A DMZ replica with your own outbound feed gives more control. We cost both against your sites.

02Do we lose our custom products when moving to OnDemand?

No. Product and rating content moves across as it is. Custom extensions and integrations are another matter, because they're built and deployed differently on OnDemand. We go through each before the migration so nothing disappears unexpectedly.

03Do we need to do anything for TEFCA if Epic is our QHIN connection?

Usually, yes. You still decide which exchange purposes to support, how requests get answered, and how consent and patient matching work. We go through those settings and the workflows behind them with your team.

04How long does a move to Guidewire Cloud take?

It depends on how many products and lines of business you run, how much Gosu code and how many integrations you carry, and how much history you convert. We give an estimate after the customization and integration inventory, not before.

05Should we upgrade ourselves or move to MXSaaS?

It depends on your hosting and regulatory constraints, how many interfaces need to change and how much in-house MX.3 operations staff you want to keep. We lay both options out against your own estate.

other areas

More case studies by area

The same approach, applied to other parts of the estate.

next step

Facing one of these moves?

Tell us what you're on now and where you need to be. We'll come back with how we'd run the move.

useful to bring
  • The platform and the version you're on
  • Where you need to get to, and by when
  • What's custom: rules, plugins, integrations
  • Any audit finding or deadline driving it