Moving to the InterSystems Cloud: What to Actually Expect

By Heather Capel, LEAD North LLC

For decades, InterSystems customers ran IRIS-based products on servers they owned, patched, and babysat. That's changing fast, with IRIS for Health Cloud, Health Connect Cloud, and the standalone FHIR Server now available as a genuine "as a service" offering, fully provisioned, administered, and supported by InterSystems rather than by your own infrastructure team.

LEAD North has implemented all three, for existing InterSystems customers making the jump and for organizations coming from a different interface engine or FHIR Server product entirely, and this is our honest, practical take on what the transition actually involves.

Note: Not everything below applies evenly across all three products; we’ll call that out as we go.

The Big Picture

These products run on Amazon Web Services today, and InterSystems owns and operates that AWS environment, so you don't need your own AWS or server team to make it work.

That's really the core of what "managed" means here: InterSystems takes over provisioning, patching, monitoring, and uptime, backed by a real SLA. What it doesn't mean is that InterSystems runs your integrations for you. You still own your productions, interfaces, transformations, and code; think of it less as outsourcing your integration team and more as no longer needing a server team.

Important tip: The products discussed here are currently available in an AWS-only model, so if your organization has a multi-cloud policy or specific data residency needs, raise that with InterSystems directly.

Getting Your Foundation Right

Your first stop will be the InterSystems Cloud Services Portal, a new layer above the System Management Portal. This is where tenants and deployments get set up:

• A tenant is your organization's top-level container.

• A deployment (typically named something like DEV, TEST, and PROD) are the environments that live inside it, each with their own namespaces.

Assign an owner to learn this portal early. If team size allows, keep this ownership separate from your integration developers. Beyond basic separation of duties, it lets your devs focus on data flows while someone with an administrative mindset handles overall tenant governance.

Another decision you need to get right before go-live: tenants, not deployments, are your real data-segregation boundary, since everyone invited into a tenant can potentially see across every deployment inside it. If you're supporting separate business units, geographic regions or organizations that merged but haven't unified security, each belongs in its own tenant. Moving things between tenants later is a difficult, largely manual process, so getting this right at the start is important.

What You Give Up, and Where to Get Help

Here's the trade-off that catches teams off guard: true systems-administrator-level access, the kind that lets you get under the hood of the operating system itself, isn't available in InterSystems Cloud. Nearly everything you'd have configured at that level on-premises is instead handled through the Cloud Services Portal. Anything not exposed there has to be requested directly through InterSystems, and those requests are subject to platform restrictions and InterSystems' own architectural guidelines.

That's what iService, InterSystems' support ticketing system, is for, and we’re being honest when we say that InterSystems' support is genuinely strong. A lot of the same people who build the platform are the ones answering cloud tickets, which is a different experience than a first-line queue reading from a script.

You can open a ticket from the Cloud Services Portal, through the iService web portal directly, or by emailing cloudsupport@intersystems.com. A well-scoped ticket moves faster than a vague one, so be sure to include:

• Tenant

• Deployment ID

• Exact issue

• Urgency

How Integration Works in the Cloud

How you connect depends on what type of interfaces you have.

• Messaging: In many cases, Health Connect Cloud and IRIS for Health Cloud both still lean on TCP-based HL7v2 messaging as a primary pattern with HTTP-based web traffic as a growing alternative.

• Files: File-based interfaces are the one thing that changes meaningfully: since there's no OS-level file system access to drop files into anymore, S3 buckets or SFTP (InterSystems offers a built-in option) replace the old shared-drive pattern.

• APIs: IRIS for Health Cloud and FHIR Server both expose FHIR REST APIs, secured through OAuth2 with support that varies depending on the identity provider (Auth0 and Okta are well supported today). IRIS for Health Cloud additionally lets you build and expose your own custom APIs, which sit behind a mandatory InterSystems-managed gateway; should that gateway alone not provide the granularity you require for controlling access, plan to add your own API gateway during the initial implementation.

• Private Connections: Anything requiring a fully private connection can go through InterSystems Network Connect, a VPN/Direct Connect hub your deployment attaches to. It's available alongside all three cloud products; reach out to InterSystems for pricing.

Setting up these VPN connections is typically your responsibility, not InterSystems' or your implementation partner's by default, and your data source/recipient’s network team often needs a long lead time to configure their side, so this isn't a cutover-week task. It's also worth remembering that the old trust model doesn't carry over: traffic that used to stay inside a corporate VLAN is now crossing the internet, so encryption and IP whitelisting should be minimum requirements and you’ll need to loop in your security team on any additional requirements for securing PHI specifically.

