Migrating to HealthShare Connect Cloud: What NZ Providers Need to Know Before They Start

What HealthShare Connect Cloud Actually Is

HealthShare Connect Cloud (HSCC) is InterSystems' SaaS-hosted delivery of its integration platform — built on InterSystems IRIS for Health — managed and operated by InterSystems rather than the customer's own infrastructure team. The distinction matters operationally: where an on-premise HealthShare or Ensemble installation gives your team full access to the server, OS, namespace configuration, and upgrade schedule, Connect Cloud moves those responsibilities to InterSystems.

What changes in the cloud model: the hosting layer and physical infrastructure, patching and version upgrade cadence (managed by InterSystems on a defined schedule), the support model (issues go through InterSystems WRC rather than your internal team), and where configurations and deployment artefacts live (within the cloud management layer rather than a local file system).

What stays the same: the HL7 v2 processing logic you have built over years, your FHIR endpoints and resource mappings, the production and namespace architecture, Business Services, Business Processes, Business Operations, and any ObjectScript code your team has written. The runtime is the same IRIS for Health engine — the change is in who operates the platform beneath it.

The licensing model also shifts. On-premise HealthShare involves a capital or committed software licence against known server capacity. Connect Cloud moves toward a consumption or subscription model, which changes how integration costs are budgeted and allocated across financial years. For organisations with fixed capital vs operating budget constraints, this is a planning conversation that needs to happen before the technical migration begins.

The Migration Decision Factors

Migration to Connect Cloud makes sense when capacity constraints are limiting your on-premise estate — particularly where server provisioning cycles are slow, where upcoming hardware refresh creates a natural transition point, or where the organisation wants to reduce the operational overhead of managing InterSystems infrastructure. Providers who are approaching an Ensemble-to-HealthShare or HealthShare version upgrade may find it more efficient to migrate to HSCC than to perform the upgrade in-place.

It makes less sense when the production estate is heavily customised with complex ObjectScript that has hard dependencies on local infrastructure — shared file drops, locally-hosted services, or ODBC connections to on-premise databases. Multi-namespace estates with many interdependencies between namespaces require careful mapping before any migration can begin. Significant staff capability gaps — teams who know how to operate HealthShare on-premise but have not worked in the cloud delivery model — also represent a readiness constraint that needs to be resolved before migration, not during it.

The hidden cost organisations routinely underestimate is threefold. First, staff retraining on the HSCC platform model — the Management Portal, deployment pipelines, and support workflows are different enough that teams need deliberate preparation. Second, interface re-testing against the new environment is not optional: even interfaces that migrate cleanly at the code level need to be validated against the cloud runtime before production cutover. Third, and most significantly, documentation that was never written for the on-premise estate becomes an immediate liability during migration — you cannot migrate what you cannot describe.

Interface Estate Assessment Before You Migrate

A full interface inventory is a prerequisite for migration planning, not a parallel workstream. Most NZ teams do not have one. What commonly exists is a combination of partial documentation, a list of Business Services in the Management Portal, and institutional knowledge spread across two or three engineers who built or inherited the estate over several years.

What you need for each interface: a versioned message specification (which HL7 version, which segments, what field-level processing rules apply), the connection configuration (TCP listener ports, TLS settings, IP allowlists), the transformation and routing logic (what Business Process the message flows through, what modifications are applied), and the business rules that govern error handling and acknowledgement behaviour. What most NZ teams have: a spreadsheet with system names, and the engineers' memory of the rest.

Identifying undocumented interfaces requires more than a portal audit. Productions that were built for a project that has since ended, feeds that still run but whose downstream system is no longer active, and routing rules that were added to handle an edge case years ago and never revisited — all of these surface during a structured assessment and all of them require a decision before migration begins.

Test coverage is the hardest gap to close quickly. Can your team confidently regression test the interface estate end-to-end if a platform update changes behaviour? In most NZ organisations, the honest answer is no. Message replays, synthetic test payloads, and known-good output baselines need to be established during the assessment phase, not retrofitted after the cloud migration is underway.

The Migration Architecture

Environment strategy is a foundational decision. A typical HSCC migration architecture involves at minimum three environments: development (where interfaces are built and unit-tested), a staging or pre-production environment (where system integration testing and regression testing occur against realistic data volumes), and production. Organisations with a formal change management process will often add a UAT environment as a distinct gate before production cutover.

The sequencing matters: environments need to be provisioned and validated in sequence, configuration management decisions made early (how namespace naming, deployment packaging, and version control will work across environments), and the relationship between the cloud environments and any remaining on-premise systems documented explicitly.

Cutover approach is a consequential architectural decision, not a project management detail. Parallel run — operating both the on-premise and cloud environments simultaneously, comparing outputs before switching traffic — provides the highest confidence and the lowest risk, at the cost of operational complexity and the overhead of running two environments. Hard cutover — switching traffic at a defined point with rollback capability — is faster but requires higher confidence in the migration output and a tested rollback path. The decision between these approaches should be made per interface group based on clinical criticality, message volume, and your team's confidence in the test coverage.

Interface migration sequencing should start with low-risk, high-frequency feeds: administrative ADT flows, non-clinical notifications, or internal reporting interfaces where a brief interruption has limited clinical consequence. This builds team confidence in the migration process and surfaces environment-level issues before they affect high-stakes clinical workflows. Complex clinical feeds — orders and results between PAS, LIS, and RIS systems; medication feeds; theatre management integrations — should be sequenced later, once the migration factory is proven and test coverage is established.

FHIR endpoint migration requires specific attention. FHIR endpoints defined in your on-premise IRIS for Health environment will need to be re-profiled and re-tested in the HSCC environment. Implementation Guide conformance, capability statements, search parameter support, and OAuth 2.0 / SMART on FHIR configuration all need to be validated in the new environment — they do not migrate as transparent configuration artefacts.

What Post-Migration Operations Look Like

Monitoring in a cloud-hosted model works differently to on-premise HealthShare. InterSystems provides platform-level monitoring — infrastructure health, availability, and platform alerts — through the HSCC management layer. What the local team must configure and own: production-level monitoring within the IRIS environment (error queue alerting, message throughput thresholds, business-level alerting for clinically significant failures), integration with the organisation's existing ITSM tooling, and the escalation paths for after-hours incidents.

The vendor support model changes in ways that have operational implications. On-premise HealthShare support typically involves a combination of your internal team, a local InterSystems partner, and InterSystems WRC for product-level issues. In the HSCC model, platform issues are escalated directly to InterSystems — which means your team needs to understand the WRC support tiers, what constitutes a platform issue versus a configuration issue, and what the expected response times are for incidents of different severity. After-hours support planning needs to reflect this model explicitly.

Runbooks need to be written or updated before handover, not scheduled as a post-go-live activity. The runbooks that matter most: what to do when a Business Service stops receiving messages, how to investigate and clear a backed-up error queue, how to safely restart a production component, certificate renewal procedures, and the escalation path for each class of incident. These need to reflect how the HSCC environment actually works — not be re-labelled versions of the on-premise runbooks.

Operational ownership after the migration team leaves is a question that must have a named answer before the project ends. Who owns the HSCC production environment day-to-day? Who holds the WRC relationship? Who makes decisions about production configuration changes, and through what process? Organisations that answer "the integration team" without specifying individuals and their capability levels tend to find those gaps within the first month of operation.

Frequently Asked Questions