BMC Remedy Container Migration: A Practical Guide for ITSM Teams

13 August 2026 · 10 min read · All articles

Container migration is not simply lifting Remedy onto Docker. AR System, Mid Tier, plugins, integrations, and customisations each have dependencies and constraints that must be understood before you commit to a target architecture. This guide walks through the decisions, phases, and pitfalls we see most often in enterprise ITSM migrations.

For specialist delivery support, see our BMC Remedy and Helix service, and our BMC Remedy migration case study for a worked example.

Why migrate Remedy to containers?

Organisations running Remedy on ageing infrastructure face several pressures:

• End-of-support operating systems — Windows Server and Linux versions reaching EOL force upgrades or migration
• Scaling limitations — adding capacity means provisioning new VMs, not elastic scaling
• Deployment friction — patching, upgrading, and DR testing are manual and time-consuming
• Cloud strategy alignment — enterprise architecture mandates container platforms (AKS, EKS, OpenShift)
• Path to BMC Helix — container readiness is a stepping stone toward full SaaS ITSM

Containerisation does not change Remedy's functional behaviour, but it changes how you deploy, scale, monitor, and recover the platform — often dramatically for the better.

Choose your target: self-managed containers vs BMC Helix

Two primary paths exist:

• Self-managed containers — Remedy AR System and Mid Tier deployed on Kubernetes (on-premises or cloud-managed). You retain full control over infrastructure, customisations, and upgrade timing. Requires container platform expertise.
• BMC Helix (SaaS) — BMC hosts and manages the platform. Customisations migrate via the Helix Innovation Studio and deployment pipeline. Less infrastructure overhead, but SaaS constraints on certain customisations and integrations.

Many organisations take a hybrid approach: containerise on-premises first to stabilise the platform, then migrate to Helix in a later phase once customisations are rationalised.

Step 1: Inventory and assess

Before any migration work, document the current estate thoroughly:

• Remedy version, patch level, and licencing
• All server roles — AR Server, Mid Tier, FTS, Atrium, plugins, integration servers
• Customisations — filters, active links, escalations, forms, workflows, Java plugins
• Third-party integrations — monitoring tools, CMDB feeds, SSO, email, chatops
• Data volume — form counts, attachment storage, audit log size
• Performance baselines — response times, concurrent user counts, batch job schedules

Flag customisations that use unsupported APIs, hard-coded server names, or file-system dependencies — these are the items most likely to break in a container environment.

Step 2: Design the target architecture

Container architecture for Remedy typically includes:

• AR System pods — stateless, horizontally scalable behind a load balancer
• Mid Tier pods — separate deployment with session affinity if required
• FTS/Elasticsearch — often deployed as a separate StatefulSet or managed service
• Database — typically remains external (SQL Server, Oracle, or PostgreSQL) with persistent storage
• Shared storage — for attachments, logs, and configuration via PVCs or cloud storage
• Ingress and SSL termination — handled at the cluster ingress controller

Define resource requests and limits per pod based on current server sizing, then load-test with headroom. Under-provisioned containers cause performance regressions that erode stakeholder confidence early in the programme.

Step 3: Prepare customisations and integrations

Customisation migration is often the longest phase. For each custom object:

• Test in a container dev environment — do not assume parity with VM deployment
• Replace hard-coded paths and server references with environment variables or configuration
• Validate Java plugins against the target JDK version in the container image
• Update integration endpoints to use service names instead of IP addresses or hostnames
• Review ARDBC and filter logic that depends on local file system access

Rationalise while you migrate. Customisations that nobody can explain are candidates for retirement, not porting.

Step 4: Plan the cutover

Production cutover for ITSM requires careful sequencing because the service desk cannot tolerate extended downtime.

• Final data sync — plan for a change freeze window; migrate incremental changes after the last full backup
• DNS and load balancer switch — redirect users to the container environment with minimal TTL delay
• Integration cutover — update monitoring, CMDB, and SSO endpoints in coordination with the platform switch
• Rollback plan — keep the legacy environment running (read-only) for 48–72 hours post-cutover
• Hypercare period — extended support coverage for two weeks after go-live

Run at least two full dress rehearsals in a pre-production environment that mirrors production topology, including integration traffic.

Common pitfalls to avoid

• Underestimating customisation complexity — budget 40–60% of effort for custom object testing and remediation
• Ignoring FTS migration — full-text search indexes require separate planning and re-indexing time
• Skipping performance testing — container networking and storage I/O behave differently from bare-metal VMs
• No observability plan — deploy logging, metrics, and alerting before go-live, not after the first incident
• Treating it as purely infrastructure — Remedy migration is an application migration; involve Remedy administrators and developers, not just platform engineers

Conclusion

BMC Remedy container migration is achievable with structured assessment, careful customisation preparation, and disciplined cutover planning. Whether your destination is self-managed Kubernetes or BMC Helix SaaS, the investment in understanding your current estate and testing thoroughly pays off in a smoother transition and a platform that is easier to operate for years to come.