Source Control and CI/CD

If you're on IRIS for Health Cloud or Health Connect Cloud, every deployment comes with a connected GitLab instance which acts as the mechanism for getting code into your deployments. From a developer's perspective, that means working in Visual Studio Code and pushing changes to GitLab. You can still edit transformations directly in the System Management Portal, but a Git commit triggers the pipeline that loads code into an environment, and the next pipeline run will overwrite anything changed directly but never committed. In practice, it's best to treat the Visual Studio Code to GitLab path as the way you make every code change, rather than relying on direct edits. Each Git branch maps to at least one namespace, and promoting code means merging one branch into the next.

This is a genuine shift for teams used to editing code directly and calling it done. We recommend assigning someone to design your CI/CD pipelines, since the right structure depends on your namespace setup, code architecture (are packages to be shared or not across namespaces), deployment cadence, and testing needs. InterSystems provides pipeline templates that get you most of the way there, but building out a fully automated pipeline including testing or other steps is on you.

Exclusion: None of this applies to the standalone FHIR Server, which does not require or include a connected GitLab pipeline.

A Few Practical Things to Plan For

• Scaling works both ways: IRIS scales vertically with ease (starting small with a Micro deployment is often plenty for lower environments), and you can scale horizontally as your workload grows. As a general rule of thumb, a single deployment comfortably supports up to roughly 100 namespaces before you'll want to plan for an additional deployment.

• Built-in Resilience: Mirroring and disaster recovery are available as part of the platform, which is one more thing your team doesn’t have to worry about in a managed environment.

• Treat any migration as its own project: Whether you're cutting over existing productions or backloading data into a new FHIR Server, inventory everything, test with real message volumes, phase your cutover, and budget a monitoring window afterward.

• Go in with realistic expectations: Ownership gaps happen (e.g., VPN setup is usually on you, not InterSystems), the platform is still maturing so you'll hit the occasional issue, and documentation beats tribal knowledge when staff or vendors change. None of this is a knock on the platform, it's just what any serious migration requires, and an implementation partner who's done this before on these specific products will catch most issues before they become blockers.

Compliance, Cost, and Case for Cloud

For executives and directors, the move to InterSystems Cloud represents a fundamental shift in both risk management and IT spending.

On the compliance side, the platform is audited annually for SOC 2 Type 2, holds HITRUST CSF r2 certification, and maintains ISO 27001 (HIPAA-covered entities will need to confirm BAA terms during contracting). This secure, audit-ready environment replaces risky manual deployments with forced source control, significantly reducing operational risk.

Financially, you are shifting away from the heavy, capital-intensive overhead of on-premises infrastructure - including server refreshes, SAN storage, OS licensing, and data center power. While you are taking on cloud software costs, you are gaining AWS-grade scalability and a real SLA in return. It’s a transition from unpredictable hardware maintenance to a predictable service model, freeing your team to focus on high-value interoperability rather than fighting platform fires.

Getting Pricing and Access

Procurement is available through the AWS Marketplace or directly through InterSystems; we'd recommend talking to InterSystems first, and if you don't have a relationship there, we're happy to make an introduction.

Health Connect Cloud and FHIR Server both have public AWS Marketplace listings (including pricing); IRIS for Health Cloud isn't sold through Marketplace today, so pricing is available only by speaking with InterSystems directly

• InterSystems HealthShare Health Connect Cloud – AWS Marketplace

• InterSystems FHIR Server – AWS Marketplace

About LEAD North

Heather Capel is the Founder and CEO of LEAD North LLC, an InterSystems Elite-level implementation partner focused on interoperability, integration engineering, and cloud migrations for healthcare organizations. Heather and LEAD North have extensive experience working directly with InterSystems products such as HealthShare, IRIS for Health, Health Connect, and FHIR Server (cloud and on premises) across health systems, payors, and healthcare technology companies.

This article reflects our own hands-on experience with these products as of mid-2026, but we recognize that the platform continues to evolve quickly. We've made every effort to get the details right, but this isn't a substitute for InterSystems' own documentation or the guidance of your account team, and specifics can vary by contract or change after publication. If something here doesn't match what you're seeing in your own environment, or you have questions about accuracy, reach out to us at info@leadnorthllc.com.