Migrating from Service Manager to OpenText SMAX for a national health insurer - case study

Executive summary

Eywo migrated a national health insurer from an unsupported OpenText Service Manager to SMAX on-premises rebuilding on SMAX's native processes rather than cloning the old tool, and going live in a matter of hours with no lost work in progress.

About client

A national health insurance company with 3600 employees, 6 milion clients and 12 bln EUR revenues.

The challenge

The client needed to move quickly and safely from an unsupported version of OpenText Service Manager to its successor platform, SMAX, without disrupting IT service operations.

The solution

• Preparation: a proof of concept defined the project scope, settled the on-premises vs. cloud decision, and surfaced risks before the live migration began.
• Scope: rather than copying the old functionality, Eywo built an MVP on SMAX's native processes Request Fulfillment, Incident Management, Service Catalog, and basic Configuration Management including integration of the client's master data (locations, people, org structure).
• Delivery approach: a combination of Waterfall (fixed milestones) and Agile (continuous validation with process owners) suited a project with a fixed deadline but variable detail. Two separate SMAX instances (production and non-production) plus Dev2Prod enabled safe transfer of changes.
• Quality & enablement: testing was managed through Azure DevOps with clear test-case owners and continuous business validation. Training for both end users and operations administrators, alongside transparent change communication, significantly improved adoption.

Results

• SMAX runs on-premises, including integrations, monitoring, and backups.
• Service Manager was fully replaced and switched to read-only.
• Delivered on time, within scope, and to the expected quality.
• Go-live took only a matter of hours, with no loss of users' work in progress; users rate the transition positively.

Lessons learned

• Don't copy the old tool one-to-one build on the new platform's native processes.
• Take the PoC seriously, and combine methodologies to balance a fixed deadline with variable detail.
• Invest in people: training and change communication drive adoption more than features do.
• Give live-operation data migration its own dedicated space in the plan. Migrating open requests and attachments from a running system deserves far more mapping attention than closed records — and should be accounted for as early as the PoC. The biggest complications here came from new client-side technologies (PostgreSQL, Kubernetes) and migrating supplier email communication.

Eywo designs and implements observability, ITSM, and infrastructure solutions for enterprise clients across regulated industries. If you're planning a similar project, get in touch.